Max Pfingsthorn wrote:
On 11/20/05 10:28 AM, "Antonio Gallardo" <[EMAIL PROTECTED]> wrote:
...
About Dojo, one of the concerns is that it takes longer initializing on
the client. Maybe it is just due the internet wire. Let me explain,
seems like dojo use a load on demand scheme to load the required JS
files, hence it connects back to the server and this takes time, making
the initialization slower. A bug or a feature? Dunno
Dojo has a "compressor" which is supposed to speed up javascript
initialization. See [1]. Not sure if it takes care of making dynamic loads
static, but that would be nice.
In some way it does. Basically, the compressor works with a "profile",
which contains a number or "dojo.require()" instructions (this loads JS
code on-demand without <script> tags). The compressor then concatenates
all the required files and their dependencies in a single JS file that
is compressed (i.e. whitespace removed and private symbols shrinked).
So the idea is to have the full expanded sources at development time and
use compressed profiles (for both Dojo and Cocoon JS files) for deployment.
...
Then the question is. How we will approach?
A. Having our own AJAX code in cocoon
B. Using one of the AJAX frameworks outthere.
I prefer to go for A. until the dust go out in the AJAX world. Seems
like every week is an annuncement of a new AJAX framework now!
But if B. is the way to go, then please share with us wich one is the
best for us.
I would definitely go with B. Personally, I think maintaining such a library
would just be way too much work. Seeing what sort of people work on Dojo, we
probably can be sure that it will be around and maintained for a while.
Exactly. There are many frameworks and articles emerging every day, but
most of them are just crap (see [2]). Dojo has been there for some time,
is developed by experienced JavaScript people (they were doing cool
stuff before the Ajax hype) and its development is community-driven.
...
---------- 0 -----------------
Also, with the suggestion-list we can also create a new multivalue
widget rendering. One without an selection-list but with one
suggestion-list using AJAX.
Usecase: You need to define a group of 10 users from a list of 200+
potential users. Is this too specialized or do you think it makes sense?
I like the idea. You mean sort of by populating a list with entries from a
suggestion-list?
That should be a special styling of the widget, based on the same
infrastructure used by suggestion-lists. Actually, the main difference
between selection and suggestion is that selection is a closed choice
whereas suggestion is an open choice.
Now implementation-wise, we have the problem that the point in the
pipeline where we know if the full list is needed or not (in the XSL) is
too far from the generation step (the template). So we either need to
have a hint for this in the form template and/or definition, or find a
way to generate the selection-list in the XSL.
Sylvain
[1] http://dojotoolkit.org/docs/compressor_system.html
[2] http://bluxte.net/blog/2005-11/01-42-13.html
--
Sylvain Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
