myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Korhonen, Kalle" <kkorh...@cisco.com>
Subject RE: [Myfaces-develop] New feature suggestion : Edit mode
Date Thu, 05 May 2005 20:01:19 GMT
Mmm.. good point, if we kept inputText as is (and its readonly is
reserved for html input attribute readonly), but implemented
x:editableText with attribute readonly, which would then render either
inputText or outputText, we wouldn't need to add new attributes and
would avoid the semantical problem of rendering inputText as outputText.
A good compromise, no?

Kalle

> -----Original Message-----
> From: Thomas Spiegl [mailto:thomas.spiegl@gmail.com] 
> Sent: Thursday, May 05, 2005 12:47 PM
> To: MyFaces Development
> Subject: Re: [Myfaces-develop] New feature suggestion : Edit mode
> 
> I'd suggest to use the readonly attribute in association with 
> a new renderer type and new jsp-tags. The advantage would be, 
> that the same attributes could be used as for the existing 
> components. Just the rendering behaviour concerning the 
> readonly attribute would be different. Myfaces' extended 
> components shouldn't get overloaded with new functionality & 
> attributes, above all this could lead to misunderstandings 
> (as Rolf mentioned).
> I think new tags would bring out the differences more clearly.
> Anyway the InputText's readonly attribute should be set to 
> false, when rendered as OutputText. Otherwise the decode 
> method would not work correct!
> 
> naming proposal:
> renderer-type: org.apache.myfaces.Text2
> renderer-class: HtmlTextRenderer2 (extending
> org.apache.myfaces.renderkit.html.ext.HtmlTextRenderer)
> tag-names: inputText2, ..
> 
> This would bring clear separtion and would not mean too much effort.
> 
> regards, Thomas
> 
> >inputText should definitely support @editable. If I 
> understand you guys 
> >correct, you think editable="false" means, the component is 
> rendered as 
> >an outputText. IMHO it should be rendered as a readonly input field.
> >
> ><input ... readonly="true" .../>
> >
> >Otherwise, two different concepts/semantics are mixed, which is bad 
> >imho.
> >
> >Makes sense?
> >
> >  
> >
> 
> >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