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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
