myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Marinschek <martin.marinsc...@gmail.com>
Subject Re: [Myfaces-develop] New feature suggestion : Edit mode
Date Thu, 05 May 2005 09:32:55 GMT
yes, that is exactly my problem as well. look at the code below - I
generally have 20 fields like that per form, unmanageable at all:

            <h:panelGroup>
                <h:inputText id="editableRequestLimit"
value="#{limitDetail.limitView.requestLimit}" styleClass="text"
                    converter="#{converterBean.amountConvt}"
rendered="#{limitDetail.limitView.changeable}"/>
                <h:outputText
value="#{limitDetail.limitView.requestLimit}" styleClass="text"
                    converter="#{converterBean.amountConvt}"
rendered="#{!limitDetail.limitView.changeable}"/>
            </h:panelGroup>

In comparison, that looks rather nice:

                <h:inputText id="editableRequestLimit"
value="#{limitDetail.limitView.requestLimit}" styleClass="text"
                    converter="#{converterBean.amountConvt}" 
editable="#{limitDetail.limitView.changeable}"/>

what we do when requesting the user to duplicate the definition is in
fact create redundancy - I believe that this is unnecessary. And
really, that is very much the same as the existing editableOnUserRole
and the visibleOnUserRole attributes - you change the rendering
dependent on an attribute.

I like Sean's idea of dynamically deciding upon a renderer though, but
I am not sure if that is possible with the framework at all...

regards,

Martin


On 5/5/05, Sylvain Vieujot <svieujot@apache.org> wrote:
>  I came up with this idea, as I come from a Notes/Domino background, where
> you can have a document or document sections in edit mode or in read mode.
>  
>  Sure, you can do this with multiple fields (at least always 2), but this
> quickly turns into a maintenance nightmare, with pages very hard to read.
>  
>  When you have pages with 50+ components that can be either in edit mode or
> read mode, this becomes quite complex and generate bugs.
>  It's harder to test to, as you have to test all modes to be sure your
> edit/output components are consistent.
>  So, the easiest place to solve this is into the components, as it makes the
> application easier design and to maintain.
>  
>  This is the same logic as the one that leads to the creation of the
> enabledOnUserRole like attributes.
>  
>  A small example to show how it can greatly simplify a real-life example :
>  
>  In a client form, I have a section with the accounting informations that
> the account manager can view, but not edit, and that only the accounting
> department can edit, it the client has some status.
>  So, the formula to know it a field in this section is editable is quite
> complex.
>  
>  If I use the components without this extension, I have roughly 48
> components, and 32 of them have a complex rendered formula.
>  This is both inefficient, and hard to maintain.
>  Now, if I use the editable attribute, I only have 16 fields, which is a
> great improvement maintenance wise.
>  If now I put all those fields in an x:panelGroup with the editable
> attribute/formula, I still have those 16 fields (17 with the x:panelGroup
> one), but the editable formula is writen just once.
>  In addition to this, this is just a section of the page. In my application,
> just for the main client form, I have 6 sections. 4 of which having custom
> editable settings.
>  So, for the all form, the difference is about 128 additional components,
> and 124 additional render formulas.
>  This is definitely a real improvement, and the difference between a code
> cluttered page, and a page that can be readable & maintainable.
>  
>  Even if the concept can seem useless and just meant to add more attributes
> and/or gadgets to the x: components, in large applications, it has some real
> value.
>  
>  Sylvain.
> 
>  
>  On Wed, 2005-05-04 at 15:32 -0400, Sean Schofield wrote: 
>  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
> expression.
> 
> 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
> dynamically.
> 
> 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)
> 
> sean
> 
> On 5/4/05, Martin Marinschek <martin.marinschek@gmail.com> wrote:
> > of course - it's just the rendering that is different.
> > 
> > regards,
> > 
> > Martin
> > 
> > On 5/4/05, Rolf Kulemann <roku@apache.org> 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
> > >
> > >
> >
> 
>

Mime
View raw message