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: [email protected] [mailto:[email protected]] On Behalf Of James Carman Sent: Tuesday, August 17, 2010 4:58 PM To: [email protected] 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 <[email protected]> wrote: > It's a good usecase for metadata. No problem there. > > Martijn > > On Tue, Aug 17, 2010 at 2:59 PM, Steve Mactaggart > <[email protected]> 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 <[email protected]> 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 < >>> [email protected]> 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: [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]
