[dojo-contributors] Prototype-al simplicity

James Burke jburke at dojotoolkit.org
Sat Apr 8 01:04:29 EDT 2006


On 4/7/06, Tom Trenka <ttrenka at gmail.com> wrote:
>
> On dojo.io, the only suggestion I might make is to maybe pull the back
> button handling into a separate, optional mixin?  Seems to me that even
> though it's large, there's a reason for it--and with that one I'd hate to
> pull any functionality to make it smaller.

I would be in favor of pulling dojo.undo.browser out of a dojo-lite
build. I almost made it a conditional dependency in BrowserIO.js and
ScriptSrcIO.js, but I was still learning things and didn't want to try
anything too ambitious. I would be OK with the following:

- Remove the dojo.undo.browser require from the files mentioned above.
- Test for the existence of the dojo.undo.browser in those files
before attempting to call addToHistory by using a check like:
if(dojo.evalObjPath("dojo.undo.browser")). If it didn't exist, then
don't call addToHistory (maybe in that case, log a debug message)?
- Then perhaps we can remove preventBackButtonFix: true from the
default dojo.hostenv config in bootstrap1.js.

That last item would have the added benefit of making
dojo.undo.browser easier to use -- just include dojo.undo.browser to
get back/forward support, instead of making sure it is included, and
also up a djConfig value that is like a double negative. We would
still check for the param in dojo.undo.browser for backward
compatibility.

But that is just me. Alex may have other thoughts. But it might help
with the size issue, and using dojo.undo.browser also requires the
iframe_history.html file: something that might make a dojo-lite
install a little harder to explain. The message would change from
"just use this one (or two) scripts and you are good to go", to
something like "use these scripts, then be sure to place this html
file in a certain directory relative to the scripts, blah, blah,
blah".

James



More information about the dojo-contributors mailing list