Guice / warp persist and dynamic finders + wicket are a killer combo:) 2009/10/5 James Perry <james.austin.pe...@gmail.com>
> Well you can use your business logic objects inside Wicket but you have to > ensure that you you hold one, and only one, instance for each business > object (assuming these objects are stateless) and that you do not > accidentally serialize these objects and their dependencies within your > Wicket pages. > If you don't want to use Spring, have a look at Google Guice - which is a > very simple, elegant yet powerful DI framework. Wicket provides support for > Guice so you don't have to worry about accidental serialization. Once you > have got to grips with Wicket and Guice then you can get really creative to > enable Guice to inject Wicket components in your Wicket application. > > Cheers, > James. > > On Mon, Oct 5, 2009 at 3:49 PM, Jeffrey Schneller < > jeffrey.schnel...@envisa.com> wrote: > > > I looked into the wicket London presentation/code and databinder.net and > > it all makes sense but it looks like then my wicket forms/components are > > tied directly to the database. When I submit a form then the data is > > persisted but I don't want this. I want to be able to call the data > > layer to retrieve data or to persist data and not care that a form is > > tied to it or not. I also need to be able to get data to populate lists > > or tables on a page. > > > > I currently have my project set up like: > > > > Data objects - POJOs to hold data that comes from or will be persisted > > to the db > > Data Access Objects - objects to get and persistent data using hibernate > > using the data objects > > Business Logic - helper classes to access the data access objects if > > additional logic needs to be performed before persisting to the db. > > Wicket Pages - all my wicket pages. The pages call the data access > > objects to retrieve data to display on pages and forms. The pages also > > handle the form submits and call the Data Access Objects to persistent > > to the db. In some cases I call the Business Logic layer to do the > > persistence. > > > > In the end I have data layer which I can re-use. The business logic > > layer which I can change as needed. Then the wicket pages which once > > they work I shouldn't need to touch if the logic changes or the data > > layer changes. This is what I think of as a true 3-tier architecture. > > > > I also am not using maven. I have eclipse running and added the jars to > > the project myself. If I need to use maven then I will but it seems > > like adding more stuff to something that should be very simple. > > > > > > Should I be doing something different in terms of my architecture to > > implement wicket? Everything is running fine for me except the lazy > > loading of data from hibernate. Not sure how my session size is going > > to look doing it this way either. Would prefer to have the smallest > > session size possible but this is a small app with little traffic for > > now so not that big of a deal. > > > > I am a wicket newbie and want to get this right as this is the first > > wicket project which will lead to a much larger higher traffic project > > that is currently planned to be developed using wicket. > > > > Thanks. > > > > > > > > > > -----Original Message----- > > From: Adrian Merrall [mailto:pigeonra...@gmail.com] > > Sent: Monday, October 05, 2009 6:17 AM > > To: users@wicket.apache.org > > Subject: Re: Wicket + Hibernate without Spring for lazy loading > > > > Google for a wicket london weekend presentation and follow up blog on > > loading jpa entity managers on demand. There have also been various > > posts > > relating to using the open session in view Hibernate filter. > > > > The JPA blog entry uses the requestcycle to prepare a thread local. The > > first call to use it creates the entity manager and keeps it in the > > thread > > local. > > > > The request cycle end request and exception methods handle the cleanup > > and > > close. > > > > Very brief description but if you google for the topics above it is all > > very > > well explained. > > > > HTH > > > > Adrian > > > > On Mon, Oct 5, 2009 at 6:22 PM, Petr Fejfar <petr.fej...@gmail.com> > > wrote: > > > > > On Mon, Oct 5, 2009 at 5:12 AM, Jeffrey Schneller > > > <jeffrey.schnel...@envisa.com> wrote: > > > > > > > I really don't want to bloat my code to implement Spring but if it > > is the > > > only way to do it then I will. > > > > > > When I've started learning of Wicket few month ago, my position was > > > the similiar: I'd like to avoid stuff like Maven, Spring etc... I > > > found out Databinder as well and tried it. But I was not able to make > > > it running with Hibernate, just with HSQLDB. > > > > > > So we've decided to continue with Spring, Maven... We've increased our > > > overhead little bit, but once we define beans, we do not care about > > > them any more. There was only one pitfall: manually invoking injection > > > of non-visual components. After few month I must say that Spring seems > > > to be the least problematic part of our projects. > > > > > > > > > Petr > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > > For additional commands, e-mail: users-h...@wicket.apache.org > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > For additional commands, e-mail: users-h...@wicket.apache.org > > > > >
