geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shrey Banga" <banga.sh...@gmail.com>
Subject Re: Reducing the dojo footprint in Geronimo
Date Wed, 30 Jul 2008 16:52:48 GMT
Joseph,

I think creating a slim version (like mydojo.js) would be, as I pointed out
earlier, useless and also not needed. My proposal was to simply get rid of
the dojox components (ie remove the dojox folder). What you suggest is
creating one giant preprocessed javascript that has all the dojo, dijit
components. For one, this js will be massive and therefore unusable and you
would basically subvert the dojo.require process which is similar to import*
ing* required components as needed in java. Also, as you said this is a
maintenance nightmare.
The reason for me to mention the dojo builder which creates a single js was
for supporting the webapps which currently use dojox once that is removed
from G. For those we could perhaps create a single js with the required
components.
So here is the updated list of options:

1) Removing Dojo from AG and having users include their own optimized Dojo
files for their apps. The downside is that we may be inefficient in
aggregating multiple copies of Dojo.

2) Leave Dojo support in AG as is now. We can safely rely on the fact that
their will be no duplicate instances of dojo for those who use it, but we
must now rely on having that dojo overhead even for users who don't utilize
it.


3) Creating a slim version of Dojo essentially by removing the dojox folder
and creating custom built js for any components that might still need the
dojox functionality. Maintaining these customized scripts might be something
that could pose a problem. Finally, we could have a plugin with complete
dojo support for applications demanding extra web 2.0 functionality.

I would still say that since dojox is considered experimental, developers
should be wary of using those features as they are subject to modifications.

On Wed, Jul 30, 2008 at 9:39 PM, Joseph Leong <josephcleong@gmail.com>wrote:

> Kevan,
>
> I am far from having the complete picture, but my understanding for #3:
> According to a post from Donald previously, this link is very good
> reference for what process is involved:
> http://dojotoolkit.org/book/dojo-book-0-9/part-4-meta-dojo/package-system-and-custom-builds,
in creating our slim  'mydojo.js'.
>
> As for the maintenance, i see the scenarios where every app using dojo will
> now need to cross reference with what is available in mydojo.js to see if
> the feature they want to use is already included.  If not we'll have to
> re-generate a new slim version of our 'mydojo.js' with the features added.
> Furthermore, when an app becomes obsolete or is removed, we will need to
> regenerate a new mydojo.js to remove the unnecessary components.
>
> On the user level, I also see some inefficiency where if one wants to
> deploy a product on AG that uses some dojo subsets which is not in our
> generated mydojo.js, they'd have to include their own copy of dojo.
>
> -Joseph Leong
>
>
> On Wed, Jul 30, 2008 at 10:59 AM, Kevan Miller <kevan.miller@gmail.com>wrote:
>
>>
>> On Jul 29, 2008, at 3:36 PM, Joseph Leong wrote:
>>
>> Hi everyone,
>>
>> So i'm building a little widget piece to run on AG and i've come to the
>> point of deciding whether i'm going to incorporate any (if) dojo/dojox
>> components into it.  I know we've had varying discussions about reducing the
>> dojo footprint.  To summarize i believe the only thing we've agreed on so
>> far is removing the unncessary /tests , but i'm wondering if the community
>> had anymore input on keeping dojox around?  To summarize it is my
>> understanding these are the choices suggested so far:
>>
>> 1) Removing Dojo from AG and having users include their own optimized Dojo
>> files for their apps. The downside is that we may be inefficient in
>> aggregating multiple copies of Dojo.
>>
>> 2) Leave Dojo support in AG as is now. We can safely rely on the fact that
>> their will be no duplicate instances of dojo for those who use it, but we
>> must now rely on having that dojo overhead even for users who don't utilize
>> it.
>>
>> 3) Creating a slim version of Dojo to support the features relying on it
>> in AG, thus allowing users who want to demonstrate fundamental dojo features
>> to utilize it - but however we incur the maintenance overhead of creating
>> new builds of Dojo to incorporate with AG releases as new fundamental AG
>> components with Dojo are included.
>>
>> Personally, I feel the functionality subset of DojoX captures a lot of
>> what this Web2.0 era is looking for.  Although it may make more sense to go
>> with option 3, now, i feel it's only a matter of time before we switch over
>> to option 2.  To provide the community with a better grasp of what the DojoX
>> functionalities are goto: http://dojocampus.org/explorer/#Dojox and
>> you'll find yourself quite surprised at how innovative and integrated these
>> technologies are influencing your favorite sites.
>>
>>
>> Thanks a lot for picking this up, again, Joseph.
>>
>> Personally, I'd like to see the Dojo footprint within Geronimo reduced.
>> It's pretty simple to make a full-Dojo plugin that users can install, if
>> they want a full Dojo library available. IMO, this can meet the needs of
>> Dojo users (as described in #2).
>>
>> Can you help me understand the maintenance overhead of creating a
>> customized Dojo library? If #3 is high maintenance, I may need to
>> reconsider.
>>
>> --kevan
>>
>>
>


-- 
Shrey Banga
Bachelor of Technology, III year
Department of Electrical Engineering
Indian Institute of Technology Roorkee

Mime
View raw message