Gordon, we changed the LTKJava implementation to allow references to ChoiceDefinition to align it with the other implementations. However, from conversations with Rob it seems that we implemented the <allowedIn> referencing a ChoiceDefinitions different from what the C* (C, Cpp, C#) implementations have done. We assumed that the C* implementations implemented option a) below, but from Rob's comments it seemed that the C* implementations use approach b). Is that correct?
<allowedIn> referring to instance of <choiceDefinition> a) extension parameter is allowed in any parameter that is listed by choiceDefinition if it has a custom field (in the case of SpecParameter, the extension is allowed in AISpec and in RFSurvey (both of which have Custom fields)) b) extension parameter is allowed as parameter in ChoiceDefinition referenced if instance has a custom field. This is identical to referencing the parent parameter of the ChoiceDefinition instance in the <allowedIn>. In this particular case, this would be allowedIn ROSpec. Christian Gordon Waidhofer wrote: > LTKC, LTKCPP (C++), and LTKNet all support <allowedIn> referring to > <choiceDefinition>s. It is quite necessary. > > -gww > > > -----Original Message----- > From: Christian Floerkemeier [mailto:[email protected]] > Sent: Monday, August 10, 2009 1:51 PM > To: LLRP Toolkit Development List > Subject: Re: [ltk-d] LTK Java and Custom Parameters > > > thanks, Basil. I guess LTK is more complicated than just messages, > parameters and extension points :). > > I'd vote for not allowing references to choiceDefinitions in allowedIn > statements. llrpdef.xsd says that the allowedIn element references > entities of the allowedInParameterReference type (and not > allowedInChoiceAndParameterReference). While references to parameter > definitions only are of course not enforced by llrpdef.xsd, the naming > suggests the use of parameter and not choice definitions. For LTKJava, > allowing reference to choiceDefinitions would also mean additional work. > > I'd be interested though whether the other implementations allow > references to choiceDefinitions in the allowedIn construct and interpret > this as "allowed in any of the parameters belonging to this > ChoiceDefinition". At the end of the day, it is important that the > different implementations of the LTK are aligned. > > Christian > > > > > > Basil Gasser wrote: >> 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 > > > ------------------------------------------------------------------------------ > 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 ------------------------------------------------------------------------------ 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
