--- Aslak_Hellesoy <[EMAIL PROTECTED]> wrote: > > > > -----Original Message----- > > From: Konstantin Priblouda > [mailto:[EMAIL PROTECTED]] > > Sent: 9. juli 2002 11:22 > > To: Aslak_Hellesoy > > Subject: RE: [Xdoclet-devel] xtags DTD > > > > > > > > > > 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. > > > > I do not think that we have to modify condition > > framework a lot. Nothing prevents us to add > condition > > which tests parameters passed on xdoclet > invocation. > > > > > > > It may still get XProgramElement - there is no > > problem. > > > > I started work to move xtags into xdoclet core > > ( if there are no objections ) and add support > > for them in module loading stuff. > > ( clearly module has to provide own xtags on > demand... > > ) > > I think we should discuss this with Ara first. And > no new stuff in XDoclet > now please. We have a release coming up you know ;-)
Yes, of course. I'm just playing around with ideas how to integrate it. I plan to make GUI module-aware, with possibility to choose which modules we cover. ( no need to bomb user with all the tags he/she may never need for his application ) To achieve this, GUI has to use module loader, and module has to be able to spit out tag families it uses... regards, ===== Konstantin Priblouda ( ko5tik ) Freelance Software developer < http://www.pribluda.de > < play java games -> http://www.yook.de > < render charts online -> http://www.pribluda.de/povray/ > __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com ------------------------------------------------------- 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