On Thu, 11 Oct 2001, Ara Abrahamian wrote:
> Hey we were in 22 place a week ago with 99.65...% :-)
shyzer!
> Problem:
> we have different namespaces, each has some special template tags,
> ifEntity/forAllBeans/forAllPersistentFields/etc. We have a
> namespace->impleclass mechanism as described above. What the problem
> with it? Well, for namespaces like "ejb:" the impl class is
> ultra-crowded, hard to manage. All sort of different things are there:
> dataobjects, bean, remote/local interfaces, everything. Though for
> example we don't have a "dataobject:" namespace but it's really
> something complex and has some part that overall make a separate entity
> in our system. Remember a class should do something meaningful and
> distinct, I don't think having currentSecurityRoleName and
> dataObjectClassnames in the same class is a good idea, it's just
> something that has all sort of unrelated things in it! Right? So we
> should find a way to handle it.
yep, on the same wavelength (o:
> Cure:
> So if we don't have a dataobject or relation namespace, we should find a
> way to split functionality of a namespace into different classes. How?
> Using a settings file (it's similar to Ant approach, check Ant's
> sources), but it's different (actually I changed my mind from my last
> proposal for handling it). I propose something like this:
> A file like /tagimpls.properties for xdoclet.jar, in it you register
> yourself as a tag impl class and define the tag impl's symbolic name
> (EjbSec for ejb security tags, for example):
> EjbSec=xdoclet.ejb.EjbSecurityTags
isn't this the same though? In my suggestion, that would have been
ejbsec=xdoclet.ejb.EjbSecurityTags
and
<XDoclet:ejbsec:forAllSecurityRoles>
... ahh, I realise what I've done... I used a stupid bloody example for
the support class (o: I think semantically we are actually on the same
wavelength, but my silly suggestion ("EntityEjbSupport") confused the
issue.
> How do we use it? Well, on startup xdoclet reads this file, creates a
> Properties object and stores it somewhere. Then in template file let's
> say you have <XdtEjbSec:forAllSecurityRoles ...>, first xdoclet removes
> the leading Xdt which is only used in TemplateEngine just to find
> xdoclet tags in template, then looks up the properties object for
> "EjbSec" and finds that it's implemented in xdoclet.ejb.EjbSecurityTags,
> the rest is not different from what we already do, invokes the
> corresponding method.
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.
> How does EjbSecurityTags look like, derives from? Well, from
> XDocletTagSupport as you described in your next email. I think what
> 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!
yep. so as you suggest below, having an abstract class will be a nice way
of enforcing that (or declaring the TemplateEngine final, or both...)
> I want to make
> templateengine independent from what xdoclet does and make it a separate
> "template engine", ok?). Method like getCurrentClass() in tagsupport
> will simply delegate it to template engine where the real
> getCurrentClass() is defined. If TemplateEngine is not a classic
> singleton so we should store an instance of it somewhere, I bet the best
> place is SubTask, but how does a tagimpl gain access to it? It has a
> back pointer to subtask in which it operates, it's set whenever
> processing a template starts.
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.
> Another note: We should get rid of XdocletContext subclasses such as
> EjbDocletContext. Why? Well simply because we should be able to use
> XdtEjb tags in a webdoclet or apachesoap subtask, but they don't expect
> or understand EjbDocletContext, they may expect a WebDocletContext for
> 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:
> So what should change:
> - SubTask and its derived classes will be only a place where you define
> configuration parameters and define which template/etc you want to
> process. - TemplateEngine should have a clean contract: setTemplateFile,
> setPrintWriter, and a start() method to actually start processing. The
> out attribute we have currently in TemplateEngine will be there but we
> set it using setPrintWriter. TemplateEngine should be changed to search
> for <Xdt, meaning XDoclet Tag, and should use the tagimpls.properties
> file, it should also have a Hashtable of the namespace->tagimpleclass
> instances. Note the value of the Hastable is an instance of a tag impl
> class, acts as a cache, so we'll probably call init() method of
> TagSupport whenever templateengine's start() method is called, so it has
> a chance to reinitialize itself.
So you're saying we'll proactively load all the tag classes? I suppose
thats a bit simpler.
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!).
> - 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.
> Hey are you still there?! :-)
yepper (o:
> Anyway, we should make a copy of cvs sources and start a test project,
> and commit it when *everything* works as before. I think I also will be
> free for fri-sat-sun-mon so you and I can arrange a simultaneous work on
> it. OK?
branch time? How about I make a branch and we can both work off
that. yes - I agree there needs to be a lot of care taken here. I'll let
you know what the branch name is.
cheers
dim
_______________________________________________
Xdoclet-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
