On 10/26/06, Martin Cooper <[EMAIL PROTECTED]> wrote:
On 10/26/06, Alexandru Popescu <[EMAIL PROTECTED]> wrote:
>
> On 10/26/06, Martin Cooper <[EMAIL PROTECTED]> wrote:
> > On 10/25/06, Wille Faler <[EMAIL PROTECTED]> wrote:
> > >
> > > Hi.
> > > I raised the question today on Don Browns blog about being able to
> have
> > > integration between Struts2 and DWR, to get a full MVC model if you
> only
> > > want to re-render a snippet of a web-page.
> > > I am not sure if this has been discussed previously, but Don
> encouraged
> > > me to send my ideas if I had any, so here goes:
> > > When I have done AJAX-based stuff, 9 times out of 10, all I really
> want
> > > to do i execute some business logic, and re-render a portion of a
> page.
> > > This would seem to fit well with a traditional MVC-approach, with the
> > > exception that I don't want to re-render the full page.
> > >
> > > Earlier this year, I implemented such a simple framework, basically
> > > using Webwork2/XWork and DWR, adding some code to glue it all
> together.
> > > It consists of the following things:
> > > - Some generic JavaScript that can interpret parameters (either from a
> > > form or URL) into a Map of parameters, akin to what Webwork uses.
> > > - A Controller that is called by DWR, taking the Map, a
> callback-target
> > > (in the web-page) and the name of an action as its arguments. This
> > > Controller then invokes an xwork ActionProxy to invoke the Action.
> > > - Custom Result-implementations for getting JSP-elements defined in
> the
> > > xwork results. These results use the DWR
> > > WebContextFactory.get().forwardToString() functionality, to get the
> > > resulting JSP-snippet as a String.
> > > - Said Result can then be sent back by the Controller through DWR,
> which
> > > is then handled by generic JavaScript and rendered to the predefined
> > > callback-target on the page.
> > > - When using forms, it can also do AJAX-based validation which makes
> use
> > > of proper Xwork-validation.
> > >
> > > As I said, I have already written code for this, it is quite compact
> and
> > > only a few hundred lines (11 implementation classes + generic
> JavaScript
> > > + dwr config), so obviously this integration is quite easy to create.
> >
> >
> > I'm not really a DWR user, but this seems like a lot of code to me, when
> all
> > you want to do is update part of the page.
>
> It pretty much depends on what you mean: "update part of the page". In
> case you want to take advantage of the whole MVC then I really think
> this is one of the right way to do it.
I guess I'm missing what you mean by "the whole MVC". Could you elaborate?
In my example, I would be using the exact same MVC mechanism as I would use
for a full page refresh. Nothing on the server side would be different. No
extra code. Nothing.
What you are missing in fact is the initial intention of the code:
have DWR AJAX work through normal MVC. I never said that with pure
XMLHttpRequest you cannot use the MVC.
> If it were me, I would use Dojo > and simply make a single call to
> dojo.io.updateNode(node, url), with no custom code required on the server
> side.
>
> Not everybody is using Dojo, as not everybody is using DWR. Dojo is a
> heavy JS library, while DWR is a java library and from this
> perspective I think DWR has an advantage.
It is an unfortunate misconception that Dojo is "heavy". Dojo can be
extremely lightweight if you only use what you need.
I don't intend to start a flame here, but after studying dojo for a
couple of days, I still couldn't figure out how to do some things.
Moreover, I had problems with it on different browsers (check WW
mailing lists for details).
And I meant heavy in the sense of a more complex learning/usage curve
than others.
If I need a pile of extra code on the server to use DWR, I'd say DWR is at a
disadvantage. ;-)
Just look at the Struts2 dependencies... there is already a pile of
extra code needed on server side :-).
But I recognise that a lot of people seem to like it, and
perhaps, as you suggest, because they're more comfortable using Java than
learning JavaScript.
And what is more important: there is no custom code on server side.
> You just have your normal actions: you can invoke them through normal
> requests, but also thru AJAX.
But for some reason you need all that DWR-related code before you can get to
your uncustomised code? This is the part that I don't get. It seems that the
need for that extra code is solely because you are using DWR, which, in this
scenario, you don't actually need.
Once again, I wouldn't say: "you don't need it". The fact that you
would prefer using Dojo over DWR is a matter of taste and your
technical decision. So, is the DWR usage. Others may use prototype, or
any other existing AJAX frameworks.
But for some reason you need all that DWR-related code before you can get to
your uncustomised code?
Yep... it's like saying that you need all that Dojo scripts just
because you want to do an Ajax request :-).
I think we need to agree to disagree :-).
./alex
--
.w( the_mindstorm )p.
--
Martin Cooper
> Can you help me understand what advantage I would gain by using DWR with
> this new code?
> >
>
> Simply said, and as the OP also mentioned: to use the same MVC
> paradigm with DWR AJAX invocation.
>
> HTH,
>
> ./alex
> --
> .w( the_mindstorm )p.
>
> > --
> > Martin Cooper
> >
> >
> > I
> > > would love to see something similar within the upcoming Struts2!
> > > I haven't attached the code to this mail, but it is available for
> > > download here: www.infonatural.com/ajax-mvc.zip (including
> > > jar-dependencies and some unit-tests, 3.6mb).
> > >
> > > If anyone wants to pick the code for ideas, or adapt it, feel free to
> do
> > > so as long as you retain the original @author comments as part of it
> (I
> > > am the sole copyright holder of the code, and you may use it under the
> > > ASF if you want).
> > > It would probably need some minor improvements to make it more in line
> > > with the rest of the Struts2-code (so tags work etc), as I only did
> the
> > > code originally for my needs and didn't bother doing more than I
> needed
> > > at the time.
> > >
> > > I apologise if this or something similar is already part of Struts2,
> but
> > > I got the impression that it may not be.
> > >
> > > regards
> > > Wille Faler
> > >
> > >
> > > ---------------------------------------------------------------------
> > > 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]