You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by "Jay D. McHugh" <ja...@joyfulnoisewebdesign.com> on 2006/10/05 23:39:44 UTC

Re: dojo in Geronimo (long)

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 <ja...@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

Re: dojo in Geronimo (long)

Posted by "Jay D. McHugh" <ja...@joyfulnoisewebdesign.com>.
Jason Dillon wrote:
>
> I've done this more times than I'd like to remember, even from a web 
> app... lemme know if you want a code snip.

A code snip would be great - Being able to initiate the built in dojo 
build would be much simpler that parsing and rebuilding the javascript 
code myself.

Jay

Re: dojo in Geronimo (long)

Posted by Jason Dillon <ja...@planet57.com>.
Invoking Ant from code is trivial.  Create a Project, initialize it,  
create a Task, configure it, execute it.

I've done this more times than I'd like to remember, even from a web  
app... lemme know if you want a code snip.

--jason


On Oct 7, 2006, at 12:27 AM, Jacek Laskowski wrote:

> On 10/6/06, Jay D. McHugh <ja...@joyfulnoisewebdesign.com> wrote:
>
>> But, how would you trigger ant from a servlet?
>
> Don't know how much it matters, but Ant is a bunch of Java classes so
> a servlet can instantiate some and execute some kind of startup method
> where Ant will get kicked off.
>
> Jacek
>
> -- 
> Jacek Laskowski
> http://www.laskowski.net.pl


Re: dojo in Geronimo (long)

Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 10/6/06, Jay D. McHugh <ja...@joyfulnoisewebdesign.com> wrote:

> But, how would you trigger ant from a servlet?

Don't know how much it matters, but Ant is a bunch of Java classes so
a servlet can instantiate some and execute some kind of startup method
where Ant will get kicked off.

Jacek

-- 
Jacek Laskowski
http://www.laskowski.net.pl

Re: dojo in Geronimo (long)

Posted by "Jay D. McHugh" <ja...@joyfulnoisewebdesign.com>.
Paul McMahan wrote:
> If you pull the dojo src tree from svn there is an additional
> directory at buildscripts/profiles.  You can use ant to build a custom
> dojo.js based on the profiles in there.  Seems like the servlet could
> get passed a profile name and invoke ant to create the custom dojo.js
> on the fly.  The output could be cached on disk for subsequent
> requests.  This would allow us to use dojo's built in mechanism for
> creating customized profiles (adding additional ones if necessary) and
> make it easy to upgrade dojo without having to up rebuild a database
> or update the servlet code.  Does this make sense?
That does make sense Paul.

But, how would you trigger ant from a servlet?

Jay

Re: dojo in Geronimo (long)

Posted by Paul McMahan <pa...@gmail.com>.
If you pull the dojo src tree from svn there is an additional
directory at buildscripts/profiles.  You can use ant to build a custom
dojo.js based on the profiles in there.  Seems like the servlet could
get passed a profile name and invoke ant to create the custom dojo.js
on the fly.  The output could be cached on disk for subsequent
requests.  This would allow us to use dojo's built in mechanism for
creating customized profiles (adding additional ones if necessary) and
make it easy to upgrade dojo without having to up rebuild a database
or update the servlet code.  Does this make sense?

Paul

On 10/5/06, Jay D. McHugh <ja...@joyfulnoisewebdesign.com> wrote:
> 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
>