On Tue, Dec 22, 2009 at 11:13 AM, <sudhir543-...@yahoo.com> wrote: > Thanks for clarifying the things, > >> show me a framework that makes this easier... > I think that when I when I was working with Webwork (Struts2 now) I dint need > to do any thing else other than specifying spring factory in one of config > file. Neither I was forced to use annotations.
so how does webwork know which properties of your actions should be injected from spring and which from the request or session objects? > LDMA might have nothing to do with Integration, but from my lil experience, I > think that When I want to pass my entity as a model to some components (which > might be serialized as in most cases) It wouldnt work with normal models, I > will have to manage a separate LDM class for each of that if I don't want > lazyloading exceptions. huh? it all depends on how your domain model works. every application is different. same applies to other frameworks - eg when you need to put your entity into session because you want to access it across requests, or when you put things into conversation scope. this problem has nothing to do with wicket. LDM is simply one concrete solution for dealing with these kinds of issues. -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: Igor Vaynberg <igor.vaynb...@gmail.com> > To: users@wicket.apache.org > Sent: Wed, 23 December, 2009 12:03:05 AM > Subject: Re: Wicket feedback > > On Tue, Dec 22, 2009 at 10:20 AM, <sudhir543-...@yahoo.com> wrote: >> Yes, from my little experience, I just started learning it [Because I feel >> it has some thing different to offer] >> >>>orly? so what about integrations with hibernate, jdo, jpa, spring, >> guice, cdi, etc? i guess all those things are a figment of my >> imagination. >> >> As I said it takes comparatively(to some others) more efforts. >> If I talk about spring, using spring with wicket needs special care, one >> will have to take care that he > does not serialize entire containers. > > that is taken care for you by the framework. all you have to do is > install the component injector (1 line of code) and use @SpringBean > annotations in your pages to inject your dependencies. show me a > framework that makes this easier... > >>I haven't tried to use hibernate yet (just playing with inmemories) but I >>think that I will have to create LoadableDetachable model of most of my >>entities (plz correct me if I am wrong) > > LDMs have nothing to do with integration with other frameworks but how > you want to manage state. in some cases it makes sense not to use LDMs > for hibernate entities. > > -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: Igor Vaynberg <igor.vaynb...@gmail.com> >> To: users@wicket.apache.org >> Sent: Tue, 22 December, 2009 9:46:45 PM >> Subject: Re: Wicket feedback >> >> 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 >> >> >> 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 > > > 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
