You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by T P D <li...@diffenbach.org> on 2009/03/30 23:15:31 UTC
Why should the programmer specify how a SingleSelectChoice looks?
What I really like about Wicket is that it -- much more than JSPs --
allows the separation of HTML markup from Java code. No "c:if"ing with a
Domain Specific Language like JTSL (or Velocity macros) inside HTML
markup and side-by-side with javascript. In Wicket, in contrast, HTML
markup contains only HTML and Wicket tags, which look just like
HTML tags. That's it.
But I think this could be taken a bit farther, and I'd like the list's
thoughts on a proposal.
Wicket imposes one constraint on markup: roughly, any HTML element with
a "wicket:id" attribute must match a Wicket Component, a Java Object, in
the Java code. More precisely, the HTML element tree (considering only
"wicket:id" elements) must (with a few exceptions) match the Wicket
Component tree rooted at the Wicket Page.
But -- in my opinion -- Wicket goes a bit too far in enforcing this. In
particular, there are at least three ways to allow a web page user to
select one thing from a list of several things:
A drop down list, like this:
<select><option>one</option><option>two</option></select>
A list that scrolls but doesn't drop down, as above but with the
select tag given a "size" attribute.
Or, a group of radio buttons, like this:
<input type=radio>one</input><input type=radio>two</input>
To the application and its programmer, these are all the same
functionality: present some choices, find out which SINGLE choice the
user selects. How that looks on the page is immaterial to the
application's functionality.
To the page designer, these are all different, presenting different
looks, talking up different amounts of screen space, each with a
slightly different learning curve for the user. In particular, novice
web users may not even realize the drop down is a choice and can be
clicked on, dropped down, and changed.
If the page designer decides that, say, he's dealing with a less
web-savvy population, and wants to change the dropdown to a group of
radio buttons, someone has to send a change request to the Java programmer.
Then the programmer has to change some or all instances of one class
derived from AbstractSingleSelectChoice (e.g., DropDownChoice) to
another (e.g., RadioChoice). Which shouldn't happen; the way the choice
is rendered has nothing to do with the the page's functionality.
In Model-View-Controller terms, the rendered look is purely up to the
Model; the functionality purely the domain of the Controller.
Would it be useful to have a Wicket Component that automatically
rendered whichever type look the page designer wants, further decoupling
web page designer's View from Programmer's Controller, while
providing a single uniform functional interface to the application?
Thanks or reading, and I hope to hear your feedback.
--Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Why should the programmer specify how a SingleSelectChoice looks?
Posted by Igor Vaynberg <ig...@gmail.com>.
i dont see anything wrong with it.
-igor
On Mon, Mar 30, 2009 at 3:07 PM, T P D <li...@diffenbach.org> wrote:
> Well, actually, I have done it, by abstracting out the rendering by having
> onTagComponent and onTagComponentBody, in a class derived from
> AbstractSingleSelectChoice, delegate to a GOF Strategy Pattern.
>
> I then have four strategies: one each for dropdown, dropdownlist, and
> radiochoice, and a fourth strategy that delegates to one of the other three
> depending on the tag in the HTML markup file. (And of course other
> programmers can derive from the AbstractStrategy to do whatever they want.)
>
> Using any of the first three strategies essentially gives the user the
> functionality of the existing Wicket classes DropDownChoice, ListChoice, and
> RadioChoice, tying that instance of the Component to one strategy. Using the
> fourth allows the rendering to vary based on the HTML markup.
>
> It renders nicely.
>
> But I wanted to broach this as "is this a good idea", and only if people
> said "yes", then talk about my implementation, and extending the same
> pattern to the multiple choice Components.
>
> Thanks,
> --Tom
>
> Igor Vaynberg wrote:
>>
>> there isnt anything really stopping you from doing this. afaict you
>> already have all the wicket hooks to do this.
>>
>> -igor
>>
>> On Mon, Mar 30, 2009 at 2:15 PM, T P D <li...@diffenbach.org> wrote:
>>>
>>> What I really like about Wicket is that it -- much more than JSPs --
>>> allows
>>> the separation of HTML markup from Java code. No "c:if"ing with a Domain
>>> Specific Language like JTSL (or Velocity macros) inside HTML markup and
>>> side-by-side with javascript. In Wicket, in contrast, HTML markup
>>> contains
>>> only HTML and Wicket tags, which look just like
>>> HTML tags. That's it.
>>>
>>> But I think this could be taken a bit farther, and I'd like the list's
>>> thoughts on a proposal.
>>>
>>> Wicket imposes one constraint on markup: roughly, any HTML element with a
>>> "wicket:id" attribute must match a Wicket Component, a Java Object, in
>>> the
>>> Java code. More precisely, the HTML element tree (considering only
>>> "wicket:id" elements) must (with a few exceptions) match the Wicket
>>> Component tree rooted at the Wicket Page.
>>>
>>> But -- in my opinion -- Wicket goes a bit too far in enforcing this. In
>>> particular, there are at least three ways to allow a web page user to
>>> select
>>> one thing from a list of several things:
>>> A drop down list, like this:
>>> <select><option>one</option><option>two</option></select>
>>>
>>> A list that scrolls but doesn't drop down, as above but with the select
>>> tag given a "size" attribute.
>>>
>>> Or, a group of radio buttons, like this:
>>> <input type=radio>one</input><input type=radio>two</input>
>>>
>>>
>>> To the application and its programmer, these are all the same
>>> functionality:
>>> present some choices, find out which SINGLE choice the user selects. How
>>> that looks on the page is immaterial to the application's functionality.
>>>
>>> To the page designer, these are all different, presenting different
>>> looks,
>>> talking up different amounts of screen space, each with a slightly
>>> different
>>> learning curve for the user. In particular, novice web users may not even
>>> realize the drop down is a choice and can be clicked on, dropped down,
>>> and
>>> changed.
>>>
>>> If the page designer decides that, say, he's dealing with a less
>>> web-savvy
>>> population, and wants to change the dropdown to a group of radio buttons,
>>> someone has to send a change request to the Java programmer.
>>>
>>> Then the programmer has to change some or all instances of one class
>>> derived
>>> from AbstractSingleSelectChoice (e.g., DropDownChoice) to another (e.g.,
>>> RadioChoice). Which shouldn't happen; the way the choice is rendered has
>>> nothing to do with the the page's functionality.
>>>
>>> In Model-View-Controller terms, the rendered look is purely up to the
>>> Model;
>>> the functionality purely the domain of the Controller.
>>>
>>> Would it be useful to have a Wicket Component that automatically rendered
>>> whichever type look the page designer wants, further decoupling web page
>>> designer's View from Programmer's Controller, while providing a single
>>> uniform functional interface to the application?
>>>
>>> Thanks or reading, and I hope to hear your feedback.
>>> --Tom
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Why should the programmer specify how a SingleSelectChoice looks?
Posted by T P D <li...@diffenbach.org>.
Well, actually, I have done it, by abstracting out the rendering by
having onTagComponent and onTagComponentBody, in a class derived from
AbstractSingleSelectChoice, delegate to a GOF Strategy Pattern.
I then have four strategies: one each for dropdown, dropdownlist, and
radiochoice, and a fourth strategy that delegates to one of the other
three depending on the tag in the HTML markup file. (And of course other
programmers can derive from the AbstractStrategy to do whatever they
want.)
Using any of the first three strategies essentially gives the user the
functionality of the existing Wicket classes DropDownChoice, ListChoice,
and RadioChoice, tying that instance of the Component to one strategy.
Using the fourth allows the rendering to vary based on the HTML markup.
It renders nicely.
But I wanted to broach this as "is this a good idea", and only if
people said "yes", then talk about my implementation, and extending the
same pattern to the multiple choice Components.
Thanks,
--Tom
Igor Vaynberg wrote:
> there isnt anything really stopping you from doing this. afaict you
> already have all the wicket hooks to do this.
>
> -igor
>
> On Mon, Mar 30, 2009 at 2:15 PM, T P D <li...@diffenbach.org> wrote:
>> What I really like about Wicket is that it -- much more than JSPs -- allows
>> the separation of HTML markup from Java code. No "c:if"ing with a Domain
>> Specific Language like JTSL (or Velocity macros) inside HTML markup and
>> side-by-side with javascript. In Wicket, in contrast, HTML markup contains
>> only HTML and Wicket tags, which look just like
>> HTML tags. That's it.
>>
>> But I think this could be taken a bit farther, and I'd like the list's
>> thoughts on a proposal.
>>
>> Wicket imposes one constraint on markup: roughly, any HTML element with a
>> "wicket:id" attribute must match a Wicket Component, a Java Object, in the
>> Java code. More precisely, the HTML element tree (considering only
>> "wicket:id" elements) must (with a few exceptions) match the Wicket
>> Component tree rooted at the Wicket Page.
>>
>> But -- in my opinion -- Wicket goes a bit too far in enforcing this. In
>> particular, there are at least three ways to allow a web page user to select
>> one thing from a list of several things:
>> A drop down list, like this:
>> <select><option>one</option><option>two</option></select>
>>
>> A list that scrolls but doesn't drop down, as above but with the select
>> tag given a "size" attribute.
>>
>> Or, a group of radio buttons, like this:
>> <input type=radio>one</input><input type=radio>two</input>
>>
>>
>> To the application and its programmer, these are all the same functionality:
>> present some choices, find out which SINGLE choice the user selects. How
>> that looks on the page is immaterial to the application's functionality.
>>
>> To the page designer, these are all different, presenting different looks,
>> talking up different amounts of screen space, each with a slightly different
>> learning curve for the user. In particular, novice web users may not even
>> realize the drop down is a choice and can be clicked on, dropped down, and
>> changed.
>>
>> If the page designer decides that, say, he's dealing with a less web-savvy
>> population, and wants to change the dropdown to a group of radio buttons,
>> someone has to send a change request to the Java programmer.
>>
>> Then the programmer has to change some or all instances of one class derived
>> from AbstractSingleSelectChoice (e.g., DropDownChoice) to another (e.g.,
>> RadioChoice). Which shouldn't happen; the way the choice is rendered has
>> nothing to do with the the page's functionality.
>>
>> In Model-View-Controller terms, the rendered look is purely up to the Model;
>> the functionality purely the domain of the Controller.
>>
>> Would it be useful to have a Wicket Component that automatically rendered
>> whichever type look the page designer wants, further decoupling web page
>> designer's View from Programmer's Controller, while providing a single
>> uniform functional interface to the application?
>>
>> Thanks or reading, and I hope to hear your feedback.
>> --Tom
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Why should the programmer specify how a SingleSelectChoice looks?
Posted by Igor Vaynberg <ig...@gmail.com>.
there isnt anything really stopping you from doing this. afaict you
already have all the wicket hooks to do this.
-igor
On Mon, Mar 30, 2009 at 2:15 PM, T P D <li...@diffenbach.org> wrote:
> What I really like about Wicket is that it -- much more than JSPs -- allows
> the separation of HTML markup from Java code. No "c:if"ing with a Domain
> Specific Language like JTSL (or Velocity macros) inside HTML markup and
> side-by-side with javascript. In Wicket, in contrast, HTML markup contains
> only HTML and Wicket tags, which look just like
> HTML tags. That's it.
>
> But I think this could be taken a bit farther, and I'd like the list's
> thoughts on a proposal.
>
> Wicket imposes one constraint on markup: roughly, any HTML element with a
> "wicket:id" attribute must match a Wicket Component, a Java Object, in the
> Java code. More precisely, the HTML element tree (considering only
> "wicket:id" elements) must (with a few exceptions) match the Wicket
> Component tree rooted at the Wicket Page.
>
> But -- in my opinion -- Wicket goes a bit too far in enforcing this. In
> particular, there are at least three ways to allow a web page user to select
> one thing from a list of several things:
> A drop down list, like this:
> <select><option>one</option><option>two</option></select>
>
> A list that scrolls but doesn't drop down, as above but with the select
> tag given a "size" attribute.
>
> Or, a group of radio buttons, like this:
> <input type=radio>one</input><input type=radio>two</input>
>
>
> To the application and its programmer, these are all the same functionality:
> present some choices, find out which SINGLE choice the user selects. How
> that looks on the page is immaterial to the application's functionality.
>
> To the page designer, these are all different, presenting different looks,
> talking up different amounts of screen space, each with a slightly different
> learning curve for the user. In particular, novice web users may not even
> realize the drop down is a choice and can be clicked on, dropped down, and
> changed.
>
> If the page designer decides that, say, he's dealing with a less web-savvy
> population, and wants to change the dropdown to a group of radio buttons,
> someone has to send a change request to the Java programmer.
>
> Then the programmer has to change some or all instances of one class derived
> from AbstractSingleSelectChoice (e.g., DropDownChoice) to another (e.g.,
> RadioChoice). Which shouldn't happen; the way the choice is rendered has
> nothing to do with the the page's functionality.
>
> In Model-View-Controller terms, the rendered look is purely up to the Model;
> the functionality purely the domain of the Controller.
>
> Would it be useful to have a Wicket Component that automatically rendered
> whichever type look the page designer wants, further decoupling web page
> designer's View from Programmer's Controller, while providing a single
> uniform functional interface to the application?
>
> Thanks or reading, and I hope to hear your feedback.
> --Tom
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org