In short: AttributeModifier can get a lot simpler:
- always add the attribute (unless the AM is disabled)
- the regexp matching functionality needs to go
- replaceModel needs to become an Object (with instanceof check for models)
- enabled field should be removed in favor of subclassing and
So AttributeAppender and SimpleAttributeModifier will not be deprecated?
On Thu, Jun 9, 2011 at 10:24 AM, Martijn Dashorst
martijn.dasho...@gmail.com wrote:
I've committed the rework for 1.5, which doesn't completely rework
AttirubteModifier and friends, but sets the stage for 1.6. I didn't
Taken from the user@ list, where it might get snowed under...
The SimpleAttributeModifier, AttributeAppender and AttributePrepender
classes are in my opinion stop gap measures to work around issues with
AttributeModifier's API.
I think that we could do better API wise with three factory methods
or builder pattern:
AttributeModifier.attr(name).model(someModel).create().append()
On Wed, Jun 8, 2011 at 12:27 PM, Martijn Dashorst
martijn.dasho...@gmail.com wrote:
Taken from the user@ list, where it might get snowed under...
The SimpleAttributeModifier, AttributeAppender and
I like the idea,
and I suggest your second approach:
AttributeModifier.overwrite(String attribute, IModel? value);
AttributeModifier.overwrite(String attribute, String value);
AttributeModifier.prepend(String attribute, IModel? value);
I like the idea of the builder pattern much better. DSLs rock!
Sent from tablet device. Please excuse typos and brevity.
On Jun 8, 2011 6:35 AM, Martin Grigorov mgrigo...@apache.org wrote:
or builder pattern:
AttributeModifier.attr(name).model(someModel).create().append()
On Wed, Jun 8,
On Wed, Jun 8, 2011 at 1:02 PM, James Carman
jcar...@carmanconsulting.com wrote:
What about the separator?
I'm thinking of ditching the separator as a constructor parameter, and
defaulting to ' ' (space). Is there anyone who uses any other value
for the separator? The attribute modifier will
I don't like the builder pattern in this case (specially with that
verbose syntax), but I kind of like the idea of method chaining for
additional (optional) configurations, with sensible defaults:
add(new AttributeModifier(class, selected)); // to overwrite the
current value
add(new
I'd prefer calling the constructor instead of static methods. It makes
it clear that you are creating a new instance, and how you could
extend the class if you needed to.
Oh, and 'for' is a reserved keyword :)
Tetsuo
On Wed, Jun 8, 2011 at 9:02 AM, Martijn Dashorst
martijn.dasho...@gmail.com
You can still use the constructors, nobody is taking that away. The
idea of these static methods is that they convey meaning
better—enhancing the readability.
add(new TextField(name,
new PropertyModelString(personModel, name))
.add(new AttributeModifier(class, foo)
yes, I wanted to say that the factory method/constructor should
contain only the mandatory data
because the first example used .for(attrName).value(attrValue)...
which can lead to missing name or value and runtime exceptions (unless
you provide default values for those :-) )
while on the topic -
On Wed, Jun 8, 2011 at 3:27 PM, tetsuo ronald.tet...@gmail.com wrote:
If you only keep the static methods, there is no point extending the class.
If you keep both setters and static methods, it would be *very* confusing.
For example:
add(new TextField(name).add(new AttributeModifier(class,
Transcript of a short IRC chat:
17:54 dashorst
ivaynberg: martin-g: I made SimpleAttributeModifier not to keep less
state but to lessen the stuff needed to instantiate a
AttributeModifier
if you're concerned about the state of AM, then override oncomponenttag
17:54 ivaynberg
once we have the
13 matches
Mail list logo
