Hi Juergen,
Answers to your questions......
> Chris, please find the questions. send date: 13. Nov 2004 to '[EMAIL PROTECTED]' (probably not the right list, though).
This will be why I missed them. I don't subscribe to the wicket-develop-admin list from work, which is where I read most of the messages.
> 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.
Yes, ComponentTagAttributeModifier is limited to component tags.
The aim is to create another class called MarkupTagAttributeModifier to deal with changing tag attributes that are not represented by components. Changing markup tag attributes is significantly more complex than component tags as you have all the issues of parsing markup that may or may not be well formed; multiple instances of a tag in the markup where you only wish to change one and so on. This is why the two concepts are kept separate.
> 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.
As mentioned in my email yesterday, it is poor OO design to subclass a component in order to alter its behaviour. We should only be subclassing where the subclass represents a different real-world abstraction. I would therefore argue that there are not two different means of modifying tags. There is one means that allows new component abstractions to change the way they work with tags (handleComponentTag) and one means that allows the behaviour of an existing component to be altered (ComponentTagAttributeModifier).
Perhaps there is an argument for improving the documentation of these to explain exactly when and how each mechanism should be used.
> 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.
Not everything should be a component. HtmlTagModifier was a typical example of this. It was a concept of altering behaviour of another component. Altering behaviour should always be implemented by properties and methods of an object. Subclassing should only be used for new abstractions.
> 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.
You do actually gain something: The component tree is more logical and easy to understand because it only contains actual components that do something meaningful in the HTML. HtmlTagModifier was wrong because it forces a new object into the component hierarchy and an extra markup element in the HTML. Thus ComponentTagAttributeModifier no only simplifies the component hierarchy but also the HTML pages.
> 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..
It depends on the application and what is does. Many applications probably never have any attribute modifications on a page. In many cases the modification is usually just the class or style attributes. Where the attribute modification is really important is for changing and localization of html tags that contain text which is displayed to the user. The most common examples being buttons on forms and the alt tag of images. Pretty much any dynamically localized application that needs forms will want to change the button text. Any application that dynamically selects images (either due to localization issues or because that's the way the app works) needs to change the alt value. These two uses on their own are common enough to the specific functionality for tag attribute modification.
> 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
This is a good idea and was something I thought about. However, for a number of reasons including performance, ease of use, ease of understanding and the way Wicket deals with markup parsing I decided that a simple tag attribute modifier mechanism would be a better implementation and more along the lines of sound OO principles.
Regards,
Chris
