Sylvain Wallez wrote:
Bruno Dumon wrote:
On Mon, 2004-04-26 at 10:43, Marc Portier wrote:
Sylvain Wallez wrote:
Marc Portier wrote:
Sylvain Wallez wrote:
- if we allow "fi:styling" in the definition (which is needed IMO), we must still retain the possibility to override it in the template. The associated logic on the template side will be much more easy to implement.
didn't think of this yet,
in any case we will need some overriding/merging rules for the @defines/@extends thing as well, I guess similar ones should apply for letting template override its definnition on certain fields
Just curious: are you planning on doing the "extending" by merging the
definitions on the XML level?
neuh, not at all, just sounds like that since the fi:* displaydata from this thread would more use that pattern
I was just refering to the fact that from a user POV the same kind of rules should apply...
Sounds weird... I would better consider this by having the definition with @extend delegate some calls to the definition it extends.
yeah, but I'ld like the definitions to become immutable to make sure we're not making errors here in this definition-reuse system (you don't want to be accidentally changing the base-definition when you're just cloning/extending it)
also it kinda feels more like the business of the builder then of the definition itself to know about these merging rules... so as far as I see now I would rather change the interface of the builders to also have a 'WidgetDefinition base' argument
wdyt? -marc= -- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
