What are you really trying to accomplish here?
I think you're on the right path only one thing I would mention, the page constructor is not called only once per application life cycle. Same page can be constructed multiple times if you have a link going to that page and you calll setResponsePage(new MyPage()). More on detachable models: https://cwiki.apache.org/WICKET/detachable-models.html ~ Thank you, Paul Bors On Mon, Feb 18, 2013 at 12:47 PM, Michael Chandler < michael.chand...@onassignment.com> wrote: > Good morning/afternoon everyone. > > I'm having a basic problem fully deciphering how to best manage my forms, > specifically related to Models that are attached to forms. Since a Wicket > WebPage has it's constructor invoked only one time in the application > lifecycle, I'm failing to fully understand how to present a form that has a > model bound to it without inadvertently sharing that instance of the Model > with every user of the application. It seems like a fundamental issue that > I'm failing to fully grasp and could use some input. > > As an example, I have the following in my constructor: > > LoadableDetachableModel<Job> jobModel = new LoadableDetachableModel<Job>() > { > > private static final long serialVersionUID = 1L; > > @Override > protected Job load() { > Job job = (Job) EntityFactory.getInstance().getBean("job"); > > // if we're editing an existing job, load the object > if (jobId >= 1) { > job.load(jobId); > } > > return job; > } > > }; > > I later create a form and after adding it in my constructor, bind the > model to it as follows: > > jobForm.setModel(new CompoundPropertyModel<Job>(jobModel)); > > As you can imagine, every user session from this point on now has that > instance of a Job object bound to that form due to these declarations being > in the page constructor. I have come a long way on my own, but I'm at a > point where I clearly do not have a full grasp of how to best approach > this. I suspect I can potentially override an instance of a Model's > getObject() method for more dynamic behavior, but I'm concerned about > writing code that becomes too verbose when perhaps there's a better/tighter > way to handle this. Can anyone advise me? > > Many thanks! > > Mike Chandler > >
