[Kss-devel] KSS without Zope

[Godefroid Chapelle]

Balazs Ree wrote:
> 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.
> 

I think you are mixing problems in the browsers with problems in Python 
libraries.

With the knowledge of what is actually working in IE and others today, I 
think using elementtree would not be difficult...

However, I think we should avoid to add a dependency not really 
needed... (see below)

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

After creating commands in memory, we do not need to manipulate them 
before serialization.

This is why I think printing is good enough.

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

we could use kss.kernel or kss.support

However, I still think that we could change kss.core to kss.zope and use 
kss.core for the Python only version.

It is not too late to change namespace imo.

I'll make a branch this week-end. We'll decide together.

Jeroen, while doing the python stuff, could you pay attention to not 
introduce pylons only stuff except in a kss.pylons package ?


-- 
Godefroid Chapelle (aka __gotcha)- BubbleNet  http://bubblenet.be