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 _______________________________________________ Kss-devel mailing list Kss-devel@codespeak.net http://codespeak.net/mailman/listinfo/kss-devel
