Thanks for the clarifications Wes. That's what I was trying to say. :)
On Wed, Aug 26, 2009 at 4:26 PM, Wes Wannemacher <w...@wantii.com> wrote:
> 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
>
>
