On Tue, Dec 22, 2009 at 7:51 PM, <sudhir543-...@yahoo.com> wrote: > Ajax with wicket is easy.. if you do it the wicket way.. But integration > with other engines isnt going to be easy. > > IMHO integration with other engines is actually quite easy, and certainly far easier than other frameworks, see this:
http://ptrthomas.wordpress.com/2009/08/12/wicket-tutorial-yui-autocomplete-using-json-and-ajax/ in response to the OP who said: - Ajax > Wicket offers no stateless ajax and often changes HTML id, which makes > harder to integrate with a 3rd party ajax framework. Is there any hope for > constructor change? > I haven't found this a problem in practice, maybe a smarter use of getMarkupId() is the answer. BTW someone wrote a patch [1] to have stable markup id-s, it was discussed on the list recently [2]: [1] http://blogs.onehippo.org/arthur/2009/02/hippoecm_integration_testing_w.html [2] http://old.nabble.com/Hippo%27s-patch-for-wicket-ids-ts25901638.html#a25901638 - Peter > Not only Ajax, from my little wicket experience, I would say wicket works > great in isolation, however integrating it to any other framework would take > (and it takes) comparatively more efforts. > > > > > Sudhir NimavatSenior software engineer. > Quick start global PVT LTD. > Baroda - 390007 > Gujarat, India > > Personally I'm always ready to learn, although I do not always like being > taught > > > > > > ________________________________ > From: Ricardo Mayerhofer <ricardo.ekm.lis...@gmail.com> > To: users@wicket.apache.org > Sent: Tue, 22 December, 2009 6:49:02 PM > Subject: Wicket feedback > > Hi all, > We've just finished with success a wicket project for a large online > retailer. I think wicket is the best framework out there, but as any other > project there is room for improvement. I will talk about some topics bellow, > I hope it can help in some way. > > - Separation of corcerns > I think we could get a better separation of concerns if page class were > focused more in behavior and html were more focused in display (or view). > What I mean is, some times we have components that the main purpose is to > add behavior, and we have to add extra markup just to satisfy wicket 1:1 > mapping. Take CheckGroup for exaple, it is a component focused on behavior, > even though we have to add a reference to it in HTML. > > When creating composite input fields (like date), the usual way is to > create a panel even if you are not interested in reusability. A interesting > aproach is to insert a hidden text field in HTML mapped to a component that > controls other components input. It makes easier to integrate with designer > and to preview in browser. If we didn't have this limitation the hidden > input would not be necessary and the development of behavior focused > components would be easier. > > One thing that bothers me is when our designer move things around in HTML > and we get "added a component in code but forgot to reference it in the > markup" error, because of component hierarchy. Html tags position is a view > problem not a behavior problem, so why bother in java? > > Another issue, is when we want to change the class of a div, for example, > and have to change our whole page hierarchy in java, just to manipulate that > tag. > > So I think a hierarchy more focused on components behavior (for example > taking care of inherited models and inputs), rather than tags position in > HTML would be better. This would make wicket more flexible and easier to > work with. > > - Too many finals modifiers > It's hard for a API or framework designer to foresee all uses and > unxepected situations its users may face in day to day development. Final > modifiers places a additional challenge when facing these situations. In > project were deadlines are in place, there is little room for submiting a > request and waiting for a new version to be released. Furthermore, > unfortunately, it's not possible to mock final methods making it harder > sometimes to test wicket related classes/components. What we had to do > internally, is to have our own version of wicket, mainly to remove final > modifiers when necessary, a clear violation of open/closed principle. > > - Ajax > Wicket offers no stateless ajax and often changes HTML id, which makes > harder to integrate with a 3rd party ajax framework. Is there any hope for > constructor change? > > Please let me know your thoughts, keep up the good work. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > > The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. > http://in.yahoo.com/ >
