Well, it's a matter of making choices really. For Wicket it is a design
decission to make everything a component, and nest those components
hierarchical. This has advantages and disadvantages. To start with the
disadvantages: some things - like you localized labels - are more
verbose than they would be in e.g. JSP/ Struts/ etc. Though, the
<wicket:component tag lifts this a bit. Compare:
Struts:
<bean:message key="bundle.myLabel"> example </bean:message>
JSF:
<h:outputText value="#{bundle.myLabel}"> example </h:outputText>
Velocity:
${messageTool.getMessage('bundle.myLabel')}
With:
<wicket:component class="com.foo.MyLabel" key="bundle.myLabel"> example
</wicket:component>
Is that such a difference? It could be improved by having:
<wicket:component type="i18nlabel" key="bundle.myLabel"> example
</wicket:component>
Or maybe even in future:
<wicket:i18n key="bundle.myLabel"> example </wicket:i18n>
The BIG danger of the latter (actually of the component tag alltogether)
is that it is against Wicket's philosophy of not allowing any scripting
in your markup. For localized labels this would be ok, but think of the
unreadable, hard-to-maintain mess people could get themselves in when
they start using Wicket to create their custom tag libraries.
Another disadvantage of Wicket's choice NOT to be a scripting solution,
is that refactoring structure once you have it can be a nuisance.
Scripting like solutions make this much easier.
THE advantage on the other hand, just because of this nesting: it is
really, really easy to create your custom components and nest lists,
trees, panels and whatever in your forms and other components, and share
models etc just as easy. Other frameworks need a lot more plumbing for
that. Coding interaction is easy and for a large part automatic, and it
is in one place: your java code, instead of partly in your markup and
partly in you javacode (and maybe even in your xml).
So, I think whether Wicket is good for you depends on whether you're
more on the page scripting or Java/ model side of things. In my opinion,
Wicket is best suited for Java centric development, where you want to
keep things as clean as possible (maybe work with a seperate
webdesigner), want to be able to create custom components easily, and
where model interaction plays a big role. If that is not your cup of tea
however, I think JSF is quite on the other side of the spectrum,
focussed on page scripting and following a mind set that the default
components and model interaction patterns would usually suffice.
Eelco
Nick Heudecker wrote:
Maybe I'm still thinking with a Struts mindset, but doesn't that seem
just a bit excessive?
On 7/12/05, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
Wicket is very Java centric, so yes, it means that you need to add
labels as components, and if you want to attach localized strings to
them, you should use StringResourceModels.
If you want to use e.g. localized labels in your markup, you can make a
reusable component, and address it like:
<wicket:component name="label1" class="com.foo.MyLabel"
resourceKey="my.resource.label">to be replaced</wicket:component>
We didn't shout this functionality from the roofs, but it has been there
for quite some time. Inserting tags using <wicket:component could be a
bit improved too in future, like as a user being able to create a
logical name/ map lookup so that you don't have to put the full class
names in them.
Eelco
-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
