Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Message-ID: <45257BA0.9050505@joyfulnoisewebdesign.com>
Date: Thu, 05 Oct 2006 16:39:44 -0500
From: "Jay D. McHugh" <jay@joyfulnoisewebdesign.com>
User-Agent: Thunderbird 1.5 (X11/20060204)
MIME-Version: 1.0
To: dev@geronimo.apache.org
Subject: Re: dojo in Geronimo (long)
References: <452523D6.60403@joyfulnoisewebdesign.com>
 <21df75940610051334o408dfacbxe1f0d34507560561@mail.gmail.com>
In-Reply-To: <21df75940610051334o408dfacbxe1f0d34507560561@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Paul McMahan wrote:
> You raise a good point and it sounds like the idea would work, but I'm
> concerned it could lead to a proliferation of dojo webapp components,
> one for each custom configuration.   I wonder if it might be possible
> to instead create a servlet in the current dojo app that could build
> and cache custom configurations on the fly.  That way we could keep
> the current standard library in place for unoptimized dojo apps but
> still serve up customized configurations from this same location for
> optimized dojo apps.
>
> Off the top of my head, invoking the servlet could look something like:
> /dojo/dojo?widget1=tree&widget2=table&...
>
> This approach also keeps us in line with some of the other motivations
> for making dojo a native component in the server -- easy to upgrade,
> easy to reference from deployment plans, keeps the server footprint to
> a minimum, etc.
>
> Best wishes,
> Paul
>
>
> On 10/5/06, Jay D. McHugh <jay@joyfulnoisewebdesign.com> wrote:
>> Hello all,
>>
>> I finally managed to get my project development/testing server up and
>> working on 1.2-snapshot (Thanks again djencks!).
>>
>> And I finally got to see the JMX console that was added - Which is very
>> cool.
>>
>> But, I think that it brings to light a performance issue.  Because we
>> are using dojo widgets that are not 'bundled' into the dojo.js library,
>> we end up pulling down -many- individual files to support the widgets.
>>
>> I think we should consider building our own dojo bundle (I'm going to
>> start looking into exactly how to do this) and deploying it to something
>> like /geronimo-dojo and using that for console apps.  Pulling the one
>> (slightly larger) library -should- increase response time since we won't
>> need all of the extra file requests/responses going over the wire.
>>
>> I do like having dojo deployed to /dojo built into the server though and
>> would like to keep the base library there (so far I have just been using
>> the AJAX portion of dojo in my own apps - so I haven't needed any 
>> widgets).
>>
>>
>>
>> Does anyone have any thoughts about this?
>>
>>
>> Jay
>>
>
>
>
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