I'm not a big fan of semi-coding in xml. So I prefer a different approach: Instead of all those nested/sibling condition/etc change it to a more abstract thing. Introduce a <validator/> tag. By default it actually maps to ConditionBasedValidator which reads all those <condition/> elements and works based on those nested elements. We can introduce more sophisticated and reusable validators: EjbSpecSensitiveValidator represented as <EjbSpecSensitiveValidator/> or <validator class="EjbSpecSensitiveValidator "/>. And of course you should be able to create a chain of validators (which is easy to do with nested validator elements).
The important thing is: You can write all possible condition combinations with condition/etc elements, so let's refactor it a bit and make it more flexible. It also fits more nicely with the XTags stuff: a Validator can be attached to the XTagBean, we (xdoclet, xdocletgui) can ask it to validate the input. Ara. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:xdoclet-devel- > [EMAIL PROTECTED]] On Behalf Of Aslak Hellesoy > Sent: Tuesday, July 09, 2002 5:00 AM > To: [EMAIL PROTECTED] > Subject: RE: [Xdoclet-devel] xtags DTD > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of Andrew > > Stevens > > Sent: 8. juli 2002 22:01 > > To: [EMAIL PROTECTED] > > Subject: Re: [Xdoclet-devel] xtags DTD > > > > > > A wise old hermit known only as Konstantin Priblouda > > <[EMAIL PROTECTED]> once said: > > > > > <condition type="tag-param"> > > > <condition-parameter>ejb:bean</condition-parameter> > > > > > > <condition-parameter>view-type</condition-parameter> > > > <condition-parameter>remote</condition-parameter> > > > </condition> > > > > > > > > > If it still does not suit your needs, we can try to > > > add condition which pokes into xdoclet parameters. > > > > > > But this would require to move all the xtags stuff > > > into xdoclet core from xdocletgui ( this is already planned > > > I think... ) > > > > Yeah, I spotted that one (tag-param), but I don't think that'll do it; > > it's a config parameter I need to test, not a tag parameter i.e. if > > ejbspec = 1.1 use one optionset, if ejbspec >= 2.0 use the other. Of > > course, that means xdocletgui would need somewhere to specify the > ejbspec > > version you want to use (I don't know if it does or not, I've not looked > > at it much yet), and I have a suspicion it'll need changes to the DTD. > > > > We might have to redesign the condition mini-framework. It's centered > around > XProgramElement now. -Evaluating whether a condition holds for a given > XProgramElement (superinterface of XClass, XMethod etc.). > > It seems obvious that we'll have to evaluate conditions based on other > factors, like the one you mention here. Here are some suggestions: > > 1) xtags.condition.Condition.eval(xjavadoc.XProgramElement) can be > refactored to xtags.condition.Condition.eval(java.lang.Object). The > consequence of this would be a more flexible evaluation system. Each > Condition subclass can cast the argument to an expected class and perform > the evaluation. In the config parameter scenario, it could be cast to e.g. > xdoclet.ConfigParameter or perhaps some Version class we want to define. > The > drawback is typeunsafeness. The advantage is minaimal API changes. > > 2) xtags.condition.Condition.eval(xjavadoc.XProgramElement) can be > refactored to xtags.condition.Condition.eval() (no argumanets). This would > require various setters to be called prior to validation. If we go for > this > approach, we can make an XProgramElementCondition class that defines the > setProgramElement(xjavadoc.XProgramElement). A parallel class hierarchy > could be made for config parameters and other things. I like this approach > better, because it's more typesafe. > > Whatever approach we choose, nothing prevents us from modifying the DTD > now. > Currently, we're using the DTD merely to validate the xtags.xml which in > turn is currently mostly used for HTML doc generation. > > I suggest you modify the xtags.dtd to add a new condition type > (config-param) in the condition ATTLIST. Then we can worry about > implementation details later, when the much-talked-about xtags start to > emerge. > > Aslak > > > > > Andrew. > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Oh, it's good to be a geek. > > http://thinkgeek.com/sf > > _______________________________________________ > > Xdoclet-devel mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/xdoclet-devel > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Oh, it's good to be a geek. > http://thinkgeek.com/sf > _______________________________________________ > Xdoclet-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/xdoclet-devel ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Stuff, things, and much much more. http://thinkgeek.com/sf _______________________________________________ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
