You may want to take a look to brix (http://code.google.com/p/brix-cms/) project. It is a wicket-based CMS framework & it also has a similar use-case like yours. Maybe you'll find their approach interesting...
Alex rmoskal wrote: > > Our application is configured after compilation. I have many different > renderers implemented as "panels with a private form" for a large > population of content types. > > When we deploy the application we have to specify the ones we want to > actually use. Since there's no compilation involved in deploying and since > we already use it for all sorts of other things (like specifying > persistence > providers, third party integration), the spring context seems like a a > natural place from which to load the > > Currently I'm thinking about implementing the functionality using jquery > in > the client. Find the appropriate ui control, decorate it and > programmatically click the next button. It's elegant in the sense that > use > case is addressed with a single change and not too fragile, since it is > done > on the page level and page is where the paging control lives. > > Again Alex, thanks for sharpening my thoughts > ___________ > Robert Moskal > Most Media > Brooklyn, USA > 347-529-4744 > > > On Tue, Dec 8, 2009 at 2:12 PM, Alex Objelean > <alex_objel...@yahoo.com>wrote: > >> >> 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 >> >> > > -- View this message in context: http://old.nabble.com/Redirect-after-for-submit%2C-but-not-what-you-think-tp26697152p26700560.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
