[Kss-devel] KSS without Zope

[Balazs Ree]

Fri, 11 May 2007 09:04:06 +0200 keltezéssel Jeroen Vloothuis azt írta:

> 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.

We originally used an elementtree generator, but we had many problems 
with it. I remember there was a specific bug that prevented it in using 
in our case, so we had to fork the library, causing enormous problems 
with compiling it for different systems, and also we had serious problems 
figuring out how to generate the namespace attributes in a way that all 
browsers especially IE parse it right. (We need tags named kukit:commands 
and so on) In the end we needed to apply a nasty hack to iterate on all 
nodes and set namespaces everywhere due to an IE issue. Ask Godefroid 
about it.

Then we decided it's a waste of time and switched to the template 
solution that we currently have.

The reason why I am suggesting printing the result is that it is really 
simple and works for sure. Of course if you want to go back to 
elementree, it's also an option, but prepare for a whole range of 
problems including unexplainable breakages in different browsers and so 
on.
   
> 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.

Since we have our packer written by Florian, I would not think of writing 
or switching to a new packer, but rather just make it available from 
python world to cook the resources and also offer a commandline that can 
"make" the kukit.js comcatenated file identically to how it's done in 
Zope.

>> 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.

Great, so we could have a pylons use case.

> 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?

I don't like kss.server because we have no server in fact.
kss.utils feels too generic for me.
kss.components is a lie because the components have nothing to do with 
this package.

Otherwise I am not so happy about pycore either.

Anyone has a better suggestion?

-- 
Balazs Ree