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
