On Thu, Jun 20, 2013 at 10:02 AM, Colin Rogers < [email protected]> wrote:
> Martin, > > I do a lot of generic stuff within my code - developing common components, > that dynamically determine a page based on variable criteria. Those pages > then need to be initialised - using reflection - and have data and state > set on them. And I also do a 'panel switching' thing - similar to Facebook > - where only the parts of a page that need updating get updated, but the > app pushes the 'bookmarkable' part to the browser so the page can still > bookmarked, hit in browser history and refreshed, as per normal page. For > that I need to create a page - using reflection - and effectively steal the > parts of the new page that require updating, add that to the current page > and update those elements via Ajax. > > Ultimately, PageProvider is a really nice way of simply selecting a page > of type X, and not having to call getConstructor() - with or without > PageParameters - then new instance and having tons of checked exceptions > being caught all over my code. It's a nice way of passing around the > combinations of Class, or Class and PageParameters, or a page instance - in > a generic way. > You can use IPageFactory for to create page instance from class (+page parameters). See org.apache.wicket.Application#getPageFactory(). > > I see your point tho - I'm effectively using a Class for something it's > not designed for and you shouldn't have to cater for my quirky use of it. > Having said that, I could easily create my own version - that does that any > more, and be lighter weight... :) > > Although... #setResponsePage could at least take a IRequestablePage, no? :) > Yes. org.apache.wicket.request.cycle.RequestCycle#setResponsePage() already works with IRequestablePage. I don't see why Component#setResponsePage() still requires Page. This will be improved only in Wicket 7. > > Cheers, > Col. > > -----Original Message----- > From: Martin Grigorov [mailto:[email protected]] > Sent: 20 June 2013 16:39 > To: [email protected] > Subject: Re: setResponsePage > > Hi, > > PageProvider is more an internal API. There is a ticket that it is complex > and needs some kind of simplification. > I don't want to expose it more to the user APIs. > How exactly you find it more convenient than the current > #setResponsePage() versions ? > It has constructors that accept renderCount and pageId, but those are > usually extracted from the request url. In your code you should not deal > with them. > > > On Thu, Jun 20, 2013 at 4:55 AM, Colin Rogers < > [email protected]> wrote: > > > Wicketeers, > > > > Super-minor API thing... > > > > I've started using PageProvider class within our frameworks, as it's a > > really convenient class for detailing pages, etc. and avoid having to > > use Reflection directly. > > > > With this in mind, would it be possible to overload > > Component#setResponsePage that takes a PageProvider or IPageProvider? > > > > Cheers, > > Col. > > EMAIL DISCLAIMER This email message and its attachments are > > confidential and may also contain copyright or privileged material. If > > you are not the intended recipient, you may not forward the email or > > disclose or use the information contained in it. If you have received > > this email message in error, please advise the sender immediately by > > replying to this email and delete the message and any associated > > attachments. Any views, opinions, conclusions, advice or statements > > expressed in this email message are those of the individual sender and > > should not be relied upon as the considered view, opinion, > > conclusions, advice or statement of this company except where the > > sender expressly, and with authority, states them to be the considered > view, opinion, conclusions, advice or statement of this company. > > Every care is taken but we recommend that you scan any attachments for > > viruses. > > > EMAIL DISCLAIMER This email message and its attachments are confidential > and may also contain copyright or privileged material. If you are not the > intended recipient, you may not forward the email or disclose or use the > information contained in it. If you have received this email message in > error, please advise the sender immediately by replying to this email and > delete the message and any associated attachments. Any views, opinions, > conclusions, advice or statements expressed in this email message are those > of the individual sender and should not be relied upon as the considered > view, opinion, conclusions, advice or statement of this company except > where the sender expressly, and with authority, states them to be the > considered view, opinion, conclusions, advice or statement of this company. > Every care is taken but we recommend that you scan any attachments for > viruses. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
