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

Reply via email to