[Helma-user] Server-side DOM

[Chris Zumbrunn]

On Jul 11, 2007, at 15:44 , Joshua Paine wrote:

> Chris Zumbrunn wrote:
>> One "problem" when using it
>> inside of Helma is that is pollutes the global namespace with the
>> browser DOM objects and properties (to avoid that, it would need to
>> be run inside a separate js scope).
>
> It would seem like this could be achieved with some minor  
> modifications
> of env.js (and possibly jquery.js) and clever use of closure, don't  
> you
> think?

With modifications of env.js and jquery.js it would be possible, yes.  
But that would be a pain to maintain.

jQuery is extreme good about being able to be encapsulated inside of  
closures. But as far as the DOM is concerned, it really counts on  
that being global. I've already tried to work around it with closures  
and still think it might work, but didn't get there when playing with  
it yesterday.

> What I'd really like is jQuery-style XML querying and modification in
> ways that make sense on the server-side.

Yes, like being able to use jQuery to query and modify E4X objects.  
And then use these E4X objects as "skins".

>> make the global vars sticky using the following
>> defineLibraryScope calls:
>
> I'm still trying to get my head around Helma's application model. Can
> you explain what defineLibraryScope does and why it's necessary?

Over the last year or two we went back and forth between whether  
defineLibraryScope is needed or not. It was deprecated and  
undeprecated several times, and it was even removed once completely  
only to be added back in. So, you are not the only one that is  
confused about it :-)

To top it off, the reason why it is needed has changed over time  
because some default behaviors in Helma changed, regarding how Helma  
handles the global scope for requests AND how it clears the global  
scope when code files of a running application are updated AND when  
an additional code repository is added dynamically during runtime.

Helma now copies the application's global scope to a "global scope  
per request" and disposes of that per-request-scope after the request  
handling has been completed.

Modifications of global vars that are set "in the global  
code" (meaning, not dynamically at runtime, but when a code  
repository is added, at startup, or after a code update) will be  
synched back to the application's global scope. But if you create a  
global var "dynamically at runtime", during the processing of a  
request, it will be cleared and will be undefined in the global scope  
of the next request.

That's where defineLibraryScope comes to the rescue. Using it, you  
can declare that a global var should survive between requests, even- 
though it wasn't defined in the global code.

There are good reasons for the change to using per-request global  
scopes the way it is done now in Helma 1.6, but I think the way this  
all behaves now isn't perfect yet. For example, the new behavior  
breaks the use of closures inside the global code, if the code inside  
those closures needs to add properties to the global object (Is this  
a bug?). That's exactly what env.js and jquery.js try to do.

Having said all that ;-) ...in this particular case we could avoid  
using defineLibraryScope and instead simply define the vars like this:

var window,navigator,location,setTimeout, ...etc

...but that only works in the global code. When global vars need to  
be added later dynamically, we *do* need defineLibraryScope.

Chris