Title: Message
Chris,
 
please find the questions.
 
send date: 13. Nov 2004 to '[EMAIL PROTECTED]' (probably not the right list, though).

Chris,

I took a look at the ComponentTagAttributeModifier class and have a view questions:

1) ComponentTagAttributeModifier is limited to a tag in the same way HtmlTagModifier is. Thus, to localize an <input> value attribute you still need an "input"-component.

2) What is the general benefit of ComponentTagAttributeModifier compared to a component subclassing Component.handleComponentTag() which offers the same functionality. Functionality such as modifiyTag (put) and addTag().

Having two different means of modifiying tags (HtmlTagModifier and handleComponentTag) already, it is not clear to me what the benefits of ComponentTagAttributeModifier are.

3) With Wicket everything is about Components, it is 100% component based, even HtmlTagModifier is a component. ComponentTagAttributeModifier now introduces an exception to that; another container to be managed by Component; a new hierachie. From a purist point of view, we are blurring the "everything is a component" concept.

From recent mails I know that you have clusters, 10+ languages and memory consumption in mind. And I know that HtmlTagModifier, because it is a Component, adds to the component tree and makes the component's path less obvious. But because ComponentTagAttributeModifier requires a component attached to the very specific tag, you don't gain anything.

I have not much experience with large webapps. How often (how many attributes on an average page) do you need to modify an attribute based on business reasons? What tag attributes are typically the ones affected? For me obvious ones are [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] etc.. Just an idea: because Wicket is about components and not about tags, why not develop a component which is not limited to the tag, but to component's markup. This component might manage a list of regexs or jpaths or ... to address the tags (not just one tag per component, but > 1), alleviating the burden of enlarged component paths and a even larger number of components (which I guess is one of your points against HtmlTagModifier as well).

regards
Juergen


Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Christopher Turner
Gesendet: Mittwoch, 24. November 2004 11:21
An: '[EMAIL PROTECTED]'
Betreff: RE: [Wicket-develop] remove package com.voicetribe.wicket.markup. html.style?

Hi Juergen,
I believe I already did answer all questions related to attribute modifiers. Can you repost which ones I did not answer? I have searched the list archive and can't find any that I might have missed.
 
regards,
Chris
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: 24 November 2004 09:51
To: '[EMAIL PROTECTED]'
Subject: AW: [Wicket-develop] remove package com.voicetribe.wicket.markup. html.style?

Chris,
 
I send a couple of questions about the AttributeModifier to you and the list about two weeks ago. Mind you having a look at it.
 
thanks
Juergen


Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Christopher Turner
Gesendet: Mittwoch, 24. November 2004 08:44
An: '[EMAIL PROTECTED]'
Betreff: RE: [Wicket-develop] remove package com.voicetribe.wicket.markup. html.style?

Yes

>
> Can deprecated package
> 'com.voicetribe.wicket.markup.html.style' be removed?
>
> Regards,
>
>     Eelco
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from
> real users. Discover which products truly live up to the
> hype. Start reading now.
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Wicket-develop mailing list [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/wicket-develop
>
>

Reply via email to