struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Frank W. Zammetti" <fzli...@omnytex.com>
Subject Re: [action2] Upgrade Dojo toolkit
Date Mon, 19 Jun 2006 16:56:36 GMT
On Mon, June 19, 2006 12:34 pm, Jason Carreira wrote:
>> 3. Using #2 above we are not forcing user to either
>> use the dojo version
>> in the SAF release, or to muck about updating the
>> dojo version
>> themselves - currently the dojo JS is included in the
>> core JAR file.
>> Not being able to easily use the most recent version
>> (with the most
>> recent bug fixes) is most likely gong to be
>> frustrating.
>
> I'm not so sure about this. I think people will be glad to have a
> combination they know works together. It's not always about the newest,
> shiniest thing, sometimes it's about the path of least resistance, and
> pre-bundled is pretty low resistance.

I think both points of view here are important...

Indeed, the path of least resistance is good for many.  On the other hand
though, as a user of the framework I wouldn't like it if I had to jump
through too many hoops to upgrade a given dependency (and ultimately,
that's what Dojo is, same as Spring, same as Freemarker, same as anything
else).

On the gripping hand ;) ... I think both ideas can be accomodated.  There
should be some mechanism that essentially allows a developer to override
the version bundled with the release, whether it's as easy as replacing a
JAR or changing a setting in some property file doesn't much matter...
those inclined to do so will go through the little bit of extra effort,
those not inclined will be happy that it's built-in.

Knowing what comes out of the box works together is without question
valuable... but sacrificing the ability to push the limits later in the
name of that value I don't think would be a good trade-off.

>> 5. If we add any ajax functionality it should tie
>> into the framework -
>> i.e. validation and connecting custom
>> componts/rendering with actions.
>> In these cases I think that DWR is a better option
>> than dojo
>>
>> /Ian
>>
>
> I think there's room for both.

I agree

Comparing DWR and Dojo, I come away with this thought: DWR has a model for
doing what is essential RPC, Dojo doesn't (it has the capability of
course, but not the API in essence).  Dojo has the component model for
widgets, DWR doesn't (and again, it has the capability, but not the API). 
What this means, to me, is that they fundamentally serve different
purposes and can coexist nicely.  You could ultimately do the same thing
with both, but as they exist today you'd have to build something on top of
each to get them to parity.

One other important point I think is that to my thinking, there is more
opportunity (and maybe even necessity) for closer integration between DWR
and SAF2 than between Dojo and SAF2.  I say this because DWR of course
uses its own servlet... to really take the integration as far as we might
like, I suspect the best approach is to in a sense absorb that servlet
into SAF2.  In other words, one could imagine a situation where you
perform the functions of the DWR servlet in a bunch of Interceptors maybe,
thereby integrating it directly in SAF2.

With Dojo, I don't think the same is true... there really isn't any server
component to be integrated.  Yes, you could wrap the widgets and make the
tags do some of the client-side setup and such, but that's really more
about convenience than integration to me (and not that convenience isn't
important!).

Anyway, I'm probably starting to babble :)

> Jason

Frank

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message