Hi again Eeclo (et al.),
Thanks for taking the time to discuss this.
On 10/06/2008, at 4:50 PM, Eelco Hillenius wrote:
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.
Ok, I understand the OO nature of components in Wicket but I guess I
will have to stop thinking of them as independent "snippet" level
components.
If there's any framework that let's you develop mini-applications
seamlessly, it's Wicket.
If one can easily build a group of components that will appear on
different pages and work together collaboratively as a whole
functional unit that's great.
The availability of such components is
another matter.
Yes, I (honestly) wonder though why more higher-level components are
not available? You suggest it is not technical.
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?
I've read a bit about them and will check them out further. I don't
believe they handle relationships (to-one and to-many) between
entities though?
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.
Yes, I understand and agree. However, the project I am doing now is
relatively small and simple and not "Enterprise class" hence I am
looking for an easy and RAD solution.
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.
Ok, that's fine.
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.
Yes, that is what I (and I think the Wikipedia page) mean by "push"
and the other approach (like Wicket) is pull.
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).
That's an interesting article but I think we have two different uses
of the terms push and pull (at least that is how I see it).
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 :-)
That very interesting, I will check it out.
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).
Yes, I agree. If using Groovy with Wicket had worked out better I
would have been quite happy indeed. I was quite excited when I first
read about it.
Unfortunately, although there has been some discussion of serialising
closures on the Groovy mailing lists but I don't believe anything has
been done about it.
I think I will just stick with plain Java Wicket or Django for the
time being.
Cheers,
Ashley.
--
Ashley Aitken
Perth, Western Australia
mrhatken at mac dot com
Skype Name: MrHatken (GMT + 8 Hours!)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
