I think we have the problem of looking at things from two different directions. We either look it from an XML perspective, that's what you suggest, John, and that's were probably something defined through an allowedIn element should only appear in whatever it was defined to be allowed in.
However, if we start to think slightly object oriented we start to mix things. SpecParameter is a choiceDefinition. That's how I came up with the term interface - if you interpret things in a object oriented way, a choiceDefinition defines an interface (or an abstract class) implemented by whatever is defined in the choice definition (AISpec, RFSurveySpec, Custom in the case of SpecParameter). Further, if you define something to be allowed in a SpecParameter you also intend it to be allowed in a AISpec/RFSurveySpec/Custom since every instance of such a parameter is an instance of a SpecParameter. In that case, Rob's assumption that by defining something to be allowedIn a SpecParameter it would actually also be allowed in any parameter defined in the choiceDefinition is perfectly reasonable. I guess the question really is if we want to have this Java-like perspective or if we want to stick to the pure XML perspective without interpreting things. Am 8/10/09 9:22 PM schrieb "John R. Hogerhuis" unter <[email protected]>: > On Mon, Aug 10, 2009 at 11:53 AM, Basil Gasser<[email protected]> wrote: >> Hi Rob, >> >> That¹s acutally a really interesting case you created, not sure if we have a >> bug here. I think you define your parameters correctly using allowedIn, >> however, some of your parameters are defined as allowedIn for an interface >> type. For example you have <allowedIn repeat="0-1" type="SpecParameter"/> >> Now, SpecParameter is an interface implemented by AISpec, RFSurveySpec and >> Custom (where Custom is again implemented by some of your types). I assume >> that defining as allowed in SpecParameter what you actually wanted is having >> it allowed in all implementing classes. > > I'm getting confused by the jumping between levels. Classes, > interfaces? We should be able to consider this at the LTK-XML level, > only, I think. > > At LTK-XML level, our universe is Messages, Parameters, and Extension > Points. A Parameter is either allowed at an Extension Point, or it is > not. > > So if the def says <allowedIn repeat="0-1" type="SpecParameter"/> that > means that the SpecParameter Parameter can have a *whatever the > containing definition of the allowedIn clause* at SpecParameter's > extension point, everwhere SpecParameter SpecParameter appears. > <allowedIn/> is a funny contruct from an architectural point of view, > but that's how it works. > > So, I think that's what you're getting at Basil. If so, yeah that > allowedIn clause wouldn't say anything about the extension point of > any other parameter than SpecParameter. > > -- John. > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > llrp-toolkit-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ llrp-toolkit-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel
