selectBooleanCheckbox just comes from the standard, so I
didn't want to change that.

I've gotten a decent bit of feedback in the past that people
just couldn't find selectInputDate or selectInputColor, but
if they'd been called inputDate or inputColor, they would have
been found.

But looks like I should move the selectInputXyz into the "controversial"
category. :)

-- Adam


On 7/12/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

Personally I'm:

Removing the object*: +1

selectInputDate -> input Date: -1

When I give the formation, the tag with select help people understand the
tags better, like all components containing "input" allow the user to
enter a value manually, while all components containing "select" offer
some kind of assitance from valid values. Components containing both were
therefore allowing both, manual input and some kind of LoV selection. For
example, selectInputDate would be very easily identified as a component
allowing the user to enter a date by himself or select a date from a
helper, in this case a calendar. The only component that was not
respecting the rule was inputFile that was not alowing the user to enter a
file and was providing a helper.

I guess the new wanted semantic is that components containing "select"
have selectItem children, but then selectBoolean* would have to be renamed
as well (they might already have though, I cannot be sure since I lost the
original list :( )


Regards,

Simon Lessard
Fujitsu Consulting





"Adam Winer" <[EMAIL PROTECTED]>
2006-07-11 19:51
Please respond to adffaces-user

        To:     adffaces-user@incubator.apache.org
        cc:
        Subject:        Re: Re: Re: Tag renaming proposal


Glad to keep getting input on this question...  but I'm
gonna guess that the so-called "noncontroversial" list
is OK, and that we can begin renaming those tags?

Anyone with a +1 or -1 to that?

-- Adam


On 7/11/06, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
> inputLOV is shorter ...
>
> ;)
>
> On 7/11/06, Benj Fayle <[EMAIL PROTECTED]> wrote:
> > I agree that inputListOfValues is better than inputLOV.
> >
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of
> > Matthias Wessendorf
> > Sent: Monday, July 10, 2006 12:40 PM
> > To: adffaces-user@incubator.apache.org
> > Subject: Re: Re: Tag renaming proposal
> >
> > Thanks Adam,
> >
> > I found this page
> >
> > http://www.webdesignpractices.com/
> >
> > and it contains some interesting stuff.
> >
> > -Matt
> >
> > On 7/9/06, Adam Winer <[EMAIL PROTECTED]> wrote:
> > > On 7/9/06, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
> > > >
> > > > On 7/8/06, Adam Winer <[EMAIL PROTECTED]> wrote:
> > > > > separator = <hr>, more or less.
> > > > > spacer takes up some space (horizontal, vertical, or both) with
a
> > blank
> > > > > area.
> > > > >
> > > > > Make sense?
> > > >
> > > > Yeah, I would have guessed the same thing if pressed.
> > > >
> > > > I'd suggest calling separator horizontalRule (or horizontalLine --
> > > > never quite understood the rule part since a rule is for making a
> > > > line, not the line itself) if that's what it is.
> > >
> > >
> > > It's not - not necessarily.  <hr> happens to be the representation
> > right
> > > now, and it could be skinned differently.  And we might end up
> > > offering an "orientation" attribute to provide a vertical separator
-
> > so
> > > "horizontal" is too limiting, at which point I think "separator" is
> > > better than just "rule" or "line".
> > >
> > > > > For reference, the name changes that had some concerns were:
> > > > > > > navigationPath      breadCrumbs
> > > > > > > navigationTrain     train
> > > > > >
> > > > > > I haven't used adffaces, so I don't know what either of these
> > do.
> > > > > > However, the first set of names seem to imply it's something
to
> > do
> > > > > > with navigation (menus?).
> > > > >
> > > > >
> > > > > Page navigation, yes.
> > > > >
> > > > >    BreadCrumbs makes me think it's something
> > > > > > to do with cookies.    Train just draws a blank.   I have no
> > idea what
> > > > > > a "train" component would be doing.
> > > > >
> > > > >
> > > > > Both of these are, in my experience at least, common names for
> > > > > two page navigation components;  the first commonly looking
like:
> > > > >
> > > > >     Home > Shopping > Computers > MacBook Pro
> > > > >
> > > > > ... and the latter for multi-page wizards, like:
> > > > >
> > > > >    Shipping ---  Billing --- Payment -- Verify
> > > > >
> > > > > I don't know of other terms for these widgets.
> > > >
> > > > I think you're saying that the navigationPath is a multilevel
menu.
> > > > I'd stick with calling it a menu or menuPage or menuItem.
> > > >
> > >
> > > No, it's not a multilevel menu.  Check out this page:
> > >
> > > http://www.emusic.com/browse/0/b/-dbm/a/0-0/1200000354+546/0.html
> > >
> > > ... and the "Home >> Browse >> Jazz" etc.. thing in there.
> > >
> > > Breadcrumbs is an extremely common term for this UI piece;  check:
> > >   http://www.google.com/search?q=breadcrumbs%20navigation
> > > ... for an example of how often it comes up.
> > >
> > > multipage Wizard makes perfect sense to me.   I think that's better
> > than
> > > > train.
> > >
> > >
> > > But it's not a wizard in and of itself, so calling it that would be
> > > a problem.  It's merely an indicator of progress through a multipage
> > > flow.  (Train is not nearly as standard a term for this UI).
> > >
> > >
> > > > > > > selectInputText     inputLOV
> > > > > >
> > > > > > inputListOfValues would be better than inputLOV.
> > > > >
> > > > >
> > > > > I could go either way.
> > > > >
> > > > > What's the difference between adf:inputText and adf:inputLOV?
> > > > > >
> > > > >
> > > > > It lets you pop up a dialog window (using the dialog framework)
to
> > pick
> > > > a
> > > > > value,
> > > > > and have that value automatically entered into the field.  That
> > requires
> > > > a
> > > > > different base component class - more than just
> > EditableValueHolder.
> > > >
> > > > In that case, it'd probably make sense to stick popup in the name
> > > > somewhere.   inputTextPopup?  inputTextPopupList? inputPopupList?
> > > >
> > >
> > > The fact that it put up a popup isn't a rendering detail, it's a
> > component
> > > typing
> > > detail, so putting it at the end of the name goes against the grain.
> > We
> > > used
> > > to have all of these
> > "components-that-interact-with-the-dialog-framework"
> > > called "selectInput".  InputDialogText comes closer.  (And perhaps
we
> > should
> > > rename the "UIXSelectInput" base class to "UIXInputDialog"?)
> > >
> > > -- Adam
> > >
> > >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > futher stuff:
> > blog: http://jroller.com/page/mwessendorf
> > mail: mwessendorf-at-gmail-dot-com
> >
>
>
> --
> Matthias Wessendorf
>
> futher stuff:
> blog: http://jroller.com/page/mwessendorf
> mail: mwessendorf-at-gmail-dot-com
>



Reply via email to