myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Schofield <>
Subject Re: [Myfaces-develop] New feature suggestion : Edit mode
Date Wed, 04 May 2005 19:32:33 GMT
Martin has a good point about the panel group.  That does make it a
bit more cumbersome (4 lines instead of 1.)  Although you could argue
that the approach I suggested is still more transparent.

This is the approach I took with tree2.  To use standard JSF
conventions to solve a problem whenever possible b/c this is the
common framework that all JSF programmers will be familiar with.   So
instead of rendering html links in the tree, just let the user specify
whether they want one or not using h:commandLink and a facet.  So that
is the argument for simplicity/flexability and the expense of a few
extra lines.

Rolf's idea concerning a "dynamic renderer" sounds interesting,
however.  Perhaps we could explore that a little more.  JSF of course
allows you to specify which renderer to use for which component but
that is done statically via the faces-config.xml, etc.  It might be
interesting to have several different renderers for a piece of data
that you could swap based on the results of a value binding

So you could use the existing text component, create a custom tag and
then create 1...n custom renderers.  This is probably what you would
do anyways even if you didn't have the renderer be dynamic right?  The
added step could be that you could determine how to render

Another use case could be a list of values.  If the field should not
be editable you could make the current selection displayed as plain
text (instead of disabling the combo box.)

My 2 cents,  (US$ so less than 2 Euro Cents at the moment)


On 5/4/05, Martin Marinschek <> wrote:
> of course - it's just the rendering that is different.
> regards,
> Martin
> On 5/4/05, Rolf Kulemann <> wrote:
> > On Wed, 2005-05-04 at 18:44, Martin Marinschek wrote:
> > > Well, MyFaces tries to remain in the Spec as much as possible in any
> > > of the core classes and the core components - extended components have
> > > far left the functionality described in the spec ;)
> > >
> > > so these attributes would of course only be implemented in the x:... components
> >
> > Yes, but I still think, that inputText and outputText semantics should
> > not be mixed, whether in the x:* components or somewhere else. A
> > inputText is and inputText and not a outputText, although a inputText
> > can be non-editable, but is stays an inputText.
> >
> > Sorry for my blue-eyedness :)
> >
> > --
> > Rolf Kulemann
> >
> >

View raw message