On Tue, Mar 08, 2005 at 12:15:48PM +0100, Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
Macros as reusable data types is OK in my (model view SoC fundamentalistic ;) ) opinion.
I wouldn't call them macros then :-)
Perhaps we should add more emphasis (via examples) on the wiki page to show that the macro concept is also shared with the bindings and templates, and not solely for form definitions.
Having a parallel syntax for all three concerns is very much on purpose. Usually (but not always) you will use parallel macros in two or three of these areas, so I was striving for the concepts and syntax to match to ease learning and use of macros.
Just wanted to point out that your first
usesace could be attaced from a different POV.
And finally my comment on the specific example: Full agreement with Daniel that there are better approaches to the label problem. (See my other email about default labels for my preference.)
That stated, I still want to create a macro extension facility which would allow the extension to modify any aspects it inherits from the base macro, including labels, validation logic, widget names, adding and/or removing widget definitions, etc. So I am not shooting down the general idea of label replacement on macro expansion, but just cautioning that it will not usually be the most fitting solution.
ok
Your other examples (credit card info with aggregate fields and validation logic, etc. used across multiple forms) much better showcase use cases for macros.
With my cForms *user's hat* on I wouldn't expect *single field* inheritance when I hear "macro" - though, for your search form example this term makes perfect sense to me.
--
Reinhard Pötz Independant Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}web(log): http://www.poetz.cc --------------------------------------------------------------------
