On 17/08/07, Brian Cassidy <[EMAIL PROTECTED]> wrote: > Carl Franks wrote: > > Sigh, I just didn't want to mess people about by renaming all the > > Element files to CamelCase - when I did the exact opposite 5 months > > ago. > > That's really the only reason I suggested such a complicated solution. > > And I feel the current inconsistency has the potential to cause > > confusion further down the line. > > I think we're in a good spot right now because of the fact that FormFu > has yet to have a non-dev release -- we can waffle a bit with the API > and syntax.
Yes, the reason I've held off making a CPAN release, is to make sure that as far as possible, nothing is ever broken after the first public release. Still though, this change will be a pain in the arse, even for so-called alpha testers. The following one-liner should be sufficient to automatically fix most yaml form configs, but the only way to do it both bullet-proof and automatically would be to use YAML.pm - and then you'd probably loose your hash ordering. perl -lpi -e 's/(type:\s+\x{0027}?)([a-z]+)(?:_([a-z]+))?(\x{0027})?/$1.ucfirst($2).ucfirst($3).$4/e' form.yml Where 'form.yml' is your file name, of course. This handles strings without quotes and within single quotes - if you use double quotes, swap both \x{0027} for a ". Windows users will have to change the -e '' to -e "" > You claim that the "type" param is far removed from perl class names -- > i don't really agree since it basically represents which class to > initialize for that element (especially for custom elements: > "+My::Element"). I just meant that the thing we're ultimately representing - a type of xhtml form field - is far removed from what we're using to represent it - a Perl class-name. Carl _______________________________________________ HTML-FormFu mailing list HTML-FormFu@lists.scsys.co.uk http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/html-formfu