What I mean is that 'separator()' and 'setSeparator()' are not that
different, so I'd prefer to keep the 'setX' convention. Not because of
the JavaBeans spec, but because the first thing I try when I want to
set a configuration on a Wicket component is to write '.set' and press
ctrl+space, the same way I write 'on' and press ctrl+space when I want
to handle an event, or 'new',ctrl+space when I want to customize the
creation of a subcomponent.
But, if by doing so it leads to error-prone syntax (say, call
'setMode(APPEND)' and forget to call 'setSeparator(" ")'), it'd be
better to break the convention. For example, 'append(" ")' sets 'mode'
and 'separator' in only one call, avoiding internal inconsistency.
Anyway, I'm confident that whoever makes this change, will try to use
the new API, and redesign it if it feels hard-to-use or error-prone,
whatever style he adopts.
On Wed, Jun 8, 2011 at 10:36 AM, Martin Grigorov <[email protected]> wrote:
> On Wed, Jun 8, 2011 at 3:27 PM, tetsuo <[email protected]> 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",
>> "foo").overwrite("width","100%"));
>>
>> yes, Eclipse would show a warning (for accessing a static method from
>> an instance), but nobody I know besides me pays much attention to
>> compiler warnings.
>>
>> I don't think we should just use setters, since it makes it much more
>> verbose. I'm ok with the DSL, but only if it makes the code more
>> terse, not more verbose. If I have to call both 'append()' and
>> 'separator(" ")', I'd rather call them 'setMode(APPEND)' and
>> 'setSeparator(" ")', but I'd much more pleased with 'overwrite(" ")'.
>>
> How your preferences are less verbose ?!
> They are several characters longer.
>
> <irony>
> As well-behaving Java developer you must use set and get for all
> accessor/mutator methods
> </irony>
> But this is just a habit and a weird standard for tools, not for
> humans. I doubt someone ever will try to create UI for editing
> AttributeModifier, or going to persist it with JPA/... If there is
> such tool then it can always use field access instead of method
> access.
>
> As I said both ways are fine for me.
>>
>>
>>
>> On Wed, Jun 8, 2011 at 10:10 AM, Martijn Dashorst
>> <[email protected]> wrote:
>>> 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 PropertyModel<String>(personModel, "name"))
>>> .add(new AttributeModifier("class", "foo")
>>> .setEditMode(EditMode.OVERWRITE)
>>> .setSeparator(" ")
>>> .setAddAttributeIfNotExists(true)));
>>>
>>> versus
>>>
>>> add(new TextFIeld("name",
>>> new PropertyModel<String>(personModel, "name"))
>>> .add(AttributeModifier.overwrite("class", "foo")));
>>>
>>> Martijn
>>>
>>> On Wed, Jun 8, 2011 at 2:52 PM, tetsuo <[email protected]> wrote:
>>>> 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
>>>> <[email protected]> wrote:
>>>>> On Wed, Jun 8, 2011 at 1:02 PM, James Carman
>>>>> <[email protected]> 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 have a setter for the
>>>>> separator, so that you can do AttrbuteModifier.append("onclick",
>>>>> "return false;").setSeparator(";");
>>>>>
>>>>> As for the fluent api... we can add that as a bonus. I'd like to keep
>>>>> the shorthand for AttributeModifier.append/prepend/overwrite
>>>>>
>>>>> Might I suggest the following fluent api:
>>>>>
>>>>> AttributeModifier.for("class").overwrites().value("error");
>>>>> AttributeModifier.for("class").appends().value(Model.of("error"));
>>>>> AttributeModifier.for("onclick").prepends().value("if(!confirm('Sure?'))
>>>>> return false;');
>>>>>
>>>>> Or perhaps:
>>>>>
>>>>> AttributeModifier.for("class").puts("error");
>>>>> AttributeModifier.for("class").appends(Model.of("error"));
>>>>> AttributeModifier.for("onclick").prepends("if(!confirm('Sure?'))
>>>>> return false;');
>>>>>
>>>>> Martijn
>>>>>
>>>>> --
>>>>> Become a Wicket expert, learn from the best: http://wicketinaction.com
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Become a Wicket expert, learn from the best: http://wicketinaction.com
>>>
>>
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
