[Kss-devel] KSS without Zope

[Jeroen Vloothuis]

Balazs Ree wrote:
> Tue, 08 May 2007 22:05:11 +0200 keltezéssel Jeroen Vloothuis azt írta:
>   
>> A second level would be the language specific integration points. This
>> would include code for generating the response in the format required by
>> KSS. It might also contain some basic abstractions like we have now in
>> kss.core. With highlevel abstractions I mean code to generate the
>> implemented commands in a nice way. What do you think is basic
>> functionality for KSS server side components?
>>     
> About the python refactorization I would suggest a conservative
> approach.
>
> First, I propose to untouch kss.core at the moment and create an
> independent package kss.pycore. (That's just the name suggestion, the
> point is start with the new package and not moving kss.core.)
>   
Agreed, Plone is almost shipping with kss.core and breaking the code or 
major refactoring are not  an option at this moment.

> What should this package contain?
> ---------------------------------
>
> - helper for command generation and rendering the response (basically
> kss.core.interfaces.IAzaxCommands). As at the moment we are generating
> the response with zpt, either tal has to be a dependency, or we need to
> rewrite the rendering. Maybe we can just generate it with print, it's
> such a simple structure, just an iteration on commands.
>   
I was thinking about using elementtree. Since this is already included 
with Python (version 2.5) and a generally accepted system.
> - api and commandline for the packing/concatenation.
>   
Mochikit seems to be using a Java based packer:

http://svn.mochikit.com/mochikit/trunk/scripts/pack.py

We could also write a command line application to automatically submit 
to the Dean Edwards Javascript packer (maybe hosted on our own server).
> - ...? maybe nothing else at the moment. but for example the docstring
> registry will come here too once it's written.
>
> As you see the most important part to start with, is the command 
> generation part, later we can add more things.
>   
Agreed.

> As I imagine the javascript would not be part of the pycore package, it
> would be needed together with it (as the serving the files is not in the
> python part).
Couldn't we make a kss.javascript to hold the files? This could then be 
used as a dependency for kss.(py)core.

> How should it be implemented?
> -----------------------------
>
> I suggest that this package should come with a simple but working
> example that uses it in another non-zope framework.
>   
I am already using KSS with Pylons. So this would go right into that. 
The reason I am doing this is for my Euro Python talk. So this would be 
an example of how to use KSS without Zope.
> After this is done, we can change kss.core in a way that it uses
> kss.pycore and get rid of the code there.
>   
Ok.
> Why am I suggesting this? Because our goal is to enable kss in a
> non-python environment. Thus a use case implemented that uses the
> library is inevital But we don't need to switch over kss.core to use it, 
> before we can see it really works.
>   
One minor thing, I do not really like the name pycore. Maybe something 
one of kss.server, kss.utils, kss.components. Maybe someone has a better 
idea?