> > So we will map <XDoclet:forAllMethods> to xdoclet.ClassTags and
lookup
> > the method there. We may also define something like Ant's taskdef:
> > <XDoclet:tagDef tagName="forAllToplinkLinks"
> > impl="mydoclet.ToplinkTags"/>
>
> I'm not really convinced... what about a situation where we have
> forAllPersistentFields, might be relevant to castor, ejb, toplink,
> etc... probably not a perfect example, but hopefully enough to clarify
my
> query.... I like your initial idea of declaring different namespaces.
What do you mean? You want an overriding feature? Or a way to tell it
that this forAllPersistentFields is for castor, not for ejb? So your
concern is the flat namespace? We already have such a case: id tag,
which is defined in AbstractejbSubTask and overridden by
DataObject/PKSubTask. So you are right. We'll convert it to: <XdtPK:id/>
and <XdtDataObject:id/>. Xdt -> XDoclet Tags. Parser will search for
<Xdt. For the phase one impl we'll simply not implement it, for second
phase we'll convert all tags from XDoclet to the respective XdtBlabla.
Remember we should refactor it step by step.
> > We currently put all tag impls in
> > SubTask-derived classes which is itself derived from TemplateEngine
and
> > use methods of it (getCurrentMethod(), generate(), etc). We'll have
> > xdoclet.Tags
> This is an abstract class/interface that tag providers implement?
An abstract class.
Ara.
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
_______________________________________________
Xdoclet-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
