As Sylvain already pointed out, if we allowed labels to be dynamic and
supported by framework
someone other will raise his hand and tell us he needs access key to be dynamic
and supported by the
framework. Personally speaking, I'm also against adding such feature to Forms
even though your
use-case is valid. I believe that good frameworks does not try to cover all
possible cases but only
common ones and leave enough freedom to implement solution in those rare ones.
I agree with that in part. However, I don't see why everything specified
in the definition shouldn't be dynamic . Maybe the arguement should be
the appropriateness of having the label, help, etc there in the first
place (I think that was a comment made in the thread you sent me). As
there is a work around, I am not going to press the issue.
Now, one thing I don't see a work around for is dynamically setting
min-size, max-size and initial-size for repeaters (aside from
dynamically generating the definitions, which is such a bad solution, it
isn't worth considering). Is there a workaround to this? Was there an
architectural reason for not supporting this, as this seems like a
common usecase? This is not a show stopper for me, but it is definitely
something I would like to do (for reasons similar to my original post).
I would be happy to document how I did the dynamic generation of labels,
but seeing as I am not using 2.1.8 CForms, I don't see much of a point
right now. If we ever move to 2.1.8, I will happily post instructions on
the Cocoon wiki.
Cheers.
--
Kamal Bhatt
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
