On Tue, Dec 22, 2009 at 6:21 AM,  <sudhir543-...@yahoo.com> wrote:

lol

> Ajax with wicket is easy.. if you do it the wicket way..  But integration 
> with other engines isnt going to be easy.


maybe if you have "little" experience you should not be making such
sweeping statements. there are projects in wicketstuff and the
internets that integrate wicket with jquery, dojo, prototype, ricoh,
mootools, etc. and they do so easily, because wicket makes it easy.

> 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.

orly? so what about integrations with hibernate, jdo, jpa, spring,
guice, cdi, etc? i guess all those things are a figment of my
imagination.

-igor

>
>
>
>
> 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/

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to