incubator-adffaces-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon_Less...@DMR.CA
Subject Re: Re: Re: Tag renaming proposal
Date Wed, 12 Jul 2006 14:34:58 GMT
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