I guess my point of view, which I thought others shared at JavaOne
(please speak up, because I'm starting to think that I am imagining it
:)), is this:
1. For very basic wrapped widgets the dojo implementation is great.
But, as soon as people start working more in depth, problems arise and
in-depth knowledge of the dojo framework is required. I believe Pat's
examples of this was debugging issues. This no longer allows us to wrap
and isolate the end user.
2. I think we are doing a lot of work wrapping the dojo widgets with tag
object models, etc. when the alternative is easier - add <saf:property
.. /> tags directly to the dojo markup. I also believe as more complex
UI's are build, most people will opt. for this route for more control.
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.
4. When it comes down to it, SAF is adding no additional functionality
to the dojo widgets. There was a discussion about PDF's the other week,
and I think this is similar issue.
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
Frank W. Zammetti wrote:
I've done a bit of work with both DWR and Dojo, so...
DWR is really fantastic in terms of being really easy and clean to write
to. It makes remote calls to the server look like nothing more than
function calls to a local Javascript object. Really sweet.
But, that's all it is. While that's great (I'm a fan of DWR if you
couldn't guess!) it doesn't provide a component model for building
widgets, as Dojo does. It doesn't inherently have anything to say about
that.
You *could* of course build widgets with DWR, but it would require coming
up with your own component model, and all the plumbing that goes into
that. Dojo already has that.
My feeling is that DWR is more advanced in terms of just doing AJAX. But,
when you start talking about GUI widgets specifically, Dojo has a big leg
up IMO. I'm not sure what that really says about either library's place
in SAF2 though...
Frank
On Mon, June 19, 2006 10:25 am, tm jee wrote:
Instead these components would fall into an "extra" project, separate
from the core project.
Is it possible to have it remain in core, I am willing to maintain and
improve them.
About using dwr as the officianl ajax tool / util, i am not sure how
components could be build around it. Would it be too much efford to build
components around dwr or are we looking on something else. (I have almost
no knowledge about dwr :-P so i might be totally off )
regards.
----- Original Message ----
From: Ian Roughley <[EMAIL PROTECTED]>
To: Struts Developers List <dev@struts.apache.org>
Sent: Monday, 19 June, 2006 8:52:45 PM
Subject: Re: [action2] Upgrade Dojo toolkit
My understanding from the meeting was that we would not pursue
components that simply wrapped other components (i.e. dojo widgets).
Instead these components would fall into an "extra" project, separate
from the core project.
/Ian
tm jee wrote:
Hmm.... what about the ajax component support? Are we going to make
them work with dwr instead of dojo? or just dropping them
rgds
----- Original Message ----
From: Ian Roughley <[EMAIL PROTECTED]>
To: Struts Developers List <dev@struts.apache.org>
Sent: Sunday, 18 June, 2006 11:22:26 PM
Subject: Re: [action2] Upgrade Dojo toolkit
At JavaOne it was decided to go with DWR in favour of dojo. Given this
I would assume that we would not upgrade the version.
/Ian
tm jee wrote:
Hi guys,
Is there any plan to upgrade dojotoolkit from the current 0.2.2 to
0.3.x?
0.3.x have lots of really cool stuff and from the bugs list, it looks
like lots of bugs have been fixed.
Cheers.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
