> Sorry, I used the wrong term there.  I didn't mean specifically components
> as in "parts of a dynamic Web page" but rather what Django calls
> "applications" (which really are components in the more general sense of the
> word - how's that for confusing ;-).
>
> Django Web applications can be composed of a number of (smaller)
> applications (basically another subdirectory in the site directory).  AFAIK,
> these can be complete high-level functionality (e.g. email-confirmation for
> registration, surveys, feeds etc).

Actually, you can build such 'applications' as components in Wicket.
That's the beauty of the fact that Wicket's components are truly self
contained. State, navigation, you name it, everything can be put in
components and it doesn't leak to outside unless you design it that
way. Develop a registration component, survey component, feeds
component and put it in any page, together with any combination of
components you want. This is  t h e  w h o l e  i d e a  with Wicket's
components :-)

> I guess these could be done with Wicket add-on frameworks (i.e. JARs) but I
> just don't see that many (please correct me if I am wrong) at this level.

If there's any framework that let's you develop mini-applications
seamlessly, it's Wicket. The availability of such components is
another matter.

>  Also, I can't see a high-level automatic and customisable admin/CRUD
> interface for Wicket like there is for Django.

Not sure what you're looking for, but something like
http://wicketwebbeans.sourceforge.net/ or
http://sourceforge.net/projects/wicket-rad?

> Please don't misunderstand me, I am not criticising Wicket - I think it is
> fantastic, I'm just trying to understand why it may / needs to lack the RAD
> and large-scale functionality reuse that something like Django seems to
> provide.

I really think it's just a matter of what we want to focus on. With
'we' I mean the core team and community here that works on Wicket. I
don't know Django well, but RoR for instance is very focussed on the
RAD part. Wicket doesn't aim to be a RAD development framework, but
instead provides a framework that is extensible so you or other people
can build stuff like that on top of it. Personally I believe that RAD
stuff is nice to score projects and show some quick results, but I
care way way more about the longer term. If I can scale a development
team and if the project still is easy to get around in and refactor
half a year down the line.

> Push to me are request-oriented or (type 2) controller-driven frameworks,
> e.g. where the URL drives a controller which produces the page.

I don't want to be blunt, but I just think that the push-pull
classification is too vague and arbitrary to be in that WIKI article.
In this case, it's perfectly fine to speak about for instance 'front
controller'/ 'web mvc' or 'model 2' (which is kinda the official term
Sun gave it a long time ago) frameworks rather than pull-push. The way
I've seen pull-push being used in the context of discussions about
frameworks, it always referred to model 2 frameworks and more
importantly to frameworks that allow some scripting in templates, and
in that case, 'pull' refers to lazy evaluation whereas 'push' means
everything has to be calculated up-front. The only somewhat agreeable
piece on this - imho - is
http://www.antlr.org/wiki/display/ST/Introduction. But imho, the pull
vs push thing is relevant for a framework like Wicket (or GWT or Echo
for that matter).

>> I couldn't find that he moved on, but it is possible the project isn't
>> maintained anymore.
>
> He has confirmed to me via email that he has moved to using Seam.

Ok. Seam with JSF, or Seam with Wicket? Seam ships with Wicket support
nowadays :-)

> I will have another look but from what I understand Grails is like Django /
> RoRs another push Web framework that focuses on mapping URLs to controller
> methods.  From what I see, the Wicket integration either requires you to use
> Java or extras classes in Groovy.

I really don't know enough about Grails to say :-) You could check with them.

> Personally I still think there is room for a Web framework that is:
>        + fully component-based,
>        + pull-oriented (but allowing push for when it is useful),
>        + full separation between HTML and application (like Wicket does),
> and allows one to use a dynamic language (for RAD).  Something based on
> Groovy (because of its close ties to Java) and Wicket (because of its great
> approach and separation) would be very elegant and powerful.

I think it is a matter of building on a framework like Wicket. Why
start over again? The whole idea of components is that you make
something more complex out of simpler parts. And there's really no end
to what you can do with that (within the confines of web applications
obviously).

Cheers,

Eelco

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to