Re: Re: Re: [Wicket-user] My take on Spring integration
if you want to create youre own page factory. And use PagePArameters for everything to supply params back and forth you are ofcourse free to do that right now. On 10/25/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >>An EditUserPage for example cannot be bookmarkable>>because it needs to know which user to edit.IMHO an EditUserPage parameterized with a userId is a perfect match for a bookmarkable URL. I didn't say, I'd never use setResponsePage(..).If I have large transactional state to be transferred to another page, I'd use setResponsePage(..) too. But I have no problem in this case to delegate the construction of the page to a factory.Sven>Furthermore, it is an excellent way of passing models/ other state to pages.>>Eelco>>On 10/24/05, Johan Compagner < [EMAIL PROTECTED]> wrote:>> i completely agree with igor.>> I use setResponsePage(new XxxPage(yy)) all over the place.>> I find this kind of code the most readable what you can get. >> No magic. A person can directly see what really happens. johan On 10/24/05, Igor Vaynberg < [EMAIL PROTECTED]> wrote:>> > > >> 2) to use the page factory your pages can only have the default or>> > > >> PageParameter constructors. This prevents you from doing >> > > things like>> > > >> setResponsePage(new EditUserPage(userId));>> > >>> > > That is the price to pay for IoC: you have to let the factory>> > > create the beans. >> > > BTW I don't think setResponsePage(new ...Page()) is so much>> > > useful afterall, since AFAIK it prevents bookmarkable links.>> >>> > Yes, it prevents bookmarkable pages, but do you need every page to be a >> > bookmarkable page? An EditUserPage for example cannot be bookmarkable>> > because it needs to know which user to edit. If you start putting>> > information like the userId into PageParameters you are creating >> > soft-dependencies just like urls. A constructor EditUserPage(long userId)>> is>> > much more understandable instead of EditUserPage(PageParameters p);>> >>> > -Igor >> >>> >>> >>> >>> > --->> > This SF.Net email is sponsored by the JBoss Inc.>> > Get Certified Today * Register for a JBoss Training Course >> > Free Certification Exam for All Training Attendees Through End of 2005>> > Visit http://www.jboss.com/services/certification for >> more information>> > ___>> > Wicket-user mailing list>> > Wicket-user@lists.sourceforge.net >> > https://lists.sourceforge.net/lists/listinfo/wicket-user>> --- >This SF.Net email is sponsored by the JBoss Inc.>Get Certified Today * Register for a JBoss Training Course>Free Certification Exam for All Training Attendees Through End of 2005>Visit http://www.jboss.com/services/certification for more information>___>Wicket-user mailing list>Wicket-user@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/wicket-user---This SF.Net email is sponsored by the JBoss Inc.Get Certified Today * Register for a JBoss Training CourseFree Certification Exam for All Training Attendees Through End of 2005Visit http://www.jboss.com/services/certification for more information___Wicket-user mailing listWicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: Re: Re: [Wicket-user] My take on Spring integration
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 itdoesits 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 {
> >> > pub
Re: Re: Re: [Wicket-user] My take on Spring integration
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?JuergenOn 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 itdoesits
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 abou
