> 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:
Hey we were in 22 place a week ago with 99.65...% :-)
> 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>
No no not like that! Namespace->implclass seems bad idea to me. We
already have it I think: all generic ejb template tags are implemented
in AbstractEjbSubTask, right? You're adding a new factor to the equation
without gaining anything. Will it make the gigantic class shorter and
easier to maintain/understand? No.
I assume we have some wavelength issue here, let me tune your wavelength
my friend :-)
Ok, here it is:
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.
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
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.
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! TemplateEngine will be a singleton
class (not really a singleton with a getInstance() method, it will have
a constructor, but it's singleton for our case. 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.
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.
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 XDolcet 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.
- 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.
Hey are you still there?! :-)
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?
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
