Notice my reply wasn't to your email. It was to Martijn's. :) On Tue, Aug 17, 2010 at 5:09 PM, Alex Rass <a...@itbsllc.com> wrote: > No. > I mean: > You can getSession() to get to the session object. > (I saw you use that so I know you know about it) > But in your Application class, you can create whatever session object you > want as long as it overrides the right class (there's a method for creating > the session you'd override). > Then you add your setters and getters to that session class of yours and use > them when you need to. > > - Alex > > > -----Original Message----- > From: jcar...@carmanconsulting.com [mailto:jcar...@carmanconsulting.com] On > Behalf Of James Carman > Sent: Tuesday, August 17, 2010 4:58 PM > To: users@wicket.apache.org > Subject: Re: Best Practice passing data between Bookmarkable pages > > You mean metadata on the session? > > On Tue, Aug 17, 2010 at 9:11 AM, Martijn Dashorst > <martijn.dasho...@gmail.com> wrote: >> It's a good usecase for metadata. No problem there. >> >> Martijn >> >> On Tue, Aug 17, 2010 at 2:59 PM, Steve Mactaggart >> <st...@whitesquaresoft.com> wrote: >>> We do pass params for the actual page's content, but this is >>> transient information that I don't want leaking into my URLs. Its >>> usually a simple text message, so I'll look into Session#info(), but >>> I have had some success with my earlier ideas of setMetaData. >>> >>> Is there a true purpose for setMetaData? or am I using it a dodgy way? >>> >>> I can forsee (fairly soon) a need to render more complex items than >>> just a simple string and it seems that (as long as its Serializable) >>> I can put anything in MetaData. >>> >>> Steve >>> >>> On Tue, Aug 17, 2010 at 7:23 PM, Josh Kamau <joshnet2...@gmail.com> > wrote: >>> >>>> HI Steve; >>>> >>>> When i want to maintain bookmarkable pages, i normally pass the >>>> record primary key in the PageParameters map . Once i have the >>>> primary key on the next page, i can use my dao to retrieve the object > and may be "float a div" >>>> to display the record. >>>> >>>> On Tue, Aug 17, 2010 at 10:57 AM, Steve Mactaggart < >>>> st...@whitesquaresoft.com> wrote: >>>> >>>> > Hi all, >>>> > >>>> > I have a simple problem that I wanted to cast out to the wider >>>> > Wicket community for a best practice. >>>> > >>>> > We try and use BookmarkablePageLinks for as much as we can, >>>> > obviously so that pages can be bookmarked. Therefore nearly every >>>> > page is constructed via the PageParameters method. >>>> > We have a lot of pages that list items, allow a user to create a >>>> > new >>>> item, >>>> > edit, delete, a pretty standard CRUD workflow. >>>> > >>>> > The problem is that I want to notify the user about the the save >>>> > of the save on the next page. If the save fails we stay on the >>>> > edit page, and that works fine. >>>> > But if the save succeeds we redirect back to another page using >>>> > setResponsePage(Class, PageParams). >>>> > >>>> > What I want to do on this page (no matter what page it is) is to >>>> > display >>>> a >>>> > little floating div showing the record just saved, its transaction # > etc. >>>> > >>>> > In the old world I would just push my saved object notification >>>> > into the Session, and then on all pages check for this value and >>>> > then display and remove it. >>>> > Is this still the best practice? >>>> > >>>> > I was looking at using something like >>>> > getSession().setMetaData(MetaDataKey, Serializable) to store the >>>> > the notification details, but couldn't see a way to remove the >>>> > MetaData >>>> (unless >>>> > setting to null is right) >>>> > >>>> > Is this right or is there a more "wicket" way of doing this. >>>> > >>>> > Cheers, >>>> > Steve >>>> > >>>> >>> >> >> >> >> -- >> Become a Wicket expert, learn from the best: http://wicketinaction.com >> Apache Wicket 1.4 increases type safety for web applications Get it >> now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.8 >> >> --------------------------------------------------------------------- >> 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