Re: dojo quo vadis
Werner, An implied restriction would be only 1 version of DoJo per webapp. Backward compatibility is my main concern. I will upgrade to the latest DoJo in implement in Tomahawk, but it will be the entire application not a page at a time. Paul Spencer My application is using the Dojo in Tomahawk now. Werner Punz wrote: Paul Spencer schrieb: Werner, I am excited to see you are planning to upgrade the DoJo support. I would like to see support for multiple versions, including the one currently in Tomahawk. The desired version to use for any project should be configurable. Hello Paul first thanks for the kind words, anyway dont expect anything too soon. (I am making good progress but there is still a load of work) Multiple versions are planned one way or the other probably I will add a source override flag to enable the loading of another dojo version instead of the default one. If I do that however there will be a culprit the old version will only be usable from the client the components will be adjusted to the latest version. And a mix of 2 versions on one page is not possible, this is a dojo inherent problem. Werner
Re: dojo quo vadis
Werner, I am excited to see you are planning to upgrade the DoJo support. I would like to see support for multiple versions, including the one currently in Tomahawk. The desired version to use for any project should be configurable. Paul Spencer Werner Punz wrote: hello everyone I just wanted to drop a short note, start a discussion here. I was busy the last few weeks regarding dojo after getting weblets 1.0 out of the door. Well here is a plan. As you all know we currently have dojo in Tomahawk, well the main issue is, this is a huge dependency. I have quietly started a small Tomahawk extension framework which should get Dojo out of Tomahawk and should encapsule the most important components. I cannot showcase too much but in a few weeks I will be able to showcase some stuff, depending on the time I can work on it. Ok here is my plan I want to get Dojo and the Dojo Initializer in its own Tomahawk dependend subproject. Dojo itself wont be packed into the sourcetree anymore, but I will move it to weblets (Actually this is working already) so that we can add it as binary dependency and also will get versioning, so that it becomes easier to change dojo versions. This stuff is working already and it works really well. What I have planned additionally, and upgrade to the latest Dojo version and encapsulation of the most important dijit components in their own tags. (This is what I am working on currently, I got my base frameworks mostly stabilized and added some code generation today(The code gens do not overlap with Leonardos and Simons work I took care of that I do not want to duplicate existing code functionalitywise)) And last but not least we have to take a proper look at the sandbox on what we will take also into our dojo extensions stuff, I want the sandbox to become smaller and I do not want a component clutter in the extension lib. This means maybe we might deprecate some sandbox components if possible. Also the moving of the sandbox components means some overhaul and some work to be done, that also means someone have to jump in here and give a helping hand. (Once the other parts are done) Those are my plans what is your opinion about this. The main issue why I started this project is to get dojo out of the tomahawk core and to make it easier to upgrade dojo. Werner
Re: dojo quo vadis
Paul Spencer schrieb: Werner, I am excited to see you are planning to upgrade the DoJo support. I would like to see support for multiple versions, including the one currently in Tomahawk. The desired version to use for any project should be configurable. Hello Paul first thanks for the kind words, anyway dont expect anything too soon. (I am making good progress but there is still a load of work) Multiple versions are planned one way or the other probably I will add a source override flag to enable the loading of another dojo version instead of the default one. If I do that however there will be a culprit the old version will only be usable from the client the components will be adjusted to the latest version. And a mix of 2 versions on one page is not possible, this is a dojo inherent problem. Werner
Re: dojo quo vadis
Paul Spencer schrieb: Werner, I am excited to see you are planning to upgrade the DoJo support. I would like to see support for multiple versions, including the one currently in Tomahawk. The desired version to use for any project should be configurable. Ah Paul sorry for the second answer, this is one thing you might like, you will be able to switch dojo versions on the fly simply be dropping in another weblet jar. So the configuration on project base will be possible. Weblets allows that you can drop in different jars the resources are loaded and versioned properly so that no cache conflicts can occur. The main problem simply by doing this however is another one. I cannot guarantee that the components still work if you drop in a different weblet version than the default one, depending on the version it might work or not. If you just need dojo and adjust the code yourself than this is no big issue. This was one of the main reasons why I added weblets to the entire project. The resource handling is way more convenient with it. If you want to see weblets and dojo in action: http://conference.irian.at/weblets-demo/jspdojotest.jsp This is a testcase I did a while ago, which tests for relative resource loading. The entire dojo toolkit 1.0 is packed as weblet jar and served from the webapp.
dojo quo vadis
hello everyone I just wanted to drop a short note, start a discussion here. I was busy the last few weeks regarding dojo after getting weblets 1.0 out of the door. Well here is a plan. As you all know we currently have dojo in Tomahawk, well the main issue is, this is a huge dependency. I have quietly started a small Tomahawk extension framework which should get Dojo out of Tomahawk and should encapsule the most important components. I cannot showcase too much but in a few weeks I will be able to showcase some stuff, depending on the time I can work on it. Ok here is my plan I want to get Dojo and the Dojo Initializer in its own Tomahawk dependend subproject. Dojo itself wont be packed into the sourcetree anymore, but I will move it to weblets (Actually this is working already) so that we can add it as binary dependency and also will get versioning, so that it becomes easier to change dojo versions. This stuff is working already and it works really well. What I have planned additionally, and upgrade to the latest Dojo version and encapsulation of the most important dijit components in their own tags. (This is what I am working on currently, I got my base frameworks mostly stabilized and added some code generation today(The code gens do not overlap with Leonardos and Simons work I took care of that I do not want to duplicate existing code functionalitywise)) And last but not least we have to take a proper look at the sandbox on what we will take also into our dojo extensions stuff, I want the sandbox to become smaller and I do not want a component clutter in the extension lib. This means maybe we might deprecate some sandbox components if possible. Also the moving of the sandbox components means some overhaul and some work to be done, that also means someone have to jump in here and give a helping hand. (Once the other parts are done) Those are my plans what is your opinion about this. The main issue why I started this project is to get dojo out of the tomahawk core and to make it easier to upgrade dojo. Werner
Re: dojo quo vadis
On Tue, Apr 15, 2008 at 12:08 PM, Werner Punz [EMAIL PROTECTED] wrote: hello everyone I just wanted to drop a short note, start a discussion here. I was busy the last few weeks regarding dojo after getting weblets 1.0 out of the door. Well here is a plan. As you all know we currently have dojo in Tomahawk, well the main issue is, this is a huge dependency. I have quietly started a small Tomahawk extension framework which should get Dojo out of Tomahawk and should encapsule the most important components. +1. I agree with you. I cannot showcase too much but in a few weeks I will be able to showcase some stuff, depending on the time I can work on it. Ok here is my plan I want to get Dojo and the Dojo Initializer in its own Tomahawk dependend subproject. Dojo itself wont be packed into the sourcetree anymore, but I will move it to weblets (Actually this is working already) so that we can add it as binary dependency and also will get versioning, so that it becomes easier to change dojo versions. This stuff is working already and it works really well. What I have planned additionally, and upgrade to the latest Dojo version and encapsulation of the most important dijit components in their own tags. (This is what I am working on currently, I got my base frameworks mostly stabilized and added some code generation today(The code gens do not overlap with Leonardos and Simons work I took care of that I do not want to duplicate existing code functionalitywise)) And last but not least we have to take a proper look at the sandbox on what we will take also into our dojo extensions stuff, I want the sandbox to become smaller and I do not want a component clutter in the extension lib. This means maybe we might deprecate some sandbox components if possible. Also the moving of the sandbox components means some overhaul and some work to be done, that also means someone have to jump in here and give a helping hand. (Once the other parts are done) Those are my plans what is your opinion about this. The main issue why I started this project is to get dojo out of the tomahawk core and to make it easier to upgrade dojo. I would like to see how tomahawk directory looks like after the modification, only to take this into account. One question is if dojo components should be 1.1 or 1.2 compatible (the difference is on the generation of component and tag classes), or both. Werner Regards Leonardo Uribe
Re: dojo quo vadis
Leonardo Uribe schrieb: I would like to see how tomahawk directory looks like after the modification, only to take this into account. One question is if dojo components should be 1.1 or 1.2 compatible (the difference is on the generation of component and tag classes), or both. Well for now we dont have too much dojo components in tomahawk, the main one being the dojo initializer i dont think any other tomahawk component uses it. The sandbox is a different issue, a load of components use it. As for the source base. Currently I am running my own code generation but I will streamline it as soon as you guys are done (I skipped the parsing stage and used direct object definitions via groovy so that I dont repeat what Simon and you are doing anyway) and I had to roll my own templates which I had to do to enable some base frameworks I had to write to make the entire javascript generation easier and to streamline some dojo attributes, which I had to add to the components by delegation (simulated multiple inheritance) Streamlining it is just a matter of a few hours to adjust the groovy and template data structures to the ones in the myfaces codegen. As for the code itself, I am still targetting 1.1 since it is the most important release. I dont think 1.2 will get that much momentum that direct 1.2 targetting makes sense. 1.2 should be possible in the long run. Currenly I have this structure Base Classes for the main control groups (with delegators doing the actual work) - generated classes which do the attribute mapping - hand written derived classes mostly renderer ajustments A shift towards 1.2 is basically adjustment of the base classes and adding templates to the generators! 2.0 is a different issue however, but for 2.0 we probably wont need codegens anymore. (At least from what I have seen from some alpha stage publications on the web, they are definitely on the right track with this one) Another off topic thing Btw. by doing all this I found out that groovy is an excellent replacement for data descriptions, way more tight than pure xml, and you can get the benefit of attribute and typechecking if you use it properly. What I did was to use a base class as defaults and then use closures (or constructor maps as you wish) as overrides to the default values. The result is a very compact data definition which can be used straight as java objects. I did this to get the data model for the codegens as fast as possible and not to cross Leonardos and Simons work on that part with duplicate code. The groovy approach might be an interesting third approach for code generation in the long run for myfaces.
