[Bese-devel] Keeping the core library separate from the extensions

[Lou Vanek]

Marijn Haverbeke wrote:
> I'd like to hear people's thoughts about the idea of making a clear 
> distinction between the core UCW library (request-response loop, frames, 
> components, actions), andl the extensions to this system (input fields, 
> validators, dojo stuff, some of the things Attila is brewing up in the 
> ajax branch), possibly also separating the extensions into different 
> modules. I personally think this would have the advantage of clarity, 
> and of being able to re-use the core in widely different ways (we're all 
> hackers who like to re-invent stuff) without having to 'fight' the library.
> 
> For one thing, I feel that the javascript that is generated when you 
> make a form call an action should be optional. It doesn't really serve a 
> purpose in the general case, and I'm not using it, but it is dragging in 
> the whole dojo dependency. I know just including dojo.js won;'t kill me, 
> but I'm something of an HTML minimalist who hates to have cruft in his 
> pages that is not necessary. (I can't help it.) I still haven't really 
> studied the ajax branch, but I'm a bit worried that there will be a 
> rather strong coupling between Attila vision of an UCW app and the 
> library itself.
> 
> 
> Hope to hear your reactions,
> Marijn

I completely agree. You've put into words what I have only recently
come to understand. UCW is turning into an intranet framework, which
wouldn't bother me at all if the extra cruft were optional, but
in some cases it isn't. Just to do a 302 redirect you have to make
sure you've downloaded a 130K+ javascript file first, and this op can
happen frequently. I know the js should have been cached, but this
is a symptom of how the framework is requiring too much bandwidth. I
have to admit I haven't tried the ucw_ajax branch, though, so maybe
Attila has successfully incorporated dojo. If ucw_ajax were a module
i would have already downloaded and seen first hand.

FOR YOUR CONSIDERATION

I would like to see ucw_ajax modularized just like Evrim has done
with ucw+. I think ucw+ is wonderful but i have recently decided it's
too heavy for some conventional web sites. I don't know exactly why
dojo is taking so long to download and configure itself, but it's
noticable and probably not an acceptable time delay. Even on my 3GHz
computer with 0 wire-delay I get a little anxious waiting for some
pages that have dojo in them to load. Over a LAN this wouldn't worry
me. Over a WAN it does.

If ucw_dev needs js at all it should be at a bare minimum (say 10K
compressed js library code). That would mean dojo would no longer be
apart of the ucw_dev branch unless it can be completely turned off or
alternatively mixed in.

Changing validation so that it isn't a drain on page loads
is not that hard: just load the validation code AFTER the
form has completely loaded in the browser. I've done this in
the past and this solves several problems. The validation
code doesn't have to be super-small because the download is
being done in the background, and the page appears to load
quicker. (BTW, an excellant 'delay-eval' module can be found at
http://www.thefutureoftheweb.com/blog/2006/6/adddomloadevent. It's
less than 900 bytes.)

If ucw continues on its current path it will splinter--the main
branch may appear intact but the devs and hobbyists using the code
base will be forced to hack it to be more internet-friendly. Evrim
has already proven that it's possible to modularize the heavy js
out. Now the core team should decide whether to modularize ucw_ajax
or instead turn it into the trunk and thus make dojo a fixed requirement.
I hope they choose the former, but maybe somebody else knows of a
better solution.

I wish this weren't necessary but apparently it is. 99% of everything
I said is just opinion and may be entirely wrong, at least from other
people's perspectives. Just one data point.

-lv