From ree at ree.hu Tue May 1 12:35:18 2007 From: ree at ree.hu (Balazs Ree) Date: Tue, 1 May 2007 12:35:18 +0200 Subject: [Kss-devel] the new kssSubmitForm action parameter Message-ID: With the help of Martin Aspeli, Jan Murre and Godefroid Chapelle and others, we introduced a "new way" of submitting entire forms. The previous solution involved usage of the form() and currentForm() action parameters and marshalled an entire form into a single record parameter. This breaks to work with Zope list: record: records: style multi variables, and it can't even be fixed like this. So we will deprecate this usage and have implemented a new way of doing this. There is a special "action parameter" with the name kssSubmitForm. Action parameters are special parameters that are associated with the action itself and generic to all actions. Their names all start with the kss prefix and consequently normal parameters cannot have their name started like this. Other examples of action parameters implemented so far, are kssSelector for client actions and kssUrl for server actions. The kssSubmitForm parameter, if present in a server action, will cause the entire form selected by the value, marshalled up directly into the request. Then it can be accessed on the server view - as normally - by a method parameter, or by accessing request.form directly. It handles all Zope multi-style form fields correctly, as it just passes them around to the server without processing. We will yet consider changing the behaviour that happens when there is a field in the form which is also a parameter in kss with the same name. Currently, the value from the form will silently overwrite that of kss. Examples for usage as in kss.demo (look for the full example there): #fullform-current:click { action-server: submitFullFormIntoRequest; submitFullFormIntoRequest-kssSubmitForm: currentForm(); } #fullform-named:click { action-server: submitFullFormIntoRequest; submitFullFormIntoRequest-kssSubmitForm: form(full2); } #fullform-namedbystring:click { action-server: submitFullFormIntoRequest; submitFullFormIntoRequest-kssSubmitForm: 'full2'; } >From the example it can be seen how the providers form() and currentForm () are used. A single string is equivalent of using form() with the string as parameter. All the above is for handling entire forms only. For handling individual field values, formVar() and currentFormVar() can be used as previously. These don't aim at handling multi form variables of Zope, instead they require the full name of the form field as in the form. This improvement is part of the current kss.core 1.2-beta2 release, already on Cheeseshop. -- Balazs Ree From ree at ree.hu Mon May 7 11:05:48 2007 From: ree at ree.hu (Balazs Ree) Date: Mon, 7 May 2007 11:05:48 +0200 Subject: [Kss-devel] ree-stripout-comments branch Message-ID: I created the ree-stripout-comment branch (should rather be called stripout-asserts) which is an experiment with the technology of creating a production and development version of the kss javascript. We introduced the ;;; construct, if this appears in the beginning of a line, the line will appear only in the development version and not in the production version. The current code is marked this way and all logs, exception messages and a lot of the asserts during parsing and binding are now stripped. This results, in full compression mode, a 104K code size, and compared to the current 129K this means a 19% win at the first try. It may also be a bit faster, but I can't estimate this. To use it with Plone, we need to again take the packing into our hands from RR. All things have to be set up manually, as I did not want to branch CMFPlone. This is how to try it: 1. switch kss.core to the branch ree-stripout-comments 2. In portal_javascript tool, rename ++resource++kukit-src.js to ++resource++kukit.js, and enter the following condition into it: here/@@kss_devel_mode/isoff 3. create a new resource like the previous one, with the name ++resource++kukit-devel.js with this condition: here/@@kss_devel_mode/ison or if you want, you can combine both of these conditions with the current condition that disables kss for anonymous users, but this is not important for testing. So these are the two resources we have, and which one gets into the page, is selected by the view. It's all set up now. You can visit a simple UI at the browser page: @@kss_devel_mode/ui That shows you if kss is currently in production or in development mode. You can toggle a browser cookie with the buttons. This is a client side setting, no need to change the server for switching to development mode: this is a very important principle imo. The setting can also be overruled by RR: if you set debug mode in portal_javascript, kss will get into development mode permanently and independently of the setting of the cookie. Something about the technology. The ;;; construct works reasonable well, but it has some artifacts. I am using the following patterns in the commentification: ;;; this line is only in development This cannot be used however - inside expressions that span multiple lines (like () or a string +) - inside the switch statement so I also used these: /* ;;; */ this is only in development mode and this too ;;; /* */ and even these: ;;; /* this is only in production mode and this too ;;; */ Comments, suggestions? I am open for new ideas. I agree ;;; does not work so nice in some cases, but it's doable. The stripout itself happens before the packer starts its job. This would stay so, even if this gets integrated to the packer, we will need two passes. In the concatresource now you have the following packing levels available: - none: the raw sources - devel: like none but the ;;;-s themselves are removed - prod: the production version unpacked, readable - safe-devel: safe packing, devel version - safe: safe packing of the production version - full-devel: full packing, devel version - full: full packing of the production version Of these mostly devel, safe and full make sense. - At the moment only kss's concatresource can pack this way, RR can not yet. Please try this branch and see if you can notice any difference in performance. -- Balazs Ree From jeroen.vloothuis at xs4all.nl Wed May 9 09:23:27 2007 From: jeroen.vloothuis at xs4all.nl (Jeroen Vloothuis) Date: Wed, 09 May 2007 09:23:27 +0200 Subject: [Kss-devel] ree-stripout-comments branch In-Reply-To: References: Message-ID: <464176EF.4070007@xs4all.nl> Balazs Ree wrote: > This results, in full compression mode, a 104K code > size, and compared to the current 129K this means a 19% win at the first > try. It may also be a bit faster, but I can't estimate this. > Saving 19% on the download alone seems worth it. > Something about the technology. > > The ;;; construct works reasonable well, but it has some artifacts. I am > using the following patterns in the commentification: > > This cannot be used however > > - inside expressions that span multiple lines (like () or a string +) > > - inside the switch statement > Is it not possible to think of a multine stripping feature? Maybe something like a special debug function: function debug(func){ func(); } debug(function(){ alert('pinda'); for(var i=0; i<3; i++){ alert('cheese '+i); } }); You could write the stripper so that it would know about this special debug function and it would remove all calls to it. From ree at ree.hu Wed May 9 10:35:42 2007 From: ree at ree.hu (Balazs Ree) Date: Wed, 9 May 2007 10:35:42 +0200 Subject: [Kss-devel] ree-stripout-comments branch References: <464176EF.4070007@xs4all.nl> Message-ID: Wed, 09 May 2007 09:23:27 +0200 keltez?ssel Jeroen Vloothuis azt ?rta: > Balazs Ree wrote: >> This results, in full compression mode, a 104K code size, and compared >> to the current 129K this means a 19% win at the first try. It may also >> be a bit faster, but I can't estimate this. >> > Saving 19% on the download alone seems worth it. >> Something about the technology. >> >> The ;;; construct works reasonable well, but it has some artifacts. I >> am using the following patterns in the commentification: >> >> This cannot be used however >> >> - inside expressions that span multiple lines (like () or a string +) >> >> - inside the switch statement >> > Is it not possible to think of a multine stripping feature? Maybe > something like a special debug function: > > function debug(func){ > func(); > } > > debug(function(){ > alert('pinda'); > for(var i=0; i<3; i++){ > alert('cheese '+i); > } > }); > > You could write the stripper so that it would know about this special > debug function and it would remove all calls to it. Two problems with this. First, it should also remove the function declarations itself since we care for space, and second it would need parsing the javascript, while recently the stripout is implemented by a very simple line-by-line filter. The current ;;; solution seems to be acceptable, but as we recently discussed with Godefroid, we should avoid using the following constructs: /* ;;; */ whatever ;;; /* */ and we already have some ideas how to achieve that with small modifications of the code. -- Balazs Ree From jeroen.vloothuis at xs4all.nl Tue May 8 22:05:11 2007 From: jeroen.vloothuis at xs4all.nl (Jeroen Vloothuis) Date: Tue, 08 May 2007 22:05:11 +0200 Subject: [Kss-devel] KSS without Zope Message-ID: For server side KSS support we are currently tied to Zope. While basic KSS functionality might be easily reimplemented this still hinders adoption. To overcome this problem I think it would be good to have a basic distribution of KSS at a few levels. The first level would be just the Javascript code. This should include only the core of KSS (what is now kukit in the repository). It would need to available as a packed version preferably with all required third party libraries included. 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? And the last level would be framework integration. This basically what we have now in kss.core. Things that are especially framework specific like the event system etc. would go here. I would like to (help) make the necessary changes. Therefore I want to know if there are any objections or suggestions to my ideas. From ree at ree.hu Thu May 10 18:07:37 2007 From: ree at ree.hu (Balazs Ree) Date: Thu, 10 May 2007 18:07:37 +0200 Subject: [Kss-devel] KSS without Zope References: Message-ID: Tue, 08 May 2007 22:05:11 +0200 keltez?ssel Jeroen Vloothuis azt ?rta: > For server side KSS support we are currently tied to Zope. While basic > KSS functionality might be easily reimplemented this still hinders > adoption. To overcome this problem I think it would be good to have a > basic distribution of KSS at a few levels. > > The first level would be just the Javascript code. This should include > only the core of KSS (what is now kukit in the repository). It would > need to available as a packed version preferably with all required third > party libraries included. > > 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.) 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. - api and commandline for the packing/concatenation. - ...? 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. 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). 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. After this is done, we can change kss.core in a way that it uses kss.pycore and get rid of the code there. 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. -- Balazs Ree From jeroen.vloothuis at xs4all.nl Fri May 11 09:04:06 2007 From: jeroen.vloothuis at xs4all.nl (Jeroen Vloothuis) Date: Fri, 11 May 2007 09:04:06 +0200 Subject: [Kss-devel] KSS without Zope In-Reply-To: References: Message-ID: <46441566.4010600@xs4all.nl> 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? From ree at ree.hu Fri May 11 09:56:19 2007 From: ree at ree.hu (Balazs Ree) Date: Fri, 11 May 2007 09:56:19 +0200 Subject: [Kss-devel] KSS without Zope References: <46441566.4010600@xs4all.nl> Message-ID: 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 From gotcha at bubblenet.be Fri May 11 10:14:10 2007 From: gotcha at bubblenet.be (Godefroid Chapelle) Date: Fri, 11 May 2007 10:14:10 +0200 Subject: [Kss-devel] KSS without Zope In-Reply-To: References: <46441566.4010600@xs4all.nl> Message-ID: <464425D2.4010105@bubblenet.be> 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 From ree at ree.hu Fri May 11 10:35:40 2007 From: ree at ree.hu (Balazs Ree) Date: Fri, 11 May 2007 10:35:40 +0200 Subject: [Kss-devel] KSS without Zope References: <46441566.4010600@xs4all.nl> <464425D2.4010105@bubblenet.be> Message-ID: On 2007. 05. 11, 10.14- Godefroid Chapelle wrote: > 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 agree on changing kss.core to kss.zope later (preferably with a major version release). I agree it's not too late, but I would say the name change can be done independently from the planned refactorization. Make the new package, make kss.core use it, and at some point we can consider changing kss.core to kss.zope. But: I am against naming the python-only package back to kss.core, we have infinite number of unused names to choose from and we should not call the new python-only package the same as we called a zope-only package at one time. Besides kss.core is not so cool either, especially because it does not say "the core for what?" but at least atm kss.core really contains "the core" of kss but that would not be true for the new package (imagine we are talking about "kss core" and "kss core plugins" as of javascript). kss.support, more ok, actually for me this feels the best so far. Also think that we may have more subpackages: kss.support.commands kss.support.cookjs or whatever, so support is good because after that you say "support for what". yet another (not too bright) suggestion is kss.base . > Jeroen, while doing the python stuff, could you pay attention to not > introduce pylons only stuff except in a kss.pylons package ? Definitely. And whoever creates a new package, make sure of the egg format. -- Balazs Ree From jeroen.vloothuis at xs4all.nl Fri May 11 15:48:07 2007 From: jeroen.vloothuis at xs4all.nl (Jeroen Vloothuis) Date: Fri, 11 May 2007 15:48:07 +0200 Subject: [Kss-devel] KSS without Zope In-Reply-To: References: <46441566.4010600@xs4all.nl> <464425D2.4010105@bubblenet.be> Message-ID: Balazs Ree wrote: > kss.support, more ok, actually for me this feels the best so far. Also > think that we may have more subpackages: > > kss.support.commands > kss.support.cookjs Can those be shortend to kss.commands and kss.cookjs (or kss.jscooker). > or whatever, so support is good because after that you say "support for > what". > > yet another (not too bright) suggestion is kss.base . > >> Jeroen, while doing the python stuff, could you pay attention to not >> introduce pylons only stuff except in a kss.pylons package ? > > Definitely. I would not dream of doing it any other way. > And whoever creates a new package, make sure of the egg format. This goed without saying :-) From ree at ree.hu Fri May 11 17:11:06 2007 From: ree at ree.hu (Balazs Ree) Date: Fri, 11 May 2007 17:11:06 +0200 Subject: [Kss-devel] KSS without Zope References: <46441566.4010600@xs4all.nl> <464425D2.4010105@bubblenet.be> Message-ID: On Fri, 11 May 2007 15:48:07 +0200 Jeroen Vloothuis wrote: > Balazs Ree wrote: >> kss.support, more ok, actually for me this feels the best so far. Also >> think that we may have more subpackages: >> >> kss.support.commands >> kss.support.cookjs > > Can those be shortend to kss.commands and kss.cookjs (or kss.jscooker). hmmm. Actually I like the idea. Godefroid? (actually packer would be better instead but jscooker is fine too) -- Balazs Ree From gotcha at bubblenet.be Fri May 11 17:25:53 2007 From: gotcha at bubblenet.be (Godefroid Chapelle) Date: Fri, 11 May 2007 17:25:53 +0200 Subject: [Kss-devel] KSS without Zope In-Reply-To: References: <46441566.4010600@xs4all.nl> <464425D2.4010105@bubblenet.be> Message-ID: <46448B01.3010705@bubblenet.be> Balazs Ree wrote: > On Fri, 11 May 2007 15:48:07 +0200 Jeroen Vloothuis wrote: > >> Balazs Ree wrote: >>> kss.support, more ok, actually for me this feels the best so far. Also >>> think that we may have more subpackages: >>> >>> kss.support.commands >>> kss.support.cookjs >> Can those be shortend to kss.commands and kss.cookjs (or kss.jscooker). > > hmmm. Actually I like the idea. Godefroid? > > (actually packer would be better instead but jscooker is fine too) > go for kss.commands I propose kss.jspacker -- Godefroid Chapelle (aka __gotcha)- BubbleNet http://bubblenet.be From gotcha at bubblenet.be Fri May 11 17:45:52 2007 From: gotcha at bubblenet.be (Godefroid Chapelle) Date: Fri, 11 May 2007 17:45:52 +0200 Subject: [Kss-devel] KSS without Zope In-Reply-To: <46448B01.3010705@bubblenet.be> References: <46441566.4010600@xs4all.nl> <464425D2.4010105@bubblenet.be> <46448B01.3010705@bubblenet.be> Message-ID: <46448FB0.6030302@bubblenet.be> Godefroid Chapelle wrote: > Balazs Ree wrote: >> On Fri, 11 May 2007 15:48:07 +0200 Jeroen Vloothuis wrote: >> >>> Balazs Ree wrote: >>>> kss.support, more ok, actually for me this feels the best so far. Also >>>> think that we may have more subpackages: >>>> >>>> kss.support.commands >>>> kss.support.cookjs >>> Can those be shortend to kss.commands and kss.cookjs (or kss.jscooker). >> hmmm. Actually I like the idea. Godefroid? >> >> (actually packer would be better instead but jscooker is fine too) >> > > go for kss.commands actually it should be kss.commands.core so that the namespace kss.commands can be reused for stuff like kss.commands.scriptaculous or whatever. > > I propose kss.jspacker > > Do we need kss.jsclient to ship the files ? -- Godefroid Chapelle (aka __gotcha)- BubbleNet http://bubblenet.be From ree at ree.hu Sat May 12 11:53:27 2007 From: ree at ree.hu (Balazs Ree) Date: Sat, 12 May 2007 11:53:27 +0200 Subject: [Kss-devel] kss.core: performance_improvement branch merged to trunk Message-ID: I report that the performance_improvement branch of kss.core is now merged to trunk. Changes: - Changed querying for css selectors to base2 instead of cssQuery. Base2 is supposed to be a lot faster than the old cssQuery. Usage is alternating, if base2 is present that one is used, otherwise it uses the old cssQuery code which stays the default. [jvloothuis, ree] - Add moveNodeBefore action (presumably missing) [ree] - Refactor load event, separate iload and load events. The new event binder handles both events together. A new parameter, evt-iload-autodetect is introduced, if this is false we don't use detection but the iframe must cooperate on telling us wnen we are done. There is deprecation warning issued for the load events, if bound on an iframe, in which case an iload event must be used. [ree] - refactor event binding to allow different iterators to bind events in a binder instance, matching the need of the events. [ree] Of this only the load event refactoring can possibly cause issues, if you experience errors or issues when loading the kupu editor, please report and also please test with kupu loading both statically and dynamically (with and without kss). Last but not least, at the same time Godefroid made a nice work on this: - Death to Azax (... long live KSS)! Removing last traces of the old name from the sources [gotcha] this means that imports that contained Azax now contain KSS. -- Balazs Ree From jeroen.vloothuis at xs4all.nl Sat May 12 17:29:07 2007 From: jeroen.vloothuis at xs4all.nl (Jeroen Vloothuis) Date: Sat, 12 May 2007 17:29:07 +0200 Subject: [Kss-devel] Server response format Message-ID: The current server side infrastructure generates XML/HTML output as a response (aside from a test renderer used in unit tests). This rendering has a problem in my opinion. I hope to illustrate the problems I see with it so that we can either discuss a fix/replacement or you can enlighten me on the design choices. After alle headers etc. are generated the KSS response consists of:

it worked

 Using the structure statement means that all output is passed as is. This has the implication of generating something like: ...

it worked ... Code like that is obviously not valid XML. A problem with this is that it breaks the whole response parsing. Therefore you do not get nice local errors for the command which should actually break. As far as I can see the current fix for this is to use BeautifulSoup to fix up any broken data. In my opinion this is a fix to a problem which should not be there in the first place. For an application developer this implicit magic can have nasty side effects when debugging styling problems (due to a wrong fix). Like I said earlier I think the approach is flawed from the start. There is no reason I can think of to alter the structure of the response document. What I mean by this is that all data should be escaped and not made part of the DOM. So the earlier example would like like: ... <h1>it worked ... This would make it possible to write a schema for the KSS reponse and validate it against that shema. If you allow arbitrary data this will not be possible. At the moment I do not see why escaping should not be default way. All actions that need DOM force any string anyway (for use with client side actions). I would rather not duplicate the current behaviour (at least not until I understand why it is done this way) in the new kss.commands package. So please enlighten me on the design choices so that I may understand them. From gotcha at bubblenet.be Sat May 12 18:28:57 2007 From: gotcha at bubblenet.be (Godefroid Chapelle) Date: Sat, 12 May 2007 18:28:57 +0200 Subject: [Kss-devel] Server response format In-Reply-To: References: Message-ID: <4645EB49.9090002@bubblenet.be> Jeroen Vloothuis wrote: > The current server side infrastructure generates XML/HTML output as a > response (aside from a test renderer used in unit tests). This rendering > has a problem in my opinion. I hope to illustrate the problems I see > with it so that we can either discuss a fix/replacement or you can > enlighten me on the design choices. > > After alle headers etc. are generated the KSS response consists of: > > > selector="div#demo" name="setHtmlAsChild" > selectorType="" > tal:attributes="selector python: command.getSelector(); > name python: command.getName(); > selectorType python: command.getSelectorType()"> > tal:attributes="name python: param.name" > tal:content="structure python: param.content"> >

it worked

> > > > > Using the structure statement means that all output is passed as is. > This has the implication of generating something like: > > ... > >

it worked > > ... > IIRC, this would not work in some of the browsers that demand well-formed XML for XMLHTTPRequests. > Code like that is obviously not valid XML. A problem with this is that > it breaks the whole response parsing. Therefore you do not get nice > local errors for the command which should actually break. > > As far as I can see the current fix for this is to use BeautifulSoup to > fix up any broken data. In my opinion this is a fix to a problem which > should not be there in the first place. > > For an application developer this implicit magic can have nasty side > effects when debugging styling problems (due to a wrong fix). > > Like I said earlier I think the approach is flawed from the start. There > is no reason I can think of to alter the structure of the response > document. What I mean by this is that all data should be escaped and not > made part of the DOM. > > So the earlier example would like like: > > ... > > <h1>it worked > > ... > > This would make it possible to write a schema for the KSS reponse and > validate it against that shema. If you allow arbitrary data this will > not be possible. > > At the moment I do not see why escaping should not be default way. All > actions that need DOM force any string anyway (for use with client side > actions). > > I would rather not duplicate the current behaviour (at least not until I > understand why it is done this way) in the new kss.commands package. So > please enlighten me on the design choices so that I may understand them. IIRC, the main reason for this "broken" format is IE6. The trouble being its broken implementation for importing in the browser document the nodes from the document in the response of the XMLHTTPRequest. I am afraid you'd need to go through all the hurdles we overcame before finding a new format that really works. One of those hurdles was the fact we had to be in the html namespace instead of being able to use the a plain kukit namespace. However, if you can prove me wrong, I am all for a format that we could validate. Keep in mind that a new format would imply changes in the js client as well, iow stuff that would need to be tested in each browser that we want to support. But I'd advise you to do this as a second step if you want to have a pure Python implementation. Do not underestimate the time invested in the current code ;-) -- Godefroid Chapelle (aka __gotcha)- BubbleNet http://bubblenet.be From ree at ree.hu Sun May 13 07:59:47 2007 From: ree at ree.hu (Balazs Ree) Date: Sun, 13 May 2007 07:59:47 +0200 Subject: [Kss-devel] Server response format References: <4645EB49.9090002@bubblenet.be> Message-ID: Sat, 12 May 2007 18:28:57 +0200 keltez?ssel Godefroid Chapelle azt ?rta: >> I would rather not duplicate the current behaviour (at least not until >> I understand why it is done this way) in the new kss.commands package. >> So please enlighten me on the design choices so that I may understand >> them. > > IIRC, the main reason for this "broken" format is IE6. The trouble being > its broken implementation for importing in the browser document the > nodes from the document in the response of the XMLHTTPRequest. > > I am afraid you'd need to go through all the hurdles we overcame before > finding a new format that really works. > > One of those hurdles was the fact we had to be in the html namespace > instead of being able to use the a plain kukit namespace. > > However, if you can prove me wrong, I am all for a format that we could > validate. Keep in mind that a new format would imply changes in the js > client as well, iow stuff that would need to be tested in each browser > that we want to support. > > But I'd advise you to do this as a second step if you want to have a > pure Python implementation. Do not underestimate the time invested in > the current code ;-) I also insist to decouple the question of the transport format. At the moment we have a transport format that works reasonably well. However let's not ignore the goal: to make the server side usable from plain python, and not changing the transport format (which would imply changes in the current zope components, and the javascript code immediately). I suggest that unless it turns out that the current transport format is not posible or very difficult to implement from python (which is not the case), stick to it completely. Also what Jeroen writes about the brokenness of current XML is not true: we have the parser class that validates and fixes broken html so we cannot at the moment issue broken xml. I suggest this behaviour is also preserved in the plain python generation. Iow, I do not believe the current solution is broken. On the other hand we can improve the format later if we like to, but since it works perfect at the moment, a real good reason is needed. -- Balazs Ree From ree at ree.hu Sun May 13 08:19:54 2007 From: ree at ree.hu (Balazs Ree) Date: Sun, 13 May 2007 08:19:54 +0200 Subject: [Kss-devel] Server response format References: Message-ID: Sat, 12 May 2007 17:29:07 +0200 keltez?ssel Jeroen Vloothuis azt ?rta: > Like I said earlier I think the approach is flawed from the start. There > is no reason I can think of to alter the structure of the response > document. What I mean by this is that all data should be escaped and not > made part of the DOM. Could be escaped but exactly as you say it would not be part of the dom any more. It would become a parameter that we'd need to parse manually from the client into dom, The current format makes sure that is is parsed immediately when the browser recieves it. > So the earlier example would like like: > > ... > > <h1>it worked > > .. > I tried to explain this to you in irc. This would be wrong, because instead of the structured html you become a simple text node, but the content is not even a string as we know various things happen with non- ascii character like enter. You could do this: and then in the attribute you'd use the escaping you need inside attributes (which is btw not the same that you need in the html code). Would this be better? I rather like to read an xml document then a string of two pages that contains an encoded structure, but indeed we can start thinking of this. But, imo, put it in any way, it's the issuer's responsibility to issue valid html code. If invalid html is issues, the result will be broken at some point and you can't do anything against it (besides an attempt to same fix it as we currently do with beautifulsoup) So if your concern is this, I am afraid there is not much to do. > This would make it possible to write a schema for the KSS reponse and > validate it against that shema. If you allow arbitrary data this will > not be possible. Indeed this is true, no strict parsing is possible. I would add that even if we had dtd it would be no use at all, since the only ones that reads this are the clients that parse this xml with the builtin xmlhttprequest code, and they don't care for dtd. Even if you have a schema it would be useless. > At the moment I do not see why escaping should not be default way. All > actions that need DOM force any string anyway (for use with client side > actions). If it were in parameters, it'd need escaping. If it is in the body of the html, then it is valid html and not a string: so no escaping desired: tags need to be real tags. > I would rather not duplicate the current behaviour (at least not until I > understand why it is done this way) in the new kss.commands package. So > please enlighten me on the design choices so that I may understand them. The question is not the design choices at this point. This format developped in an evolutionary way that it should be simple to parse, handle on the client, and that it works cross browser. The question is what reason we have to change it right now. Some of your reasons may be valid, so we may return to this topic later, but let's not turn the "enable kss from pure python" story to a "change the commands transport" saga. -- Balazs Ree From jeroen.vloothuis at xs4all.nl Sun May 13 12:04:19 2007 From: jeroen.vloothuis at xs4all.nl (Jeroen Vloothuis) Date: Sun, 13 May 2007 12:04:19 +0200 Subject: [Kss-devel] Server response format In-Reply-To: References: <4645EB49.9090002@bubblenet.be> Message-ID: Balazs Ree wrote: > I suggest that unless it turns out that the current transport format is > not posible or very difficult to implement from python (which is not the > case), stick to it completely. The reasons that I brought it up are: A. because I just noticed how it is being done now and as an outsider it seems weird. B. end users of the Python library will need to know what they can pass in (in terms of data, do they need to escape it etc.). > Also what Jeroen writes about the brokenness of current XML is not true: > we have the parser class that validates and fixes broken html so we > cannot at the moment issue broken xml. I suggest this behaviour is also > preserved in the plain python generation. Iow, I do not believe the > current solution is broken. The parser is only used in the commandset. This means that the responsibility of escaping is placed on there. In itself this is not a problem. But you a decision needs to made if this is the proper place for it. I do not want have people depend on a library and then totally change it's behaviour. > On the other hand we can improve the format later if we like to, but > since it works perfect at the moment, a real good reason is needed. How about the example given below. This is something I can generate atm with the current Zope integrated code. Because setAttribute does not escape anything we get a nicely broken XML document. name

Hellow From jeroen.vloothuis at xs4all.nl Sun May 13 12:15:54 2007 From: jeroen.vloothuis at xs4all.nl (Jeroen Vloothuis) Date: Sun, 13 May 2007 12:15:54 +0200 Subject: [Kss-devel] Server response format In-Reply-To: References: Message-ID: Balazs Ree wrote: >> ... >> >> <h1>it worked >> >> .. >> > > I tried to explain this to you in irc. This would be wrong, because > instead of the structured html you become a simple text node, but the > content is not even a string as we know various things happen with non- > ascii character like enter. You could do this: > > > > and then in the attribute you'd use the escaping you need inside > attributes (which is btw not the same that you need in the html code). > > Would this be better? I rather like to read an xml document then a string > of two pages that contains an encoded structure, but indeed we can start > thinking of this. The value as attribute you suggest now sounds fine by me. > But, imo, put it in any way, it's the issuer's responsibility to issue > valid html code. If invalid html is issues, the result will be broken at > some point and you can't do anything against it (besides an attempt to > same fix it as we currently do with beautifulsoup) So if your concern is > this, I am afraid there is not much to do. It is indeed my concern where the responsibility lies. Also the current format is deficient in the way to you must always pass valid xml even when just want to pass a string. >> This would make it possible to write a schema for the KSS reponse and >> validate it against that shema. If you allow arbitrary data this will >> not be possible. > > Indeed this is true, no strict parsing is possible. I would add that even > if we had dtd it would be no use at all, since the only ones that reads > this are the clients that parse this xml with the builtin xmlhttprequest > code, and they don't care for dtd. Even if you have a schema it would be > useless. The point of the schema is not that a schema itself would be useful but that a good format should be able to validate. > The question is not the design choices at this point. This format > developped in an evolutionary way that it should be simple to parse, > handle on the client, and that it works cross browser. The question is > what reason we have to change it right now. Some of your reasons may be > valid, so we may return to this topic later, but let's not turn the > "enable kss from pure python" story to a "change the commands transport" > saga. My biggest reason for bringing this up is to make clear that end users of the pure Python library need to know what they can pass in. From gotcha at bubblenet.be Sun May 13 14:39:00 2007 From: gotcha at bubblenet.be (Godefroid Chapelle) Date: Sun, 13 May 2007 14:39:00 +0200 Subject: [Kss-devel] Server response format In-Reply-To: References: Message-ID: <464706E4.9050304@bubblenet.be> Jeroen Vloothuis wrote: > > My biggest reason for bringing this up is to make clear that end users > of the pure Python library need to know what they can pass in. > Which actually would depend on the semantic of each command... -- Godefroid Chapelle (aka __gotcha)- BubbleNet http://bubblenet.be From jeroen.vloothuis at xs4all.nl Sun May 13 14:47:36 2007 From: jeroen.vloothuis at xs4all.nl (Jeroen Vloothuis) Date: Sun, 13 May 2007 14:47:36 +0200 Subject: [Kss-devel] Server response format In-Reply-To: <464706E4.9050304@bubblenet.be> References: <464706E4.9050304@bubblenet.be> Message-ID: Godefroid Chapelle wrote: > Jeroen Vloothuis wrote: > > > >> My biggest reason for bringing this up is to make clear that end users >> of the pure Python library need to know what they can pass in. >> > Which actually would depend on the semantic of each command... Yes, so at the moment the library would not escape anything. If you need to pass a string value than you would need to escape it yourself. This is fine by me. I will let this issue rest and continue on to the commandset support for pure Python usage. The code that is in the trunk of kss.commands works according like the current kss.core (in the way that it does not escape the values). Thanks for explaining the issues. From ree at ree.hu Sun May 13 16:22:09 2007 From: ree at ree.hu (Balazs Ree) Date: Sun, 13 May 2007 16:22:09 +0200 Subject: [Kss-devel] Server response format References: <464706E4.9050304@bubblenet.be> Message-ID: Sun, 13 May 2007 14:47:36 +0200 keltez?ssel Jeroen Vloothuis azt ?rta: > Godefroid Chapelle wrote: > > Jeroen Vloothuis wrote: > > > > > > > >> My biggest reason for bringing this up is to make clear that end > >> users of the pure Python library need to know what they can pass in. > >> > > Which actually would depend on the semantic of each command... > > Yes, so at the moment the library would not escape anything. If you need > to pass a string value than you would need to escape it yourself. This > is fine by me. I will let this issue rest and continue on to the > commandset support for pure Python usage. The problem is we don't have data types so the parameters cannot decide the conversion. Values that you can pass are either of the two types at the moment: - unicode string values - in the case of parameters that have the payload, XML or HTML (as a unicode string) Unicode strings that travel in commands are properly escaped (if not it's a bug and we need a test + fix for it) which means unicode parameters arrive on the client as sent from the server. You don't need to escape them beforehand just pass them in an unicode. The XML payload really depends on if it's XML or HTML. So we cannot decide automatically which parser we apply: the command has to decide that and check the values properly. That is what we had in commandsets in the previous implementation. Actually the parser is doing fixup of bad html too that you would not want from xml. However wheather or not we parse the content, we do not apply quoting in it because we want them to remain tags and get embedded into the document. > The code that is in the trunk of kss.commands works according like the > current kss.core (in the way that it does not escape the values). We even check from tests, if the hmtl entity was replaced by its numeric version » . This shows that the current code, when inserting html payload, is escaping the value. Only, it is not the same kind of escaping you would expect from it. Obviously for this the caller has to run the result through the html or the xml parser, in order this to be done, and we can't decide for him, which parser is needed. Only the command can know about that, and this is currently implemented in the commandset layer, whose equivalent is yet to be invented. -- Balazs Ree From jeroen.vloothuis at xs4all.nl Fri May 25 23:33:01 2007 From: jeroen.vloothuis at xs4all.nl (Jeroen Vloothuis) Date: Fri, 25 May 2007 23:33:01 +0200 Subject: [Kss-devel] Why not to use KSS? In-Reply-To: <21a6ef160705250345x178419d8tc6fc95be5ce89ad9@mail.gmail.com> References: <200705241201.03183.srichter@cosmos.phy.tufts.edu> <21a6ef160705250345x178419d8tc6fc95be5ce89ad9@mail.gmail.com> Message-ID: <4657560D.70004@xs4all.nl> Hi Martijn, Just saw your post on z3c.form. I was interested in hearing your opinions on KSS. In a response to a question as why not to use KSS you mentioned a difference of opinion in architecture. I am not out to persuade you in any way but would like to know how you (and others) see things. KSS like any tool obviously is not for everyone. But I think it would be good to know where you think it's weaknesses are so that we can either fix them or communicate the cases where it does not work better. This can help people decide if KSS is the tool they need. Martijn Pieters wrote: > On 5/25/07, Raphael Ritz wrote: >> Just a quick question in passing, as I understand this as Zope >> growing "yet another(?)" AJAX framework. >> Did you consciously decide against KSS (http://kssproject.org) >> or do you see this as complementary? > > We consciously decided against KSS, for various reasons. Some of these > reasons lie in a difference of opinion on how an AJAX architecture > should work. > > This is Paul Carduners GSOC project, BTW. From jeroen.vloothuis at xs4all.nl Sat May 26 01:59:31 2007 From: jeroen.vloothuis at xs4all.nl (Jeroen Vloothuis) Date: Sat, 26 May 2007 01:59:31 +0200 Subject: [Kss-devel] Why not to use KSS? In-Reply-To: <4657560D.70004@xs4all.nl> References: <200705241201.03183.srichter@cosmos.phy.tufts.edu> <21a6ef160705250345x178419d8tc6fc95be5ce89ad9@mail.gmail.com> <4657560D.70004@xs4all.nl> Message-ID: During a chat session with Martijn we came to the following list of problems with the current state of KSS. Note that these are my interpertations of his objections. Anything might be misrepresented by me (so don't blame him ;-). Problem descriptions: Problem number one is the filesize. KSS is easily on of the biggest JS frameworks out there. Compared to libraries such as JQuery etc. it is massive. To make matters even worse you actually need extra libraries if you want effects or anything similar. The second problem is that KSS adds an extra runtime to the browser. This directly relates to problem one in that it makes the client load greater. A third problem is that KSS is more of a framework than a library. This means you have to drink the cool-aid in order to use it. And the framework point brings us nicely to the final point in that KSS is not flexible enough. Martijn gave some examples of applications in which he wanted more done on the client (on example was filtering a list of options based on some selects etc.). This could be done with KSS but the overhead of writing plugins etc. did not outweigh any advantages (especially not since he wanted less bloated server communication as well). Solution? Of these problems the file size is obviously the biggest issue. More than one person has complained about this on different occasions. Although work has been done on compacting KSS it still is quite heavy and will probably remain so (correct me if I am wrong) until some more drastic measures are taken. One of the options Martijn and I discussed was replacing the current protocol and runtime for something simpler. I may have missed some critical points about the current design so please do not be offended by this (it was just a brain storm). If we would do away with the whole command system and replace it with direct calls to Javascript we could save some bandwidth. It would also allow us to remove the runtime. A final bonus would be that it quires no integration code to work. Let's say a KSS request would return some commands to replace some HTML. This can be changed to something like this: $("div").html("new stuff"); This example assumes you have JQuery installed. It immediately brings us to the problem this solution imposes. At the moment KSS tries to be library agnostic by wrapping everything in custom Javascript code. This means more code on the client and more Javascript in general to maintain. The new system would mean that the server side components need to be specific to the client's libraries. I do not think this will be a big problem. The largest downside to this is the client side actions. These will become library specific as well. The server side code is easy enough to wrap in a library agnostic way. Client side actions will not be possible to wrap (otherwise we will be back at square one). One possible solution to this is to compile the KSS files to Javascript code. This could even be done runtime. Using compiled Javascript for binding would mean we could also drop the client side KSS parsing. This idea would change a lot for KSS. It would stop wrapping functions and provide only the KSS syntax for binding events etc. All document manipulation will be done by directly executing Javascript code. This will cut down on the code needed, make it less of a framework (more a helper system). The overall feel for the developer of a KSS application could remain the same. She would still write KSS files (these will get compiled) and use something like the current commandsets (which just generate something different than HTML/XML). Conclusion: With this post I just want to open some discussion on why KSS works as it is and what its limits are. I did not invent KSS, nor was I part of any of the design discussions. My hope is that this post can act as starting point to discuss the merits and the cons of the current system, nothing more. From gotcha at bubblenet.be Sat May 26 09:16:13 2007 From: gotcha at bubblenet.be (Godefroid Chapelle) Date: Sat, 26 May 2007 09:16:13 +0200 Subject: [Kss-devel] Why not to use KSS? In-Reply-To: References: <200705241201.03183.srichter@cosmos.phy.tufts.edu> <21a6ef160705250345x178419d8tc6fc95be5ce89ad9@mail.gmail.com> <4657560D.70004@xs4all.nl> Message-ID: <4657DEBD.10302@bubblenet.be> Hi Jeroen, Thanks for taking the time to chat with Martijn ! I was wondering what were his thoughts : I am very happy to be able to go through them. I'll be giving my thoughts about this mail on this list asap. But I'll take time to make a wise answer (sic) rather than an emotional one... Jeroen Vloothuis wrote: > During a chat session with Martijn we came to the following list of > problems with the current state of KSS. Note that these are my > interpertations of his objections. Anything might be misrepresented by > me (so don't blame him ;-). > > Problem descriptions: > > Problem number one is the filesize. KSS is easily on of the biggest JS > frameworks out there. Compared to libraries such as JQuery etc. it is > massive. To make matters even worse you actually need extra libraries if > you want effects or anything similar. > > The second problem is that KSS adds an extra runtime to the browser. > This directly relates to problem one in that it makes the client load > greater. > > A third problem is that KSS is more of a framework than a library. This > means you have to drink the cool-aid in order to use it. > > And the framework point brings us nicely to the final point in that KSS > is not flexible enough. Martijn gave some examples of applications in > which he wanted more done on the client (on example was filtering a list > of options based on some selects etc.). This could be done with KSS but > the overhead of writing plugins etc. did not outweigh any advantages > (especially not since he wanted less bloated server communication as well). > -- Godefroid Chapelle (aka __gotcha)- BubbleNet http://bubblenet.be From apm13 at columbia.edu Sat May 26 17:59:28 2007 From: apm13 at columbia.edu (Alec Mitchell) Date: Sat, 26 May 2007 08:59:28 -0700 Subject: [Kss-devel] Why not to use KSS? In-Reply-To: References: <200705241201.03183.srichter@cosmos.phy.tufts.edu> <21a6ef160705250345x178419d8tc6fc95be5ce89ad9@mail.gmail.com> <4657560D.70004@xs4all.nl> Message-ID: <365118370705260859j71796f0ah7cbd99cb11111a06@mail.gmail.com> The following are my thoughts on these objections, they are all reasonable and vaild. However, I think the problems are perhaps not all quite as serious as they might seem. My perspective is that of someone who has been using the system extensively, but is not involved in its development or design. On 5/25/07, Jeroen Vloothuis wrote: > During a chat session with Martijn we came to the following list of > problems with the current state of KSS. Note that these are my > interpertations of his objections. Anything might be misrepresented by > me (so don't blame him ;-). > > Problem descriptions: > > Problem number one is the filesize. KSS is easily on of the biggest JS > frameworks out there. Compared to libraries such as JQuery etc. it is > massive. To make matters even worse you actually need extra libraries if > you want effects or anything similar. I've been running in production with gzipped js (using mod_deflate). While the total amount of js is certainly larger since I started depending on kss, it's still inder 80 Kb for all of the plone js including KSS (though without prototype, mochikit, and effects.js, which I don't currently use). For me, this makes the bandwidth issue relativley negligable. > The second problem is that KSS adds an extra runtime to the browser. > This directly relates to problem one in that it makes the client load > greater. Indeed, but doesn't any js library suffer from this issue? I haven't noticed much delay except of course when there are kss actions to process. The time it takes to bind the actions can be significant, but this seems mostly due to cssQuery and the way it is called. The top 4 calls during page load are calls in cssQuery (all to toString and thisElement) and they take up 86% of the total js load time (1.5 secs, with js profling and all logging on). It's the 151 calls to toString which really kill performance, they account for 70% of the time (the 10815 calls to thisElement only take 15% of the time, which may also be worth optimizing). The kicker is that the median call to to toString is quite fast (a few ms as one would expect), but one of the calls to it takes 0.84 sec. This implies that some tremendously large object is being passed by cssQuery into toString, and this seems like something quite fixable (if perhaps hard to track down). This may be an issue with the way kss uses cssQuery (which I know nothing about), or a fundamental issue with cssQuery (which Plone has depended on for some time). Removing logging from production seems to help a bit, but obviously there are still performance problems. > A third problem is that KSS is more of a framework than a library. This > means you have to drink the cool-aid in order to use it. > > And the framework point brings us nicely to the final point in that KSS > is not flexible enough. Martijn gave some examples of applications in > which he wanted more done on the client (on example was filtering a list > of options based on some selects etc.). This could be done with KSS but > the overhead of writing plugins etc. did not outweigh any advantages > (especially not since he wanted less bloated server communication as well). I think anything that does AJAX requires a good amount of buy-in, at least in my experience (using raw sarissa and mochiKit). However, the amount of really nice functionality I've been able to get without writing a single line of js, and with fairly little straightforward python on the server side. The protocol bloat is a slight issue (though only with the response), but gzipping output helps this a bit, and the transparency of the format is really nice to have when debugging issues. I agree that the overhead of writing a client side plugin seems higher than the advantages gained. But, in the end making a client side plugin is generally only a couple extra lines wrapping whatever existing js you're using to register it as a plugin and pass it the expected parameters. There's nothing to stop you from using whatever client side scripting you want, and then wrapping it only when you want to start applying it generally based on KSS rules or when you want to make it available publicly. This isn't AJAX though. The big issue is that the plugins available from the server side are limited. So far they meet my needs, even if it means I need to send a bigger chunk of html than is strictly necessary (again, this is partly remedied by gzipping). And I imagine writing a plugin t handle data from the server side is daunting (I haven't needed to), and the immediate benefit, vs writing custom handling in js is nil. The benefit is that, once written, such a plugin can be used by people who don't write js to do completely different things. > Solution? ... > Let's say a KSS request would return some commands to replace some HTML. > This can be changed to something like this: > > $("div").html("new stuff"); I have wished at times to be able to call a specific js method on some data from the server side. But I don't know if it would be worth ditching the xml, which is quite easy to debug (maybe because if its inherent limitations). I think this would be a hard sell for the KSS folks, because the command language is a big part of what it's all about IMO, but this is an interesting idea to consider for making the server side more flexible, and the runtime and protocol lighter. ... My 2 cents, Alec From apm13 at columbia.edu Sat May 26 18:02:09 2007 From: apm13 at columbia.edu (Alec Mitchell) Date: Sat, 26 May 2007 09:02:09 -0700 Subject: [Kss-devel] Why not to use KSS? In-Reply-To: <365118370705260859j71796f0ah7cbd99cb11111a06@mail.gmail.com> References: <200705241201.03183.srichter@cosmos.phy.tufts.edu> <21a6ef160705250345x178419d8tc6fc95be5ce89ad9@mail.gmail.com> <4657560D.70004@xs4all.nl> <365118370705260859j71796f0ah7cbd99cb11111a06@mail.gmail.com> Message-ID: <365118370705260902w3175bdc0g926b06381be4784b@mail.gmail.com> On 5/26/07, Alec Mitchell wrote: ... > I think anything that does AJAX requires a good amount of buy-in, at > least in my experience (using raw sarissa and mochiKit). However, the > amount of really nice functionality I've been able to get without > writing a single line of js, and with fairly little straightforward > python on the server side. The protocol bloat is a slight issue > (though only with the response), but gzipping output helps this a bit, > and the transparency of the format is really nice to have when > debugging issues. Oops, I meant to say something nice abut the large amount of functionality I've been able to get without any js, but somehow left that bit of the sentence out. :-) Alec From novotny.radim at gmail.com Sat May 26 19:16:47 2007 From: novotny.radim at gmail.com (Radim Novotny) Date: Sat, 26 May 2007 19:16:47 +0200 Subject: [Kss-devel] currentFormVar and list of checkboxes Message-ID: Hello all, I'm trying to create funcionality similar to KSSMasterSelectWidget. Everything works as expected (changing of fields visibility) but I'v found a bug in currentFormVar. I'm using azax 1.1 (SVN checkout of http://codespeak.net/svn/kukit/azax/branch/1.1), Zope 2.9, Plone 2.5.3. I have base_edit form which contains several s. I'v been digging into forms.js, method kukit.fo.getValueOfFormElement http://codespeak.net/svn/kukit/kukit.js/trunk/kukit/forms.js if "element" is list of checkboxes, "null" is returned. It seems this method is missing something like there is done for "list of radios" > } else if (typeof element.length != 'undefined' && typeof element.item != 'undefined' && element.item(0).type == "radio") { > var radioList = element; > value = null; > for (var i=0; i < radioList.length; i++) { > var radio = radioList.item(i); > if (radio.checked) { > value = radio.value; > } > } I'v added similar code block for element.item(0).type == "checkbox" and tried to return array of selected values, but I'v got error message about invalid response (it seems response parser does not like arrays?) client_reason="Response parsing error: ResponseParsingError: Unknown server error (invalid KSS response, no error info received)" I have no idea what is done with this response so I can't provide more informations. Btw, my goal is to display formatted text from several fields user selected, for example: Your selection: ...someitem... and these values: Checkbox1, Checkbox5, Checkbox7. The formatted text should change with every selection change. This works for me, except the checkboxes. Second, less important bug, is in logging part of method kukit.fo.getFormVar. If "element" is list of items, there is logged "undefined" or something like that, instead of element.tagName or element.name. Thank you for feedback, -- naro From jeroen.vloothuis at xs4all.nl Sun May 27 00:03:06 2007 From: jeroen.vloothuis at xs4all.nl (Jeroen Vloothuis) Date: Sun, 27 May 2007 00:03:06 +0200 Subject: [Kss-devel] Why not to use KSS? In-Reply-To: <365118370705260859j71796f0ah7cbd99cb11111a06@mail.gmail.com> References: <200705241201.03183.srichter@cosmos.phy.tufts.edu> <21a6ef160705250345x178419d8tc6fc95be5ce89ad9@mail.gmail.com> <4657560D.70004@xs4all.nl> <365118370705260859j71796f0ah7cbd99cb11111a06@mail.gmail.com> Message-ID: <4658AE9A.8050906@xs4all.nl> Alec Mitchell wrote: >> Problem number one is the filesize. > > I've been running in production with gzipped js (using mod_deflate). > While the total amount of js is certainly larger since I started > depending on kss, it's still inder 80 Kb for all of the plone js > including KSS (though without prototype, mochikit, and effects.js, > which I don't currently use). For me, this makes the bandwidth issue > relativley negligable. 80Kb for the whole of Plone seems reasonable to me as well. One of the problems I have with comments like it is to big is that there is no clear goal for how big something should be. Smaller is always better but for something like this (that is cached) it depends a lot on the use case. Good to know that using mod_deflate makes such a difference though. >> The second problem is that KSS adds an extra runtime to the browser. >> This directly relates to problem one in that it makes the client load >> greater. > > Indeed, but doesn't any js library suffer from this issue? I haven't > noticed much delay except of course when there are kss actions to > process. The time it takes to bind the actions can be significant, > but this seems mostly due to cssQuery and the way it is called. The > top 4 calls during page load are calls in cssQuery (all to toString > and thisElement) and they take up 86% of the total js load time (1.5 > secs, with js profling and all logging on). It's the 151 calls to > toString which really kill performance, they account for 70% of the > time (the 10815 calls to thisElement only take 15% of the time, which > may also be worth optimizing). The kicker is that the median call to > to toString is quite fast (a few ms as one would expect), but one of > the calls to it takes 0.84 sec. This implies that some tremendously > large object is being passed by cssQuery into toString, and this seems > like something quite fixable (if perhaps hard to track down). This > may be an issue with the way kss uses cssQuery (which I know nothing > about), or a fundamental issue with cssQuery (which Plone has depended > on for some time). > > Removing logging from production seems to help a bit, but obviously > there are still performance problems. Are you experiencing any serious issues or is this more in line with faster is (always) better? >> A third problem is that KSS is more of a framework than a library. This >> means you have to drink the cool-aid in order to use it. > > I think anything that does AJAX requires a good amount of buy-in, at > least in my experience (using raw sarissa and mochiKit). However, the > amount of really nice functionality I've been able to get without > writing a single line of js, and with fairly little straightforward > python on the server side. I think there may also be some conceptual difference on how to do Ajax. KSS is pretty much a what you see is what you get approach. It is aimed and working on the DOM. Some people may prefer a different approach in which they make the browser something more of a client application. In this case you only want to transfer data and do all coding on the client. > The protocol bloat is a slight issue > (though only with the response), but gzipping output helps this a bit, > and the transparency of the format is really nice to have when > debugging issues. I think using something like JSON instead of the current HTML/XML could help here as well. You would basically still keep the same structure but safe some of the verboseness. This may not make a big difference though. Because in most KSS usage you would send quite a bit of HTML for replacement operations as well. Again your suggestion of gzipping would solve it transparently. > I agree that the overhead of writing a client side plugin seems higher > than the advantages gained. But, in the end making a client side > plugin is generally only a couple extra lines wrapping whatever > existing js you're using to register it as a plugin and pass it the > expected parameters. There's nothing to stop you from using whatever > client side scripting you want, and then wrapping it only when you > want to start applying it generally based on KSS rules or when you > want to make it available publicly. This isn't AJAX though. I hope that with some more documentation we can lower the barrier so that anyone can easily what to do to create a plugin. In most cases plugins should not be needed though due to way KSS works. It may be good to have some smallish (semi) real life examples of how to do certain things with KSS. This would help with explaining the usage of kss attributes etc. > The big issue is that the plugins available from the server side are > limited. So far they meet my needs, even if it means I need to send a > bigger chunk of html than is strictly necessary (again, this is partly > remedied by gzipping). And I imagine writing a plugin t handle data > from the server side is daunting (I haven't needed to), and the > immediate benefit, vs writing custom handling in js is nil. Have you looked at the recent tutorials on this subject? I would appreciate any feedback on these if they are in any way unclear. > I have wished at times to be able to call a specific js method on some > data from the server side. It should be possible to create a plugin which will in effect evaluate any data passed in. This may make a useful addition to the core set. By having such a command we can ease the learning curve a bit. It would also allow you to recycle existing knowledge. Thanks for your thoughts and feedback :-)