so dont use databinder's entity form, only use its requestcycle infrastructure.
-igor On Mon, Oct 5, 2009 at 7:49 AM, Jeffrey Schneller <[email protected]> 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:[email protected]] > Sent: Monday, October 05, 2009 6:17 AM > To: [email protected] > 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 <[email protected]> > wrote: > >> On Mon, Oct 5, 2009 at 5:12 AM, Jeffrey Schneller >> <[email protected]> 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: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
