does the builtin communication bypass XMLHttpRequest? if so which events do you support?
this is good work..do you support JSON format? Martin Gainty ______________________________________________ Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. > Date: Wed, 26 Aug 2009 12:42:54 +0200 > Subject: Re: example of rich internet applications (RIAs) using struts 2 > From: reier...@gmail.com > To: user@struts.apache.org > > Hi Erik, > > Comments inlined. > > > > There's usually a trade-off between simplicity and out-of-the-box > > functionality and flexibility (how open to extensibility and > > customization). > > Where you opt for on this spectrum should depend a lot on the > > sophistication > > of your development team. If your team is sophisticated enough, it's better > > to opt for a framework that > > has a fairly steep learning curve in the beginning but allows for powerful > > extensibility which string developers will demand/like later on. If your > > team is fairly weak, then I think the out-of-the-box no-hassle widgets are > > what you want. > > > > We're actually trying to find a happy medium or rather, to meet both needs > > with the struts-jquery plugin. > > > > > I do agree there is no "fit all sizes" solution and you will always have to > find a compromise between having less complex components, that can be > combined to make complex things, and hight level ones that do a lot of > things and are less flexible/extensible. I would opt for having hight level > elements, that less capable developers can use to > achieve impressive results, and whenever you have things that those > components can do, then you come up with tailor made solution... Also it all > depends of the kind of applications you are building. For instance, in here > > > http://code.google.com/p/antilia/source/browse/trunk/com.antilia.web/src/com/antilia/web/crud/CRUDPanel.java > > I have built a component that creates a whole CRUD screen out of an > annotated Entity. This hight level component covers a set of use cases, lets > say 80% of what you need in an application, and whenever you find something > not doable with it, then you turn to the tailor made solution... > > > > A) OUT-OF-THE BOX SIMPLICITY: We're providing a number of standard widgets > > and components with built-in 'commnication' between them so that developers > > can > > implement all standard functionality simply: For example, to have two > > select > > boxes, one which is updated when the other changes, you can use the > > following code: > > > > <sj:select id="firstSelect" name="firstSelect" > > *onChangeTopics="firstSelectChanged" > > list="firstSelectList"*/> > > <sj:select id="secondSelect" > > *reloadTopics="firstSelectChanged"* *src="secondSelect.action" > > elementIds="firstSelect"*/> > > > > where *firstSelectList *is any kind of iterable collection in your > > model (action). > > > > Or you could create a draggable div with it's contents loaded > > remotely that drops into a droppable area simply div like this: > > > > <sj:div *draggable="true" src="myDivAction.action"*> > > <sj:div *droppable="true"*>Drop Into Me</sj:div> > > > > The one limitation I explained before is that the out-of-the-box widgets > > will be limited by what is released by > > > > B) EXTENSIBILITY AND POWER-USER SUITABILITY: By using jQuery, a > > publish/subscribe event model which allows developers to > > develop/subscribe/publish ANY custom handlers for the component events and > > by providing a plug-in mechanism for custom widgets, the ability for > > developers to extend the framework is virtually unlimited. What may be an > > issue with wicket in this area (from what i know... i may be wrong) is that > > if you are depending solely on the the provided components, there are bound > > to be special use cases where you want slightly different functionality or > > an altogether different component which isn't and to develop it yourself > > you're probably going to want to use a framework like jQuery anyway to amke > > things much easier at which point you might as well be using something like > > the struts-jquery framework. I also cannot stress enough the power of the > > publish.subscribe framework the struts-jquery plugin uses for interaction > > between ajax components and with any custom code. I'm not sure if wicket > > provides something as useful for de-coupled event handling/ component > > interaction. > > > > 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. > > Best, > > Ernesto _________________________________________________________________ Windows Live: Keep your friends up to date with what you do online. http://windowslive.com/Campaign/SocialNetworking?ocid=PID23285::T:WLMTAGL:ON:WL:en-US:SI_SB_online:082009
