> -----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
