[Product-Developers] Re: Can KSS help in my use case ?

[Balazs Ree]

On Fri, 20 Feb 2009 12:47:07 -0600, Nathan Van Gheem wrote:


>> But I was wandering whether using KSS would make the whole more clean,
>> readable and maintainable.
>>
> I suppose it might be a little more clean and readable.  I think you can
> make non-kss code very clean and readable though too.
> 
> I can't speak for all the Plone developers out there, but it seems there
> is a growing concern that kss isn't the way to go anymore.  It is too
> heavy(lots of extra code for the browser to download and parse).  IMO,
> kss became cumbersome to do easy tasks that were just a bit outside its
> capabilities and I'm no longer going to use it anymore.  In your use
> case it might work though.

Kss aims to focus on supporting the following developer roles (with 
increasing order of knowledge and expertise needed):

- developer or designer that wires up a page via a kss stylesheet

- developer who develops and sets up an ajax application, by a kss 
  stylesheet and server side kss actions (python)

- developer who creates a plugin for kss (in javascript) making it
  available for use to the above groups. This is needed for kss to 
  provide fat client behaviour for several use cases such as drag and
  drop or custom javascript widgets.

We had moderate success to document the first two activities, but we 
never arrived to documenting the third one: the making of kss plugins in 
a simple and accessible way. Those of us who actually wrote kss plugins, 
also realized that kss lacks some wisdom in this area. During the lessons 
we learned from encountered use cases and projects, some of us also 
realized that we need to improve the plugin creation process a great 
deal. One specific goal is to make plugin creation more accessible for 
javascript developers and inline with the accustomed js development 
techniques (while keeping the rest of the kss backwards compatible).

Before this happens I can give the following advice on deciding about 
whether or not deploying kss in a project:

- If you don't actually need to have a fat client or write actual 
javascript code, you can use kss to implement your ajax in the documented 
way, with all benefits offered.

- If you need a fat client, just go ahead and implement your features in
javascript "as usual". If you want you can also have some kss code 
running in parallel with your javascript: although kss won't know about 
your additional javascript in this case, but it also will peacefully 
coexist with it.

- If you already have your extra javascript running, you would have a 
chance to make it into a kss plugin: write a wrapper that enables using 
your new code from within kss. This allows you to wire up and configure 
your new features from kss, and provide the same code as a kss plugin 
egg, reusable in other applications without touching the javascript.

Since the last step and process involved is the undocumented one that I 
mentioned above, I would only suggest to attempt it if you have deep 
knowledge about both javascript and understand bits of the kss internals. 
In particular I would not suggest to dig into "kss event creation", 
however for simple cases it is easy to create just "kss actions" (and for 
this you will also find some documentation and examples).


I would also like to react a bit about performance. We believe there is a 
lot we can improve here, one of my personal development plans is called 
"zerotolerance": and it aims to implement **0 pageload overhead** in kss. 
(Yes we figured out a feasible way to do that.)

So, although we cannot promise an immediate remedy to the above stated 
problems, development of kss is going on with some exciting goals to 
reach by the end of 2009. 

Best wishes,

-- 
Balazs Ree