Yeah, Wicket would look more like Tapestry then. And what would the
advantage be? Your XML would look horrible (like with access paths for
individual components), and it would just serve the purpose of
avoiding the service lookup pattern (which in my opinion really isn't
that bad when done right). What I like about annotations is that it
keeps things close to your code. Maybe not a good idea for everything
in the world, but in this case I like it. Alternatives would be to use
XDoclet or working with tagging interfaces. If we would get
annotations working, XDoclet would be no problem either I think.
Eelco
On 8/22/05, Koen Serry <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I seem to agree with Huy since not all developers are already too
> anxious to start using annotations or jdk1.5 for that matter, although
> it would be a good solution for say wicket 2.0.
>
> As for the XML, wouldn't that be like tapestry'ing wicket? I keep to my
> original though of having something like a global variable in the
> application class.
>
> Koen
>
>
> Huy Do wrote:
>
> > Eelco Hillenius wrote:
> >
> >> Sorry guys, but I wasn't able to reserve enough free time to do an
> >> irc chat.
> >>
> >> I have been thinking about Spring integration a bit more though, and
> >> the only thing I can think of to make it really nice is to use
> >> (runtime) annotations. I was thinking about letting Wicket (actually
> >> a few utility classes that come in a seperate package, e.g
> >> wicket-extensions-spring) do the wiring using spring like:
> >>
> >> class MyForm extends Form {
> >>
> >> @Dependency("myDaoName")
> >> private MyDAO foo;
> >>
> >> etc...
> >> }
> >>
> > why introduce something new if you are integrating an existing
> > technology ? Wouldn't it make sense that if you are integrating
> > spring, you would use whatever spring used for configuration ? I would
> > assume that you want spring integration to attract existing spring
> > users or potential spring users. If that is the case, using what
> > spring users are use to i.e xml configuration (although I hate xml
> > just as much as others on this list) would make much more sense
> > because they wouldn't need to learn or be familiar with another method
> > regardless of how simple it appears to be (for simple cases at least).
> > Its a question of "I already" know spring, so can bring all that
> > knowledge (baggage) to wicket without having to climb another hill (in
> > terms of spring).
> >
> >> I know, it will take a while before JDK1.5 will be available for the
> >> large public, but this is something I would like to support, while I
> >> definitively don't want to go the xml route. The advantage of trying
> >> to implement something like this, is that we can learn what parts of
> >> the Wicket API aren't flexible enough yet to support this. And once
> >> that is clear and fixed, it opens the way for alternative
> >> implementations if people want that.
> >>
> > Quite dangerous to force jdk 1.5 on everyone who wants to use spring.
> > Spring supports 1.3 for a reason.
> >
> >> What do you think?
> >>
> >> Eelco
> >>
> >>
> >>
> >> Eelco Hillenius wrote:
> >>
> >>> We could even have an online conference (IRC) with the people who
> >>> are interested/ want to contribute to this topic. We (core devs)
> >>> sometimes work like that, and I find it really boosting to
> >>> brainstorm like that and write some code right away. Interested?
> >>> This weekend?
> >>>
> >>> Eelco
> >>>
> >>
> >>
> >>
> >>
> >>
> >>
> >> -------------------------------------------------------
> >> 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
>
>
>
>
> -------------------------------------------------------
> 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
