incubator-adffaces-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Winer" <awi...@gmail.com>
Subject Re: Re: Re: Tag renaming proposal
Date Wed, 12 Jul 2006 16:26:51 GMT
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, Simon_Lessard@dmr.ca <Simon_Lessard@dmr.ca> 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" <awiner@gmail.com>
> 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 <matzew@apache.org> wrote:
> > inputLOV is shorter ...
> >
> > ;)
> >
> > On 7/11/06, Benj Fayle <bfayle@maketechnologies.com> wrote:
> > > I agree that inputListOfValues is better than inputLOV.
> > >
> > > -----Original Message-----
> > > From: mwessendorf@gmail.com [mailto:mwessendorf@gmail.com] 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 <awiner@gmail.com> wrote:
> > > > On 7/9/06, Mike Kienenberger <mkienenb@gmail.com> wrote:
> > > > >
> > > > > On 7/8/06, Adam Winer <awiner@gmail.com> 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
> >
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message