Hello Igor,
I must object to your statement that my proposed page factory is not IoC:
Nobody says that a Spring context is the only valid container in an
application. The page factory just becomes part of the this logical
container, it is aware of and cooperates with the Sprint context.
When using IoC you always have to device which components are aware of
IoC and which not. IMHO this awareness is acceptable for page factories
and wicket applications, but not pages.
Spring is able to handle prototypes, the only unusual thing is that
pages get serialized. But with 're-injection' this is easily solved. AND
you can use strongly typed constructors too.
What I don't understand why we should talk about 'magic' solutions as
readObject() or dynamic proxies.
As Eelco wrote it:
I'd like to state very clear that we are not looking for Wicket to
become a plumbing framework; we just want to develiver a good
framework for developing web applications with enough elegant hooks
for integrating with other frameworks yourself.
IMHO to satisfy all possible requirements, these hooks shouldn't be
located on the pages.
It is easier to call from stateless code into stateful code (i.e.
RequestCycle -> Page) than the other way around.
Sven
Igor Vaynberg wrote:
Yes, it is not ioc, i never claimed it was. Sven's page factory is not ioc
either because the container does not manage the lifecycle of the page.
Does an ioc page make sense? I dont think so. I like to use the new operator
to instantiate pages myself, I also really like to have strongly typed
constructors for my pages. I dont think ioc containers are meant to be used
with these kinds of volatile objects. ioc containers are meant for more
static objects which are 90% of the time singletons. Sure there are factory
beans in spring and prototype beans, but they do not give you the freedom of
constructors. Also ioc managed objects are not meant to be serialized
outside of their container, in the webworld that is unavoidable. Dont get me
wrong, i love ioc, but i dont think its the right tool here.
I looked into the HttpSessionActivationListener. Didnt know about that
little nasty spot int he spec :) I think we can solve the problem by letting
pagemaps implement the listener interface and cascading it down to pages.
But i dont think that is a good idea because there will be a big performance
hit. Why do resolution on all the pages in the pagemap if we are only going
to use at most one of them.
Maybe the method that pulls a page out of the pagemap can call a hook on the
page, like Page.reinitialize(), and we can use that to reinject the
dependencies. Of course, this wont work for pages that store references to
other pages unless the owning page cascades down the reinitialize() call. I
just dont see an elegant solution.
Another idea which is a bit nasty but i think would work ok is to use a bit
of runtime magic. We can extract a page's interface at runtime and create a
dynamic proxy that can lazy-lookup dependencies whenever a getter is called.
So creating a page becomes a two part step, create the page and wrap the
proxy around it. The proxy should be able to serialize with the page and
deserialize fine.
-Igor
On 11/7/05, Eduardo Rocha <[EMAIL PROTECTED]> wrote:
Igor, the class you have implemented is exactly the way I was
thinking. However Sven pointed out correctly that this is not really
IoC, since the component itself is looking for its dependencies
(Alexandru said that even before...).
But even if it is not IoC, I think this is a nice approach. The client
code it would look exactly like a really IoC implementation (if
getSpringContext() is implemented in another way). And if I can live
with the Page constructor automatically attaching itself to the
Session, I could live with Pages doing serialization as well.
That said, a really IoC approach seems to be achieved either using AOP
or doing something with onBeginRequest/onBeginResponse, as Sven,
Juergen and Johan said before.
2005/11/7, Johan Compagner <[EMAIL PROTECTED]>:
And there is also a thing like XML Serialization
Which also doesn't use the java read/write object at all.
On 11/7/05, Christian Essl <[EMAIL PROTECTED]> wrote:
Hi Igor,
I looked through your code. Thanks for implementing it. I am not sure
wheter readObject() is the right place to do the (re)injection.
According
to the servlet-spec in SVR 7.7.2 readObject() is not guaranteed to be
called on session-attributes. (Instead session attributes which
implement
HttpSessionActiviationListeners are informed on deserialization). Even
if
readObject is called I am not sure wheter there is an
ApplicationContext
to get to the BeanContext.
I don't know wheter wicket has a mean to propogate these
HttpSessionEvents
on deserialization or a similar callback? If so I guess you could do
the
(re)injection there.
Christian
On Mon, 7 Nov 2005 01:13:31 -0800, Igor Vaynberg <
[EMAIL PROTECTED]>
wrote:
here is something i threw together that solves the deserialization
and
ability to use the new operator to create pages. atleast i think it
does....its really late here and all i really know so far is that it
compiles :)
the idea is pretty simple, do the injection in the default
constructor,
and
then do it anytime the object is deserialized. you use a @SpringBean
annotation to denote the dependency. it can either be used on a
field or
on
a setter. If you specify the bean name it will be used to find the
bean,
if
you dont then the field's type or the setters argument 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.
DI should be done by the IoC container, creating the pages can
better
be done 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.
And NO, I don't use autowiring: applyBeanPropertyValues() does
not
autowire although 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
--
Christian Essl
___________________________________________________________
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier
anmelden: http://mail.yahoo.de
-------------------------------------------------------
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
