Wicket is unmanaged framework. I've never have seen a wicket code which would use instantiation of panels using spring. I don't know I understand it... do you have some special use-case? Can you describe it? My first thought is, that this is some sort of over engineering which doesn't bring you any advantage.
Alex rmoskal wrote: > > Thanks Alex. It does seem a like a slightly old-fashioned way of doing > things. My factory instantiates the Panels by reflection from the class > name > (kept in a spring file). I personally don't know how to create an > anonymous > class when I instantiate something using the reflection api. I suppose I > could pass in an interface that is to be called by the onSubmit method or > change the factory to create an anonymous subclass of my panels, but all > this seems like a lot of work to accomplish such a simple thing. > > I will keep thinking on it and will post if I come up a less obtrusive way > to handle this. You have helped me focus my thoughts. > > Regards, > > Robert > ___________ > Robert Moskal > Most Media > Brooklyn, USA > 347-529-4744 > > > On Tue, Dec 8, 2009 at 1:05 PM, Alex Objelean > <alex_objel...@yahoo.com>wrote: > >> >> You can define a default behavior (for instance no redirect after submit) >> & >> apply redirect only for few pages. It is a nice solution... it reminds me >> about template method design pattern. >> >> Alex >> >> >> rmoskal wrote: >> > >> > I could do that, but would be nicer if I didn't have to touch n classes >> or >> > create a class hierarchy for my Panel. I don't like my Page knowing so >> > much >> > about what goes on in my Panels either. >> > >> > Thanks! >> > >> > Robert >> > ___________ >> > Robert Moskal >> > Most Media >> > Brooklyn, USA >> > 347-529-4744 >> > >> > >> > On Tue, Dec 8, 2009 at 12:44 PM, Alex Objelean >> > <alex_objel...@yahoo.com>wrote: >> > >> >> >> >> You don't have to expose your private panels. Just create a protected >> >> method >> >> which handles the form submission & override it in inherited >> components. >> >> >> >> Alex Objelean >> >> >> >> >> >> rmoskal wrote: >> >> > >> >> > That's just what I don't want to do. My forms live as private >> classes >> >> on >> >> > a >> >> > panel (one form per one style of panel). I don't want to have to >> >> > introduce >> >> > n new panels to handle the case where I wan to do the redirect. I >> was >> >> > hoping I could do it in one place (kind of like an aop after advice >> :). >> >> > ___________ >> >> > Robert Moskal >> >> > Most Media >> >> > Brooklyn, USA >> >> > 347-529-4744 >> >> > >> >> > >> >> > On Tue, Dec 8, 2009 at 12:09 PM, Alex Rass <a...@itbsllc.com> wrote: >> >> > >> >> >> So: always override onSumbit for the buttons and *sometimes* >> redirect. >> >> >> Tis all. >> >> >> >> >> >> - Alex >> >> >> >> >> >> -----Original Message----- >> >> >> From: Robert Moskal [mailto:rmos...@mostmedia.com] >> >> >> Sent: Tuesday, December 08, 2009 12:05 PM >> >> >> To: users@wicket.apache.org >> >> >> Subject: Redirect after for submit, but not what you think >> >> >> >> >> >> Hi all: >> >> >> >> >> >> I'd like to be able to redirect after I submit a form, basically I >> >> want >> >> >> my >> >> >> app to navigate to the next question in a survey after a user >> >> responds. >> >> >> But >> >> >> I don't want to do this in the onClick method of the form buttons, >> >> >> because >> >> >> I >> >> >> only want to do this sometimes. In other words sometimes I want to >> >> >> deploy >> >> >> an application where I do the auto-navigation and sometimes I want >> the >> >> >> user >> >> >> to stay on the same page after submitting. >> >> >> >> >> >> The ideal place seems to be on the page level. but it seems you >> can't >> >> >> call >> >> >> setResponsePage in the onDetach method. Where in request >> life-cycle >> >> >> would >> >> >> be the place to do this sort of redirect? >> >> >> >> >> >> Thanks and regards, >> >> >> ___________ >> >> >> Robert Moskal >> >> >> Most Media >> >> >> Brooklyn, USA >> >> >> 347-529-4744 >> >> >> >> >> >> >> >> >> >> --------------------------------------------------------------------- >> >> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> >> >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> >> >> >> >> >> >> > >> >> > >> >> >> >> -- >> >> View this message in context: >> >> >> http://old.nabble.com/Redirect-after-for-submit%2C-but-not-what-you-think-tp26697152p26697704.html >> >> Sent from the Wicket - User mailing list archive at Nabble.com. >> >> >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> >> >> >> > >> > >> >> -- >> View this message in context: >> http://old.nabble.com/Redirect-after-for-submit%2C-but-not-what-you-think-tp26697152p26698038.html >> Sent from the Wicket - User mailing list archive at Nabble.com. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > -- View this message in context: http://old.nabble.com/Redirect-after-for-submit%2C-but-not-what-you-think-tp26697152p26699099.html Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
