I haven't looked in-depth at the Spring stuff, but there seem to be a couple of
different view points around when it comes to Spring integration. Maybe we
should start a Wiki item on this topicus. More specifically:
- What do people want to achieve? What kind of wiring would they like to be
done by Spring? Wire DAOs etc to their pages? Or have them immediately
available from your pages (service lookup)? And do you want fancy configuration
of your WebApplication class done by Spring (I guess that's no problem at all
now), and are there other things people want to do.
Discussing on this list is more convenient, but by creating a Wiki item, we
might make the specs more persistent.
Eelco
-----Oorspronkelijk bericht-----
Van: Koen Serry [mailto:[EMAIL PROTECTED]
Verzonden: vr 19-8-2005 14:33
Aan: [email protected]
CC:
Onderwerp: Re: [Wicket-user] Spring Integration
Hi
I did before posting to this mailing list, but as I found the construct
a bit weird to me I was thinking if an alternative would be possible.
Like the SpringApplicationController creates a new instance of the
servlet to then assign the application to it, or the SpringContextLocator is
implemented as a singleton/factory requiring the page to pass the request to
it.
I was just wondering if this could be a plausable alternative since it
seems like a lot of overhead just to get to the applicationContext.
Koen
Juergen Donnerstag wrote:
please have a look at sourceforge project wicket-stuff which
contains
additional higher level component. It contains also a modul with
different alternatives on how to integrate with Spring. I think
there
is even a example application in there.
Juergen
On 8/19/05, Koen Serry <[EMAIL PROTECTED]> <mailto:[EMAIL
PROTECTED]> wrote:
Hi all,
I've been looking into Wicket for a couple of days now
and I have to say
I like what I see so far from a web framework point of
view.
However I have a couple remarks/questions with regards
to Spring
integration or IOC integration in general for that
matter.
So far I've been using tapestry and in tapestry 3 it
was pretty easy,
you subclassed the engine class, put the
applicationContext in it, and
from whatever page-class you could access it. In
Tapestry 4 however,
they haven't found a clean way so that's one of the
reasons I was moving
to Wicket.
Now would it be possible to keep some kind of
global(Map) in Wicket as a
way of putting/getting 'other' items in the Application?
Since you're pretty much required to subclass the
Application class and
it gets initialized with the WicketServlet pretty much
immediately. This
would allow the ApplicationContext of spring or some
frequently used
items like a sessionFactory of Hibernate (if you didn't
want to use
Spring) to be easely accessed from each page to be
used. As then the
only thing it would require is like
getApplication().get("spring") or if
you'd use ognl getApplication().get("spring.mydao").
What do you guys think?
Koen Serry
http://www.serry.org
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software
Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development
Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects &
Teams * Testing & QA
Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference &
EXPO
September 19-22, 2005 * San Francisco, CA * Development
Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams *
Testing & QA
Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
HS^�隊X�J�'���u����^�J�����
��z��q�<䞦צm���m��NRjqkjw"�� 7�zZ)���.'�s'%x��rz�
�W���î+ޜ7�zZ)���1�ڂ)�>�#y�lM榱7��)[EMAIL PROTECTED]
0����o۱ǹ���rG��ǫ����x%��V�� �� �X���(�� ~��zw���i�����l���q����z����l�X��)ߣ�"rG��ǫ
