I don't agree with Erik that one shouldn't override isVisible. I haven't seen problems with it in my 4 years of Wicket development. The problem with these types of rules is that they tend to be taken at face value without even thinking about it. Having to maintain the state of the visible flag manually is an anti-pattern in my book.
Martijn On Thu, Jan 15, 2009 at 10:21 AM, Michael Sparer <michael.spa...@gmx.at> wrote: > > Jeremy, > > I used to do some business logic in the overriden isVisible() method too but > changed that and used setVisible in onBeforeRender. Erik summed that issue > up in his presentation on > http://www.grons.nl/~erik/pub/20081112%20Effective%20Wicket.pdf (4MB) - > slide 100 is the one containing the isVisible stuff. > > regards, > Michael > > > Jeremy Thomerson-5 wrote: >> >> Yes - typically it is a good idea to do things like service-layer / >> database >> access inside the model or inside onBeforeRender / isVisible, etc, rather >> than doing your business logic and calling setVisible(), etc. >> >> One of the main reasons for this is that if you don't, your page won't >> work >> properly when you click a link that modifies something on the page - >> because >> it doesn't reconstruct the page, and therefore you don't refresh the data >> in >> your components. >> >> On Wed, Jan 14, 2009 at 11:09 AM, behrica >> <carsten.behr...@efsa.europa.eu>wrote: >> >>> >>> Hello, >>> >>> I do something similar in a page constructor, even with accessing the >>> service layer. I have the same concerns, if this is correct. In general I >>> do >>> not like if a constructor does any significant (eventually time >>> consuming) >>> work like database access or other. But I did not find an other solution >>> neither. >>> Maybe it could be "postponed" by using a model which executes the needed >>> calls to the service layer in an lazy fashion. >>> >>> Carsten >>> >>> >>> Jonas505 wrote: >>> > >>> > Thank you for the quick reply. >>> > >>> > It's already working fine, I was just wondering if it is best practice >>> to >>> > call business logik from the constructor: >>> > >>> > public PageB(PageParameters p) { >>> > // can throw an exception: >>> > DataSet result = callMyBusinessLogik(p.getString("param1"), >>> > p.getString("param2")); >>> > preparePageBComponents(result); >>> > } >>> > >>> > Jonas >>> > >>> > From: Martijn Dashorst >>> > 14 Jan 2009 14:24:21 +0100 >>> > Subject: Re: Where to process PageParameters >>> > >>> >> setResponsePage(PageB.class, parameters); >>> >> >>> >> or use a bookmarkablepagelink >>> >> >>> >> Martijn >>> >> >>> >> On Wed, Jan 14, 2009 at 1:06 PM, Jonas505 <jonas.hoepf...@iteratec.de> >>> >> wrote: >>> >> > >>> >> > Hello, >>> >> > >>> >> > I would like to know, where in my WebPage class PageParameters >>> should >>> >> be >>> >> > processed. >>> >> > >>> >> > I have a page A where you can fill in certain parameters (or select >>> a >>> >> > predefined set of parameters). Then you submit those parameters >>> which >>> >> are >>> >> > given to the business logic to prepare some data. The resulting data >>> is >>> >> > shown on page B. I would like that the user can bookmark page B with >>> >> those >>> >> > parameters encoded in the URL. >>> >> > >>> >> > This works fine with page B having a constructor taking >>> PageParameters. >>> >> > However, right now I call the Business-Logik from the constructor of >>> >> page >>> >> B, >>> >> > which seems strange. Am I missing something or is this the way to >>> go? >>> >> > >>> >> > Thank you! >>> >> > Jonas >>> >> > -- >>> >> > View this message in context: >>> >> >>> http://www.nabble.com/Where-to-process-PageParameters-tp21454742p21454742.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 >>> >> > >>> >> > >>> >> >>> >> >>> >> >>> >> -- >>> >> Become a Wicket expert, learn from the best: http://wicketinaction.com >>> >> Apache Wicket 1.3.5 is released >>> >> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. >>> >> >>> >> --------------------------------------------------------------------- >>> >> 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 >>> > >>> > >>> > >>> >>> -- >>> View this message in context: >>> http://www.nabble.com/Where-to-process-PageParameters-tp21454742p21460425.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 >>> >>> >> >> >> -- >> Jeremy Thomerson >> http://www.wickettraining.com >> >> > > > ----- > Michael Sparer > http://talk-on-tech.blogspot.com > -- > View this message in context: > http://www.nabble.com/Where-to-process-PageParameters-tp21454742p21474018.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 > > -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.3.5 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
