Those method names are really wrong.
Because those are not called when a request begins they are called when the response begins so it should be called onBeginRespond()/onEndRespond()

onBeginRequest() should also be there but that one should be called right after the page is reconstructed from the pagemap.
(and maybe onEndRequest should be called right after the interface handling, right before onBeginRespond())

johan




On 11/7/05, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
Maybe RequestCycle.onBegin/EndRequest is what you are looking for?

Juergen

On 11/7/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Hi Igor,
>
> >here is something i threw together that solves the deserialization >andability to use the new operator to create pages.
>
> thanks for your work on this.
>
> Regretfully it's still a solution I wouldn't like to use:
> IMHO dependency injection should not be done by the object which has the dependency. Yes, you've hidden the lookup in a base class, but nevertheless I still think that this is the wrong way around.
>
> Regarding what Eelco has written:
> > And... for this whole discussion: if you like one approach... go
> > implement it now! Create your own component factory, annotations
> > processor, aop, and please contribute when you've got something nice
> > working. Or let us know when you need specific changes to Wicket to
> > support your needs. We'll most probably honor such requests if they
> > are reasonable as we've done in the past.
>
> This is exactly what I'm talking about. Wicket should provide enough hooks for everybody to do *their* preferred approach - nothing more and nothing less.
>
> It's just that I'm missing a required hook, but perhaps I've just missed it.
> beforeCallComponent() was a step in the right direction, but I'd prefer to hook into such a notification outside of stateful code (i.e. a Page).
>
> If it is the Session, PageMap or RequestCycle, if it's on deserializing or before calling a method doesn't matter to me - it just should happen outside of the pages.
>
> Sven
>
>
> On 11/7/05, Igor Vaynberg <[EMAIL PROTECTED]> wrote:here is something i threw together that solves the deserialization andability to use the new operator to create pages. atleast i think itdoes....its really late here and all i really know so far is that itcompiles :)
>
> the idea is pretty simple, do the injection in the default constructor,and then do it anytime the object is deserialized. you use [EMAIL PROTECTED] annotation to denote the dependency. it can either be usedon a field or on a setter. If you specify the bean name it will be usedto find the bean, if you dont then the field's type or the settersargument type will be used for the lookup.
>
> -Igor
>
>
>
> On 11/7/05, Igor Vaynberg <[EMAIL PROTECTED]> wrote:and you have to have the pages defined as beans in the application context? with their properties specified?
>
> -Igor
>
>
>
>
> On 11/7/05, Igor Vaynberg <[EMAIL PROTECTED]> wrote:but how does the above handle deserealization of pages? there is nothing to reinject the dependencies.
>
> -Igor
>
>
>
>
> On 11/7/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:IMHO pages are standing on the borderline between a stateful GUI and the rest of the application in form of stateless services.
> DIshould be done by the IoC container, creating the pages can better bedone the standard Wicket way (e.g. with PageParameters).
>
> As described before I'm using a custom page factory that cooperates with a wrapped page factory and the containing bean factory:
>
> public class SpringInjectingPageFactory implements IPageFactory, BeanFactoryAware {
>
>  private AutowireCapableBeanFactory beanFactory;
>  private IPageFactory pageFactory;
>
>  public void setPageFactory(IPageFactory pageFactory) {
>  this.pageFactory = pageFactory;
>  }
>
>  public void setBeanFactory(BeanFactory beanFactory) throws BeansException {
>  this.beanFactory = (AutowireCapableBeanFactory)beanFactory;
>  }
>
>  public Page newPage(Class pageClass) {
>  Page page = this.pageFactory.newPage(pageClass);
>
>  injectDependencies(page, pageClass.getName());
>
>  return page;
>  }
>
>  public Page newPage(Class pageClass, PageParameters parameters) {
>  Page page = this.pageFactory.newPage(pageClass, parameters);
>
>  injectDependencies(page, pageClass.getName());
>
>  return page;
>  }
>
>  private void injectDependencies(Page page, String beanName) {
>  if (this.beanFactory.containsBean(beanName)) {
>    this.beanFactory.applyBeanPropertyValues(page, beanName);
>  }
>  }
> }
>
> Note that if you don't specify a name or id attribute for beans, they will be registered under their classname in Spring.
> AndNO, I don't use autowiring: applyBeanPropertyValues() does not autowirealthough it is located in AutowireCapableBeanFactory.
>
> Sven
>
> >you are right, this is not ioc. but are pages/components managed by an ioc
> >container?
> >-Igor
> >
> >
> >On 11/6/05, Alexandru Popescu <[EMAIL PROTECTED]> wrote:
> >>
> >> #: Igor Vaynberg changed the world a bit at a time by saying on 11/6/2005
> >> 7:06 PM :#
> >> > Or how about a simple solution:
> >> >
> >> > public MyApplication extends WebApplication {
> >> > public Object lookup(String name) {
> >> > Object=...do a lookup from somewhere like spring context or app
> >> object...;
> >> > return object;
> >> > }
> >> > }
> >> >
> >> > public MyPage extends Page {
> >> > public transient SomeService service;
> >> >
> >> > public SomeService getService() {
> >> > if (service==null) {
> >> > service=getApplication().lookup(SomeService.class.getName());
> >> > }
> >> > return service;
> >> > }
> >> >
> >> > I know its not quiete as elegant as ioc but it has none of the
> >> performance
> >> > hits an automatic injection would cause if it would be done on
> >> > deserialization of every component. Also its a lazy lookup so you dont
> >> do it
> >> > until its needed, and its only done once per page (until it gets
> >> > deserialized).
> >> >
> >> > -Igor
> >> >
> >>
> >> But this was exactly what I was suggesting to avoid ;-). Lookups and
> >> factories are not ioc/di.
> >>
> >> ./alex
> >> --
> >> .w( the_mindstorm )p.
> >>
> >>
> >>
> >> -------------------------------------------------------
> >> SF.Net email is sponsored by:
> >> Tame your development challenges with Apache's Geronimo App Server.
> >> Download
> >> it for free - -and be entered to win a 42" plasma tv or your very own
> >> Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
> >> _______________________________________________
> >> Wicket-user mailing list
> >> Wicket-user@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/wicket-user
> >>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server. Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Wicket-user mailing list
> Wicket-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wicket-user
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server. Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Wicket-user mailing list
> Wicket-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wicket-user
>


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Reply via email to