If you pull the dojo src tree from svn there is an additional directory at buildscripts/profiles. You can use ant to build a custom dojo.js based on the profiles in there. Seems like the servlet could get passed a profile name and invoke ant to create the custom dojo.js on the fly. The output could be cached on disk for subsequent requests. This would allow us to use dojo's built in mechanism for creating customized profiles (adding additional ones if necessary) and make it easy to upgrade dojo without having to up rebuild a database or update the servlet code. Does this make sense?
Paul On 10/5/06, Jay D. McHugh <[EMAIL PROTECTED]> wrote:
Hello all, Thought I would throw out the basic frame of what I -think- we would need to do in order to make a dynamic 'dojo.js builder' servlet. First, we would need to spin through all of the dojo source code and assemble the dependencies of everything. I would suggest that this would be stored in a database (probably derby since it's handy). As a second step (or as part of the first) we would need to capture all of the dojo source code in a database as well so that when the servlet receives a request it has the code available to assemble. I originally thought that we might want to make a method in the servlet for each javascript function or library - but I think that would make the assembly of the code more complicated. Lastly (and the easiest step) we would need to write the servlet to receive one or more requirements that would be used to specify how much would need to be pulled in. I think requirements might be a better parameter to specify than widgets and it follows along with how dojo is organized - providers and require-ers. -OR- A simpler version would be to have our base dojo.js be the 'kitchen-sink' distribution (that is really what it is called by the way) and only specify widgets. Each widget and its dependencies would be stored in a method of the servlet and be included along with the base 'dojo.js' that is sent down from the server. Between these, I think the first one is really the better of the two because it could actually send down only what is needed - cutting down the bandwith used (the real purpose of the whole exercise). The second has a strong likelihood of introducing a lot of redundancy in the code that is sent. And that would probably make the library end up either inconsistent or plain old broken (if there are two dojo.doSomething functions, which gets run?). Also, I think we have a better chance of developing an automated process to parse the dojo source all the way down to its smallest pieces. The second choice (that I thought of anyway - there may be more options so if you have one, speak up) would probably just be an ugly manual process that would have to be done each time a new version of dojo comes out. Thoughts? Jay
