Hi again! > -----Original Message----- > From: Sylvain Wallez [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 11, 2005 16:32 > To: dev@cocoon.apache.org > Subject: Re: Cocoon Forms library... some more questions. >
<snip/> > > > >Yes, but what is the contract of a widget with the model? > That the type stays the same? If you think about macros more > in terms of a template, then you might need to replace > something. But I agree, replace seems a little out of place. > > > > > > Hmm... I wouldn't go as far as considering macros as a > template. If you > really need that flexibility, then use a pipeline to build the form > definition! Okay... So a macro is just a container then, sort of like a wrapper? Maybe then the only one needed is "extend"? What makes a macro different from a class now? > > <snip/> > > >>What do you mean by "deep copying"? Is it copying in a > definition the > >>elements that are reused from the definition it extends? I > >>don't think > >>it should be deep: since a definition is immutable, just > copying the > >>needed information from the extended definition should be enough. > >> > >> > > > >Yes, but we want definitions to be mutable, otherwise we > cant change it anymore by extending it. > > > > ?? Why does extending a definition modify it? The extension > definition > should grab what it needs from the definition it extends, but > not modify > it. Also, how can you handle multiple definitions extending a > single one > if extending means modifying? That's why I wanted a complete clone, ie deep copy, of the definition to be extended/modified. But I see what you mean now. I guess this would work with the beanutils you mentioned before. I am a bit concerned about deeper things, like selection lists, event listeners and so on. We'll see how that goes. > > >Or Builders can somehow go around the immutability. The way > I think it might be is that definitions should be kept in the > library objects. However, multiple widgets, and therefore > definitions, might be derived from a particular definition in > the library. Since we are dealing with references all the > time, we would change the original definition object while > deriving if we didn't make a complete copy of it first. > > > > > > Hmm... Not sure I got everything, but I insist on the immutability of > definitions. If a library has changed, then it is rebuilt, and any > definitions currently in use (through instances on which users are > currently acting) still use the previous version of the definitions. Yes, of course. I wasn't talking about modifying definitions within a library, but rather modifying a copy of a definition from a parent library. So changing definitions while they are in use wouldn't happen. But I guess its just the difference or responsibility, who copies who. My first thought was that the library, when asked for a definition, returns a new definition which looks exactly like the one within the library. But we can do it the other way, that the library/macrodefinition asking the parent library gets the real definition and accesses whatever it needs. We would need some copy constructors then here and there. > > >Ah: Or the builders would be kept by the library. Then they > can pump out new definition objects for every time one is > requested. This would mean though that the builders would > have some state, which is not the case right now. And I guess > the whole point was to _not_ reparse the xml all the time. > > > > > > Builders parse the XML and build definitions from it. If a library is > stored as a set of definitions, I don't see why reparsing the > XML would > be needed when a definition uses a library? Exactly, but if it were stored as a set of builders which know how to generate new definitions, then they would have to know something about what they just parsed in order not to reparse the xml again and again. But storing the builders doesn't make sense, so don't worry about it. I was just thinking aloud. Thinking again, maybe it can work like this: 1. A builder starts generating the widgetdefinition from xml 2. The builder instantiates a new definition 3. The builder sees an "extends" attribute, asks the local library (given as a parameter to buildWidgetDefinition()) for that definition 4. The builder calls super.setupDefinition(widgetElement,newDefinition,baseDefinition), baseDefinition may be null if this widget does not inherit 5. The builder goes through all widget-specific settings, taking the base definition into account where necessary/possible (this might just access private members of the other definitions, without having to go through the getter/setter stuff used by BeanUtils) 6. The definition is returned By local library, I mean the Library object which would be used to resolve extends. This might be the Library object that is being build at the moment or a member of the form which is being build, since macro definitions can also occur directly in forms. This also preserves the separation between definition builder vs definition, since all building knowledge should be in the builder. So, a definition doesn't have to know what to copy, the builder does it. This would also solve the first question I had, since it implies resolving macros at definition-build-time. What do you think? Bye! max
