You could probably hook into Stripes' population strategy (and set new
objects' *created* property), but it sounds like you would much rather like
a JPA solution (some kind of interceptor).
On Sun, Jul 4, 2010 at 5:55 PM, Nikolaos Giannopoulos <
nikol...@brightminds.org> wrote:
> Hi,
>
> Say we had the following rudimentary Data Object / Model class:
>
> @Entity
> public class User extends BaseModelShardIntegerID {
> private Long created;
> public Long getCreated() { return created; }
> public void setCreated(Long created) { this.created = created; }
> }
>
> Created corresponds to the time the instance was created and therefore
> although it can be externally pumped into the class in reality the model
> should be capable of initializing this on its own. There are other examples
> of this such as holding an internal score and wanting it to start at 0 for
> example.
>
> Now there are a couple of scenarios were this model can be utilized:
>
>
> 1) From a JSP Form and therefore as an attribute of an ActionBean.
> Although we could populate the form with a hidden field for this attribute
> and have the setter set it on the bean I prefer not to as once again this is
> a rudimentary example and in the real case we have say 6-12 fields that
> require initialization. What to do - well 1 option - code the constructor
> as follows:
>
> public User() {
> this.initialize();
> }
> private void initialize() {
> this.created = System.currentTimeMillis();
> }
>
> All is great for JSP Form --> Action Bean population
>
>
> 2) Say we have a piece of code that needs to "create" a User object. Quite
> simply:
> User user = new User();
> this.userDao.save(user);
>
>
> 3) Say we have a piece of code that needs to "load" a User object. Quite
> simply:
> Integer id = <some value>
> User user = this.userDao.findById(id);
>
> Except what is "really" happening in 3)???? JPA / Hibernate is taking the
> object and automatically calling its constructor which a) invokes the
> initialization and populates created with the current time and then once the
> object is loaded from the database created is overwritten.
>
> Small problem right. Well not exactly. Imagine you have embedded objects
> that need to implicitly initialize and you have thousands of these users in
> your system say logging in... there is A LOT of unnecessary object creation
> and garbage collection right off the bat.
>
>
> Potential Solution:
>
> public User(boolean initialize) {
> if (initialize) this.initialize();
> }
>
> However for JPA Load we want:
>
> public User() { this.(*false*); }
>
> Though for Action Bean populate we want:
>
> public User() { this.(*true*); }
>
> Unfortunately we can't have the same zero argument constructor coded 2
> different ways...
>
> All would be well if I used the 1st constructor and could hook into the
> ActionBean creation point and invoke User(true) or is that a bad idea?
>
> What have others done in this case? Thoughts / recommendations?
>
> Much Appreciated!
>
> --Nikolaos
>
>
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Stripes-users mailing list
> Stripes-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
>
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
