Joerg Heinicke wrote:
On 26.11.2004 14:00, Sylvain Wallez wrote:
What you describe here comes again to an additional "output" state ...
and makes the output widget obsolete? We had this in mind since a long time ... e.g. at http://marc.theaimsgroup.com/?t=108301315200002&r=1&w=4.
Mmmh... for sure that obsoletes the output _styling_.
Not the styling itself, but writing <fi:styling type="output"/> in the template. Or am I wrong?
That's exactly what I'm talking about :-)
This hint is now added by the FormsTransformer, isn't it?
Nono, the state is transmitted as a "state" attribute, i.e. <fi:field id="blah" state="disabled"> (the "output" state doesn't exist yet).
The output widget is equivalent to <fd:field state="output"> with the difference that an output can never be modified by the user, even by changing its state to active.
So the output widget still has some use cases IMO.
I don't see them. With user you mean CForms user, so a developer? A user of the web app can not change both at all.
And for the developer:
fd:output is just a subset of <fd:field state="output">, so all use cases can be done using the latter too.
Yes, but the output widget doesn't allow browser input by setting its state to "active", which can happen on a field if its state is set to "active".
The remaining question is whether the output state allows more than the output widget does. Yes, it allows to change the state, but who does it? Whether a developer changes the field definition or the state in a flowscript - I don't see a difference.
Right, except that if for some obscure reason (a programming mistake?) the flowscript sets the state of an <output> to "active", it won't change the fact that it won't read its value on the request.
It's the same role 'developer' doing it or do you discriminate both?
Well, there may be several "developer" :-)
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
