On Wed, Aug 26, 2009 at 6:42 AM, Ernesto Reinaldo
Barreiro<reier...@gmail.com> wrote:
>
> Not quite following you here. In Wicket you normally attach events to
> components in a programmatic way at the Java side and then when components
> HTML code is generated the framework itself generates the (e.g. AJAX)
> callbacks. All you have to do is what you want at Java code level and say
> which components you want to refresh via AJAX (this at the Java level, the
> framework itself will generate all the JavaScript necessary to get this
> working). Think of something like the following (pseudo) code
>
>
> TextField b = new TextField("b");
>
> DropDownChoice a = new DropDownChoice("a" ....);
> a.add(new AjaxFormComponentUpdatingBehavior("onchange") {
> �...@override
> protected void onUpdate(AjaxRequestTarget target) {
> if(target!=null) {
> // do soemething to the model of
> TexField b
> target.addComponent(b);
> }
> }
> });
>
> This will generate a select and whenever you change the selected element you
> will get notified at the server side, you do something that change the model
> of textfield b, which determines what b will display, and then say you want
> b update (target.addComponent(b)) . Thats all what it takes to do AJAX in
> Wicket.
>
What Eric is trying to say is that in practice, taking this design
approach at the framework level creates limitations for the users. It
may not seem obvious when you are first adopting a framework that
delegates all JS generation to the framework (via annotations or
hooks, etc.), but the day a new JS-only functionality comes along that
you want to use, you may be stuck waiting for the framework to be
updated to include what you're looking for. In addition, let's say
you're hoping to use YUI in addition to JQuery (or whatever is built
in to frameworkX), if you are not exposed to any of the javascript,
then you have to render the page and try to surmise what the java is
generating for dom ids or css classes, then try to anticipate the
pattern and build your YUI integration around that. What we're trying
is a fundamentally different approach. Rather than make javascript a
completely invisible detail, we are making the basic things easier,
but exposing the details in a way that make it friendly for the people
who desire the ability to write some of the javascript code. This is
what he is alluding to when he mentioned the publish/subscribe library
he has created. We view this as one of the keys to making it easy to
separate framework javascript code from framework user javascript
code. Each of the built-in components will hook into this
event-handling, but the library for the event handling is exposed so
that framework users can manipulate it.
The main difference is that it always seems like to do ajax, you have
to choose one of two options... Option one is to adopt a framework
with built-in ajax support. The downside to option one is that you're
often limited to what they expose because the exposed
widgets/events/etc. are generally not meant to be hacked. Option two
is to adopt a javascript framework and learn ajax. The downside to
option two is that if you aren't using a framework's "blessed" ajax
functionality, then you are trying to inter-jimmy-in functionality
into a pattern that is usually meant for a traditional
request-response/view lifecycle.
I'm not judging any competing frameworks because I feel we were guilty
of this with the first set of ajax tags. We tried to hide too much and
it was particularly hard to add raw Dojo to your app that worked with
the generated dojo components.
In the end, we'll see how it all shakes out, but one rule I keep and
it seems like the other guys working on struts2-jquery keep is that we
create and work on stuff that we want to use. We're all good struts2
users and jquery users, so we're going to create a taglib/integration
that is worthy of our own projects :)
-Wes
--
Wes Wannemacher
Head Engineer, WanTii, Inc.
Need Training? Struts, Spring, Maven, Tomcat...
Ask me for a quote!
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
