> yep - so just a syntax difference between > <XDoclet:ejbsec:forAllSecurityRoles> and > <XtdEjbSec:forAllSecurityRoles>. Personally, I think that my suggestion > is cleaner - no offence (o: but its only a syntax thing, and I cant say > it bothers me much.
Cleaner but more verbose. Xdt +1
<1>
> > you've proposed for tagsupport class is good, but I want to stress
that
> > XDocletTagSupport will not derive from TemplateEngine, it's kind of
> > incorrect to derive from a parser!
</1>
> ahh, this is what I was suggesting by XDocletContext... shit, I've
just
> realised (looking at the next line of your email), that we already
have
> that! Anyway, that is how I was suggesting the tag support classes
> getting access to the doc tree.
Yep, a ClassesRoot root in XDocletContext.
> > example, so a classcastexception/etc. So we'll make it generic:
instead
> > of get/setEjbspec in an EjbDocletContext class we'll define a
Hastable
> > in XDocletContext, name="ejbspec", value=String("2.0") and so on.
>
> yep, fine... but can probably be done separately yes? Small
> changes... lol, well, as small as possible (o:
This one's not a big deal ;-)
> So you're saying we'll proactively load all the tag classes? I
suppose
> thats a bit simpler.
I meant an object cache, create a new one if not there, else use it. The
important thing is that tagimpls should be initialized like ejbean
instances, where when you're done with processing template 1.j you
reinit it for 2.j.
> So just to confirm I'm 'tuned' onto the right wavelength now (o: The
> various subtasks (EntityCmpSubtask etc) will still extend Subtask,
which
> will still extent TemplateEngine? But the way TemplateEngine handles
tags
> will change... the rest of it is the same? (I'm scared to write this
as
> I've just woken up and think there's a good chance I'm not thinking of
> something... but hey!).
SubTask won't derive from TemplateEngine. Why should it? Will it use
anything from template engine? No, everything is done in tagimpl
classes, the only thing it should do is to new it and call
setblabla/start() methods of template engine. It's semantically
incorrect to derive subtask to derive from template engine.
TemplateEngine is not final but not extended in own system by any class.
> > - A XDocletTagSupport abstract base class, with a set of delegator
> > methods like getCurrentClass(), a set of state setting methods like
> > setSubTask(), and a set of generic utility method for all other
> > tagimpls. It does not derive from TemplateEngine.
>
> I think I disagree with this... right, at the moment, because
everything
> is in one class, when a tag calls setCurrentClass, or
setCurrentMethod,
> etc, all other tags see it. Because we've now got a multitude of
classes,
> we need a common place that holds where we are in the tree. Thats
what I
> see XDocletContext as being. So here's my static class diagram:
>
> +----------------+
> | XDocletContext |
> +----------------+
> ^
> |
> +----------------+ 1 * +----------------------+
> | TemplateEngine |--------| AbstractTagSupport |
> +----------------+ +----------------------+
> ^ | init(XDocletContext) |
> | +----------------------+
> +----------------+
> | SubTask |
> +----------------+
> ^
> |
> +------------------+
> | EntityCmpSubTask |
> +------------------+
>
> (o: well that was fun! ummm, does that make sense? Thats how we
share
> the tree between different tag support classes.
No! We're processing template file blabla.j, so current class/method/etc
is valid only for the scope of that template file. We can place
curmethod/class/etc in TemplateEngine as is now, but what does a parser
has to do with current class in a javadoc tree? Nothing. A single
instance of Xdocletcontext is shared by all subtasks and tagimpls, so
not a good place to put a current-template-scope variable there. The
best place is subtask I think. And because tagimpls have a back pointer
to subtask there's no problem there.
Anyway find attached a class diagram of my thoughts :-)
We'll later move it to docs probably.
Btw, I strongly suggest you to use IDEA for the huge refactoring we
should do :-)
Ara.
draft1.gif
Description: Binary data
