checkAccess() is called per Page after intialization. Though meant for
access check, it can serve your purpose as well. And IMO there are
even more: onRender, onComponentTagBody etc.

Juergen


On Wed, 23 Mar 2005 12:49:15 -0500, Gili <[EMAIL PROTECTED]> wrote:
> 
>     But Page has no onBeginRequest(). What do you do then?
> 
> Gili
> 
> Jonathan Locke wrote:
> 
> >
> > there is no need for this.  there are already two phases of init
> > before the rendering cycle.  you can override onBeginRequest to
> > perform extra initialization if you really need to.  but 99% of the
> > time you won't even need to do this...
> >
> > Gili wrote:
> >
> >>
> >>    The biggest problem I currently have (related to this issue) is
> >> that I manipulate the sturucture -- calling add() -- in the
> >> constructor but this requires me to get call getApplication() and
> >> getPage() at certain points and this isn't actually available yet.
> >>
> >>    It would be good to move to a no-arg constructor, formal structure
> >> building method (should be called after the user has add()ed the
> >> component into the parent, so now it is available), and *then* a
> >> rendering phase.
> >>
> >> Gili
> >>
> >> Juergen Donnerstag wrote:
> >>
> >>> +1 for change. But I've currently no time to do it. Someone else has
> >>> to.
> >>>
> >>> Juergen
> >>>
> >>>
> >>> On Tue, 22 Mar 2005 10:49:53 +0100, Christopher Turner
> >>> <[EMAIL PROTECTED]> wrote:
> >>>
> >>>
> >>>> Maurice, Yes, I agree that it doesn't solve every single case.
> >>>> However, the most
> >>>> common place that lazy loaded collections will be used is in list
> >>>> views and
> >>>> thus building the structure prior to rendering solves the most
> >>>> common case
> >>>> that I have encountered. For the much smaller number of cases where
> >>>> this is
> >>>> not the case then I'm quite happy to pre-initialize any lazy loads
> >>>> that I
> >>>> know I am going to need for the current use case.
> >>>>
> >>>> regards,
> >>>> Chris
> >>>>
> >>>> -----Original Message-----
> >>>> From: [EMAIL PROTECTED]
> >>>> [mailto:[EMAIL PROTECTED] Sent: 22 March
> >>>> 2005 09:12
> >>>> To: [email protected]
> >>>> Subject: RE: [Wicket-develop] major rendering phase change
> >>>>
> >>>>
> >>>>
> >>>> +1 for the change too.
> >>>>
> >>>> Sorry Chris but what you are saying here does not make sense to me.
> >>>>
> >>>> In the rendering your model is going to get accessed, this model
> >>>> may contain
> >>>> a lazy loaded collection. So you still need to have the hibernate
> >>>> session
> >>>> running at rendering time.
> >>>>
> >>>> Unless you would have accessed the lazy collection before, causing
> >>>> it to
> >>>> load, but in order to do that in a generic way you would pretty
> >>>> much have to
> >>>> copy the behavior of rendering (without writing to the output
> >>>> stream) and
> >>>> that would (I m o) be wrong.
> >>>>
> >>>>
> >>>>
> >>>> I you see things different let me know.
> >>>>
> >>>>
> >>>>
> >>>> Maurice
> >>>>
> >>>>
> >>>>
> >>>> -----Oorspronkelijk bericht-----
> >>>> Van: Christopher Turner [mailto:[EMAIL PROTECTED] Verzonden:
> >>>> dinsdag 22 maart 2005 10:00
> >>>> Aan: '[email protected]'
> >>>> Onderwerp: RE: [Wicket-develop] major rendering phase change
> >>>>
> >>>>
> >>>>
> >>>> I'm +1 for this change having already discussed it with Jon
> >>>> previously. I
> >>>> think the decoupling of making the structure of the page from the
> >>>> rendering
> >>>> also has some other advantages. On particular I can think of right
> >>>> away is that Hibernate lazy loaded collections are easier to use as
> >>>> you don't need
> >>>> to keep the session factory/transaction active for the whole rendering
> >>>> process.
> >>>>
> >>>> Regards, Chris
> >>>>
> >>>>
> >>>>> given a particular problem in versioning and some anticipation of
> >>>>> a horde of other problems, i think we need to change our model for
> >>>>> rendering components a little.  eelco and maurice verbally agree,
> >>>>> but we'd like any feedback from the list too.  the versioning
> >>>>> problem is that urlFor() can be called during rendering to create
> >>>>> a url of version N.  if a component further down the page makes a
> >>>>> structural change while rendering, it will increase the version at
> >>>>> that time, resulting in urls further down the page having version
> >>>>> N + 1.  the root problem here is one that chris and i wanted to
> >>>>> fix some time ago and one that seems worth fixing: once rendering
> >>>>> begins, the component hierarchy should be immutable.  any attempt
> >>>>> to change the structure during rendering would result in an
> >>>>> exception.  to implement this change, we'll have to change
> >>>>> ListView (yet again... sorry juergen!!) so that it has a component
> >>>>> building (populate) phase and a render phase which are decoupled.
> >>>>> i think this is a really good change, but i could be missing
> >>>>> something too... does anyone see any problems with this?
> >>>>>            jon
> >>>>>
> >>>>>
> >>>>> ------------------------------------------------------- SF email
> >>>>> is sponsored by - The IT Product Guide Read honest & candid
> >>>>> reviews on hundreds of IT Products from real users. Discover which
> >>>>> products truly live up to the hype. Start reading now.
> >>>>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396> &op=click
> >>>>> _______________________________________________
> >>>>> Wicket-develop mailing list [email protected]
> >>>>> https://lists.sourceforge.net/lists/listinfo/wicket-develop
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>> -------------------------------------------------------
> >>> SF email is sponsored by - The IT Product Guide
> >>> Read honest & candid reviews on hundreds of IT Products from real
> >>> users.
> >>> Discover which products truly live up to the hype. Start reading now.
> >>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> >>> _______________________________________________
> >>> Wicket-develop mailing list
> >>> [email protected]
> >>> https://lists.sourceforge.net/lists/listinfo/wicket-develop
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >> -------------------------------------------------------
> >> This SF.net email is sponsored by: 2005 Windows Mobile Application
> >> Contest
> >> Submit applications for Windows Mobile(tm)-based Pocket PCs or
> >> Smartphones
> >> for the chance to win $25,000 and application distribution. Enter
> >> today at
> >> http://ads.osdn.com/?ad_id=6882&alloc_id=15148&op=click
> >> _______________________________________________
> >> Wicket-develop mailing list
> >> [email protected]
> >> https://lists.sourceforge.net/lists/listinfo/wicket-develop
> >>
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
> > Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
> > Embedded(r) & Windows Mobile(tm) platforms, applications & content.
> > Register
> > by 3/29 & save $300
> > http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click
> > _______________________________________________
> > Wicket-develop mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/wicket-develop
> >
> >
> 
> -------------------------------------------------------
> This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
> Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
> Embedded(r) & Windows Mobile(tm) platforms, applications & content.  Register
> by 3/29 & save $300 http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click
> _______________________________________________
> Wicket-develop mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/wicket-develop
>


-------------------------------------------------------
This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
Embedded(r) & Windows Mobile(tm) platforms, applications & content.  Register
by 3/29 & save $300 http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop

Reply via email to