Hi Eelco (and others),
Thanks for your post.
On 09/06/2008, at 11:37 AM, Eelco Hillenius wrote:
I don't know about Django, but I think Wicket comes with quite a
number of reusable components. And as I believe that you typically
want to customize components for your own use anyway, I think it is
more important that it is easy to create them than to have them
readily available. Anyway, are there any components you miss that e.g.
Django has but Wicket hasn't?
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).
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. Also, I can't see a high-level automatic and customisable
admin/CRUD interface for Wicket like there is for Django.
I think being able to pull together this sort of functionality quickly
into an application (i.e. reuse) and customise it is very handy -
saves re-inventing the wheel. Whether this is a result of Django
being based on Python and interpreted I am not sure.
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 don't agree with the classification. That whole article
(http://en.wikipedia.org/wiki/Web_application_framework) isn't very
well written imho. I made this comment on the wiki-talk page:
"== Push vs Pull should go ==
I've seen these terms - push and pull - used before in discussions,
but not everyone agrees on what they mean.
Sure, I agree there is some vagueness in these terms and I agree they
have little to do with component vs. non-component based Web
frameworks. But I do think there is a "push vs. pull" distinction
(although some frameworks as you say can be push and pull).
Push to me are request-oriented or (type 2) controller-driven
frameworks, e.g. where the URL drives a controller which produces the
page. These type of applications also seem to make it clear that you
are getting a request object and have to return a response object.
In Django, for example, (like I believe happens in Struts) you map out
which URL patterns will match to which functions, and then the
functions are sent the request and return a response object (usually
produced by filling in a template in a context).
Pull, on the other-hand, to me are more page-driven Web frameworks,
e.g. where the main page loads and there you go from page to page.
These type of applications seems to, generally, let you work at a
higher level of abstraction than request-response.
Of course, there is a request-response cycle going on lower down, that
one can get to if you wish, but generally speaking developers work at
a higher level. Wicket I think, like WebObjects and a lot of other
frameworks work at this level.
A quick Google showed me that some work has been done with Groovy
(wicket-contrib-groovy) and the WicketBuilder by Kevin Galligan.
However,
Kevin seems to have moved on to Seam and wicket-contrib-groovy
seems to be
no longer supported.
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.
His implementation used named closures and he mentioned (as another
poster has indicated) that he had to do various "hacks" to serialise
the closures and make it all work. I think it was more of a proof-of-
concept than anything else.
That said, I think the *brevity and structure* of the Groovy code that
he was able to use (in the pages I linked to) was really something
significant. That with the ability to have a more RAD approach was
very appealing (to me at least).
You could take a look at the integration that Grails has for Wicket.
That will let you use Groovy with Wicket, but also provides a RoR-like
rad framework.
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.
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.
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]
