Ok, a little more thought, here's my thought for the
"XDocletContext" interface that would be provided to
"XDocletTagSupport" classes (how are those interface names?)
getCurrentMethod()
getCurrentClass()
getCurrentPackage()
pushCurrentClass(Class clazz)
popCurrentClass()
pushCurrentMethod(Method method)
popCurrentMethod()
generate(String template)
I've had a quick look through SubTask and AbstractEjbTask and think that's
pretty much what we need. The XDocletTagSupport interface (which support
classes must implement) has:
setContext(XDocletContext ctx)
how does that all sound?
cheers
dim
On Thu, 11 Oct 2001, Dmitri Colebatch wrote:
> anyone see this!!! geez guys... top work - 45th overall on
> sourceforge... I know its not really the benchmark to use, but its very
> nice (o:
>
> on a different note, I've been thinking of the namespace issue and would
> like to have a go at it this weekend. Ara - that ok with you? Here's
> what I suggest.
>
> A config file that maps "namespaces" to classes. eg:
>
> ejb=xdoclet.ejb.EntityEJBSupport
>
> which results in the tag
>
> <XDoclet:ejb:forAllPersistentFields>
>
> being mapped to the class xdoclet.ejb.EntityEJBSupport. If an instance of
> the class hasn't yet been loaded, an instance is created using the default
> constructor. The Support classes must implement an interface that has a
> setContext() method, which the context is set (to provide access to the
> doc tree). TemplateDoclet will be changed slightly to support this, but
> there'll be a lot of changes required in the SubTask subclasses to
> separate them.
>
> how's this sound? what you were thinking Ara?
>
> cheers
> dim
>
>
> _______________________________________________
> Xdoclet-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
>
_______________________________________________
Xdoclet-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
