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, -Joseph Leong On Mon, Jun 30, 2008 at 7:29 AM, Shiva Kumar H R <[EMAIL PROTECTED]> wrote: > > > On Sat, Jun 28, 2008 at 12:04 AM, Donald Woods <[EMAIL PROTECTED]> wrote: > >> Sounds like the right solution, given that would allow our console to >> upgrade at a slower pace and would allow users to choose their own level... >> >> Other option, is to drop the /dojo webapp in 2.2, only ship what we need >> in the console and let users package the Dojo level and features they need >> within their own apps (which is more portable across different servers >> anyway....) >> > > On http://cwiki.apache.org/GMOxDEV/using-dojo-in-geronimo.html we say: > > "AJAX developers usually incorporate the Dojo library into their > applications by making a copy of its static files (javascript, css, gifs, > etc) in their webapp and referencing those files from their servlets and > JSPs. The downside of this approach is that each application has a separate > copy of the AJAX library, increasing the server's overall footprint and > preventing browsers from using a single copy of the library files from their > caches. Another downside is that the AJAX library can't be upgraded or > otherwise managed independently from the web applications that contain it. > For example, a web application deployed across a cluster might need to serve > up the static Dojo files from a central location. Hosting the Dojo files in > a separate webapp can help work around these problems." > > So asking users to package the Dojo level and features they need within > their own apps would imply the downsides mentioned above. Providing an > installable dojo plugin that's equivalent to the /dojo support we currently > provide as suggested by Kevan seems to be an excellent alternative. > > -Donald >> >> >> >> Kevan Miller wrote: >> >>> >>> On Jun 27, 2008, at 11:00 AM, Shrey Banga wrote: >>> >>> >>>> As for the including the rest of DojoX, since it a significant part of >>>> the reducing effort. Would it make sense to build a custom js for >>>> monitoring, remove the rest of DojoX and if the development starts shifting >>>> to a real need for DojoX to make a decision to bring it back in the future? >>>> >>>> I think that makes perfect sense- not only will this do the part in >>>> reducing the dojo footprint, it'll also be useful as an example to how dojo >>>> should be used optimally in deployment. Another desirable side-effect would >>>> be reduced load times in the monitoring application, although currently >>>> that >>>> is not an issue. >>>> >>> >>> I'm starting to think that our server should deliver dojo support that is >>> targeted to the requirements of the admin console. >>> >>> For general dojo support, we could provide an installable dojo plugin >>> that's equivalent to the /dojo support we currently provide... >>> >>> --kevan >>> >>> > > > -- > Thanks, > Shiva
