<Snip from one of my previous emails>
I still have some things in my mind that we should implement. I
postponed it always for the next release. There should be something
useable for the moment, you can then refactor it. So I always thought
"no not yet". But I guess after v1.0 it's definitely the time for that
change. I'm talking about changes to the way we work with template tag
impl methods. You already have seen those two long long SubTask and
AbstractEjbSubTask classes where we put almost 80% of impls there. This
is wrong. We'll go a jsp-taglib-like path but avoid
jsp-heavyweight-ness. Details should be discussed but generally it'll be
like this: A property file like Ant's where we'll map a namespace name
to an implementer class (<Xdoclet:forAllMethods/> will map to
xdoclet.MethodTags and its forAllMethods method), so we'll break the
functionality to different classes instead of being monolithic.
MethodTags, for instance, will derive from interface xdoclet.Tags (or
maybe AbstractTags class), a well-designed contract is defined there:
init(), setExecutionContext() (sets currentclass for example). As before
tag impl methods will be accessed by reflection, accepting the usual
string/properties param. The template source will change from XDoclet:
to XdtMethod: for example and not more. Note that MethodTags will
implement several tags: forAllMethod/methodType/methodName and so on.
PermissionTags will implement hasPermission/forAllSecurityRoles and so
on. Utility classes such as isSession(ClassDoc) will be public static,
this means you can write your TopLinkTags and TopLinkSubTask
(SubTask-derived classes will serve as a place where you put config
parameter get/set/create methods) and while toplink can be
ejb-independent but it indeed can call isSession static utility method
of SessionTags.
</Snip from one of my previous emails>
I thought more about it that I want to share with you. Templates files
should not change at all. <Xdoclet: will still exist. The property file
will look like this:
forAllMethods.impl=xdoclet.ClassTags
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"/>
And thereafter forAllToplinkLinks will be accessible in that template
file. So we should also have a tagClassDefinitions hashtable in
TagManager class.
Now the tricky part is the relationship between xdoclet.Tags-derived
classes and TemplateEngine. 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 which I think shouldn't derive from TemplateEngine because:
previously we had a one subtask-one template situation. But in Tags case
we have n xdoclet.Tags-one template-one subtask. SubTask only is where
Ant settable config params are set. So to keep track of
currentMethod/currrentClass and things like that TemplateEngine should
be a single instance shared by all Tags. So I think we should make it
singleton and instead of doing getCurrentClass() as before in SubTask,
do a TemplateEngine.getInstance().getCurrentClass() (we can indeed make
it easier by defining a getCurrentClass() in xdoclet.Tags that delegates
to TemplateEngine's single instance, this will also make refactoring
easier).
Any ideas? I want to make sure I haven't missed anything critical before
investing time on it. To me it seems smoother than I've thought.
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
