On 17 July 2014 17:43, Igor Vaynberg <igor.vaynb...@gmail.com> wrote:
> On Thu, Jul 17, 2014 at 9:08 AM, Garret Wilson <gar...@globalmentor.com>
> wrote:
> > On 7/17/2014 8:25 AM, Martin Grigorov wrote:
> >>
> >> ...
> >>
> >> For some reason this feature doesn't seem that usable to me...
> >
> >
> > Could you be more specific about why you don't find this feature doesn't
> > seem useful? None of your comments below were about the feature
> > itself---they were about ancillary implementation details, such as
> whether
> > the "assert" keyword should be used.
> >
> > This feature proposal is based upon the following assumptions:
> >
> > * Many developers will want to use the Wicket framework with
> > third-party frameworks that require certain attributes and/or CSS
> > classes in certain circumstances.
> > * Adding third-party library support shouldn't require subclasses a
> > lot of components. (Otherwise, I'd have a PureCSSButton, and I'd
> > have to instantiate PureCSSButtons throughout the code... until I
> > changed frameworks, at which point I'd have to change them all to
> > BootStrapButtons.)
> > * Third-party library support should be isolated from main UI code and
> > from business logic. That is, I shouldn't have have to go add
> > PureCSSAttributeBehaviors to all my buttons throughout the code,
> > intermingled with my CSS framework-agnostic code.
> >
> >
> > If one of those assumptions are invalid, let me know. Otherwise, do you
> have
> > an alternative approach for me to easily add Pure CSS support for all my
> > buttons (for example) in one locations without going through all my UI
> code,
> > and then tomorrow to switch to using the Bootstrap framework (with its
> > different required attributes for buttons and such) without changing all
> my
> > code? If there is an alternative, great. But I don't see how you can say
> > there is no need for such a feature.
>
> there is no need for the wrapper you provide. everything you want is
> already possible using IComponentInstantiationListener - which you
> already use.
> there are a few issues with the convenience wrapper:
>
> * you are forcing developers to share the behavior instance across
> multiple components
>
> this may be undesirable in some cases and inconvenient because it
> forces the behavior design to be stateless or store data using
> metadata instead of fields. while ok for simple things like appending
> a class it makes developing more complex behaviors difficult.
>
> * the mapping is not flexible enough
>
> suppose you want a link that opts out of this behavior for whatever
> reason. maybe you do it by implementing some interface on the link.
> now all methods in the behavior have to check for this interface. much
> easier to check for the interface and just not add the behavior.
>
> * the wrapper doesnt provide any real value
>
> its just a convenience and one that doesnt work for the 90% case. how
> many lines of code does it save? not many.
>
> we dont add such wrappers because they blow up the api surface area.
>
> -igor
>
>
>
> >
> > Garret
> >
> >
>
From a user who lurks on the dev list, I feel it's worth adding my 0.02
BTC.
(or is this where I reveal I've been using Wicket all wrong *-)
I view raw markup
<input type=? ...>
the same way as I view (from another recent dev post) hard coded string
constants
assert t.getName().equalsIgnoreCase("a");
They are both "typed" as far as the compiler is concerned.
But to an application they are untyped.
Is the:-
* string: really a user name, email, url, password, part reference,
supplier name...
* number: really a sale price, height, duration, stock quantity ...
In my application I've abstracted (almost)all fields, away from raw inputs
and instead use a meaningful class to handle a specific input type.
For example I use stock quantity fields in many places. A (simple view of)
stock quantity consists of a numeric amount and some unit of measure.
[ 50] Kg
[230] Each
All the user of such a field has to supply is
code
someForm.add(new StockQtyField(id, model, ....))
markup
<wicket:container wicket:id="saleQty"/>
along with the appropriate model for the value in question.
This is repeated for currency amounts, business specific reference fields,
common drop downs and various string fields etc.
It means that if I need to change from say Bootstrap to 'latest trendy css
framework' I reimplement the ~40 or so field classes (and markup), and the
thousands of places which use them are automatically correct.
Of course each of the business input fields is free to use fancy behaviours
to wrap input fields.
<TL;DR>
So back to the topic of this thread. From my POV, I see little use in being
able to bundle behaviour with an untyped input field in order to make some
css framework happy.
--
Peter Henderson
