When you say "offline storage" do you mean that the user has chosen to save pages for future offline reference or do you mean a more 'automated' process that wicket performs when system memory becomes too low?
Chris > -----Original Message----- > From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] > Sent: Friday, 29 May 2009 11:43 AM > To: users@wicket.apache.org > Subject: Re: Anemic domain model and are @SpringBean's compatible with the > solution in "Spring 2.0 vs. the Anemic Domain Model"? > > well, this is why salve removes the dependency field to at least help > with those. > > other then that you can use a loadabledetachablemodel to release the > reference when the page is not used. > > -igor > > On Thu, May 28, 2009 at 6:40 PM, Chris Colman > <chr...@stepaheadsoftware.com> wrote: > > Is that controllable? > > > > What if I have complex object models referenced from wicket UI > > components that I don't want (can't reasonably with Java's non optimal > > serialization) serialized? > > > > If we're serializing for offline storage aren't we going to require the > > underlying model objects to get serialized as well? > > > >> -----Original Message----- > >> serialization in the context when you need to serialize the object - > >> eg wicket serializes its pages for offline storage, etc. > >> > >> -igor > >> > >> On Thu, May 28, 2009 at 5:51 PM, Chris Colman > >> <chr...@stepaheadsoftware.com> wrote: > >> > Another extremely light weight IoC with ORM wrapping (JDO and > > Hibernate) > >> > is exPOJO at http://www.expojo.com > >> > > >> > No need for old fashioned DAOs etc., just POJOs being persisted > >> > transparently the way they should be. > >> > > >> > In terms of serialization: > >> > > >> > Is that for the purpose of scaling in a cluster environment? I vote > > for > >> > 'session affinity' every time - it's almost necessary when you have > >> > anything more sophisticated than an anemic domain model. Do you > > really > >> > want to be shifting complex object models from server to server via > >> > serialization? > >> > > >> > If it's not for a cluster environment but for a single server to > > allow > >> > stale sessions to be swapped out then let the garbage collection > > clean > >> > out the ORM's object cache instead. > >> > > >> >> -----Original Message----- > >> >> From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] > >> >> Sent: Friday, 29 May 2009 3:38 AM > >> >> To: users@wicket.apache.org > >> >> Subject: Re: Anemic domain model and are @SpringBean's compatible > > with > >> > the > >> >> solution in "Spring 2.0 vs. the Anemic Domain Model"? > >> >> > >> >> On Thu, May 28, 2009 at 10:09 AM, Kent Larsson > >> > <kent.lars...@gmail.com> > >> >> wrote: > >> >> > Nice! I think Salve looks great! And it solves more than this > >> > problem, > >> >> > I like the design by contract module too as it allows me to > > validate > >> >> > parameters in a bit more declarative way. > >> >> > > >> >> > Do you think Salve is ready to be used in production? I'm a bit > >> >> > concerned by "Although already usable, Salve is still in its > >> > infancy. > >> >> > Not all features have been implemented and not all problems > > worked > >> >> > out.". I only see one open issue and it doesn't seem too major > > for > >> > me > >> >> > to pick it up. > >> >> > >> >> we have been using it in production for a while without any > > problems. > >> >> i just need to find the time to update the website text :) > >> >> > >> >> > If I'm not mistaken Salve may be used (for lots of things, but > > one > >> > is) > >> >> > to solve serialization issues with Spring beans in Wicket > >> > components? > >> >> > But isn't that the same issue that the Wicket IOC and it's > >> > @SpringBean > >> >> > annotation solves? > >> >> > >> >> wicket ioc can only take it so far. because it has to generate a > > proxy > >> >> there are limitations to what classes can be proxies - eg no final > >> >> methods, default constructor, etc. salve doesnt use a proxy so it > >> >> doesnt have any problems. > >> >> > >> >> although small, wicket ioc does have an overhead of having to > >> >> serialize the proxy with the componnet. since salve removes the > > field > >> >> it has no such overhead, this is more important when you are > > returning > >> >> large resultsets of entities that use dependencies. > >> >> > >> >> > If that's the case: Could I use Spring to inject my entities with > >> >> > DAO's for now, and use the @SpringBean annotation on those as > > well > >> > in > >> >> > my Wicket components (In those cases I have entities as class > > vars)? > >> >> > And the @SpringBean will solve the serialization issue? > >> >> > >> >> you can use whatever works for you. salve is an alternative :) > >> >> > >> >> > By just looking at Salve a bit it seems I could migrate to Salve > > in > >> >> > two steps that way. And it might be a pretty smooth path to take? > > It > >> >> > would mean that I inject 1000 entities for no good reason. But if > > I > >> >> > see a performance problem in doing so I could just migrate to > > Salve? > >> >> > By smooth path I mean that I would have access to my DAO's in my > >> >> > entities and would essentially only change the dependency > >> > annotations > >> >> > and setup Salve. > >> >> > >> >> as long as you do not use spring-specific injection rules you > > should > >> >> be fine. salve uses lookup by type primarily, but also does have > >> >> @SpringBeanId that can be used as a qualifier. > >> >> > >> >> > >> >> > Of course, if Salve is production ready. Then could I throw out > >> > Wicket > >> >> > IOC and the @SpringBean annotation and use Salve instead to solve > >> >> > serialization issues? In this case I would use Salve for my > >> >> > presentation/Wicket -layer as well as dependency injection in my > >> >> > entities and Spring as I already do for my service/business > > -layer > >> > and > >> >> > my persistence/DTO -layer. Or would it be nicer to have Salve > > handle > >> >> > dependencies in the last two layers as well? > >> >> > >> >> we use salve to inject across all layers. it gives you a consistent > >> >> approach to use and mock in unit tests. we have a spring context > > that > >> >> contains true services - eg session factory, mail sender, credit > > card > >> >> processor, etc. all of our domain model then uses salve to inject > >> >> these wherever needed. > >> >> > >> >> -igor > >> >> > >> >> > A lot of questions and text. Thanks for reading this far! :-) > >> >> > > >> >> > Best regards, Kent > >> >> > > >> >> > > >> >> > > >> >> > On Thu, May 28, 2009 at 5:36 PM, Igor Vaynberg > >> > <igor.vaynb...@gmail.com> > >> >> wrote: > >> >> >> this is why i built salve.googlecode.com > >> >> >> > >> >> >> you can easily hook it into spring and have all your objects > > (doman > >> >> >> objects or wicket components) injected via @Dependency without > >> >> >> worrying about serialization issues or eager injection - eg if > > you > >> >> >> load a result set of 1000 hibernate entities that need injection > >> > you > >> >> >> dont want all those injected for no reason. > >> >> >> > >> >> >> -igor > >> >> >> > >> >> >> On Thu, May 28, 2009 at 6:38 AM, Kent Larsson > >> > <kent.lars...@gmail.com> > >> >> wrote: > >> >> >>> Hi, > >> >> >>> > >> >> >>> Our current architecture: > >> >> >>> --- > >> >> >>> > >> >> >>> We're currently using a 3-tier architecture (presentation, > >> >> >>> service/business and persistence) consisting of Wicket (+ a > > little > >> >> >>> Spring), Spring and Spring + Hibernate: > >> >> >>> > >> >> >>> Wicket: > >> >> >>> > >> >> >>> Does presentation, we're not inside a transaction / Hibernate > >> > session > >> >> >>> so all used fields must be loaded by Spring. We call Spring > >> > singleton > >> >> >>> beans and annotate those fields with @SpringBean. > >> >> >>> > >> >> >>> Spring: > >> >> >>> > >> >> >>> In the service layer we have Spring singleton beans, services, > >> > which > >> >> >>> are called from the Wicket layer. We have our transaction / > >> > Hibernate > >> >> >>> session boundary at this layer. We call DAO's from this layer. > >> >> >>> > >> >> >>> Spring + Hibernate: > >> >> >>> > >> >> >>> Our DAO's are Spring singleton beans which performs database > >> >> >>> operations using HibernateTemplate. > >> >> >>> > >> >> >>> And common to all the layers are our entities. We use the > > @Entity > >> >> >>> annotation on them (not XML), from the Wicket layer we just use > >> > the > >> >> >>> accessor methods making sure that the relevant fields are > > loaded > >> > (as > >> >> >>> we would get an exception if they were Lazy and not yet > > loaded). > >> > Our > >> >> >>> entities are stupid, they lack logic and are used mostly like a > >> > struct > >> >> >>> in C/C++. > >> >> >>> > >> >> >>> I think the general pattern is pretty common for Java EE and > >> > Spring > >> >> >>> based web applications (feel free to disagree!). Yet it's > >> > classified > >> >> >>> as an anti-pattern by Martin Fowler as we are using mostly > >> > procedural > >> >> >>> programming and have an anemic domain model ( > >> >> >>> http://en.wikipedia.org/wiki/Anemic_Domain_Model ). > >> >> >>> > >> >> >>> What I would like: > >> >> >>> --- > >> >> >>> > >> >> >>> I would like to use a more OOP approach and have logic in our > >> > current > >> >> >>> entities, creating a rich domain model. For that to work in all > >> > cases > >> >> >>> they need to be able to load and save data. I would still use a > >> > Spring > >> >> >>> singleton bean's for different services. But instead of > > changing > >> > the > >> >> >>> entities like structs they would be rich objects capable of > >> > chaning > >> >> >>> themself's and other objects. > >> >> >>> > >> >> >>> I found this article very interesting: > >> >> >>> http://www.nofluffjuststuff.com/blog_detail.jsp?rssItemId=96860 > >> >> >>> > >> >> >>> But how would something like that work with Wicket? Could I > > just > >> > use > >> >> >>> @SpringBean like I'm currently doing but use it on both > > "entities" > >> > and > >> >> >>> Spring singleton services? > >> >> >>> > >> >> >>> For me this has a purely practical benefit, as I could use some > >> >> >>> inheritance in the domain object model to create different > >> > variations > >> >> >>> of logic and not just data. Wicket feels quite agile and nice > > to > >> > work > >> >> >>> with, but I still feel that the current architecture is a bit > >> > stale > >> >> >>> and seldom supports elegant OO solutions (that said, of course > >> > things > >> >> >>> can still be solved elegantly, I just think it would be easier > > if > >> > I > >> >> >>> could do it in a more OO oriented way). > >> >> >>> > >> >> >>> Comments? What are the pros and cons of this kind of > > architecture? > >> >> >>> > >> >> >>> All comments are greatly appreciated! > >> >> >>> > >> >> >>> Best regards, Kent > >> >> >>> > >> >> >>> > >> > > > --------------------------------------------------------------------- > >> >> >>> 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 > >> >> >> > >> >> >> > >> >> > > >> >> > > >> > > > --------------------------------------------------------------------- > >> >> > 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 > >> >> > >> >> > >> >> No virus found in this incoming message. > >> >> Checked by AVG - www.avg.com > >> >> Version: 8.5.339 / Virus Database: 270.12.44/2140 - Release Date: > >> > 05/28/09 > >> >> 18:09:00 > >> > > >> > > > --------------------------------------------------------------------- > >> > 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 > >> > >> > >> No virus found in this incoming message. > >> Checked by AVG - www.avg.com > >> Version: 8.5.339 / Virus Database: 270.12.44/2140 - Release Date: > > 05/28/09 > >> 18:09:00 > > > > --------------------------------------------------------------------- > > 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 > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.5.339 / Virus Database: 270.12.44/2140 - Release Date: 05/28/09 > 18:09:00 --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
