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 <[EMAIL PROTECTED]> wrote: > of course - it's just the rendering that is different. > > regards, > > Martin > > On 5/4/05, Rolf Kulemann <[EMAIL PROTECTED]> 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 > > > > >
