I like to make these assumptions:

- we're only targeting relational databases so don't use super-abstract
names such as schema or attribute. Certainly we can't target oodbs or
xmldbs, is jdbc:FooDS a good datasource name for a oodb for example?!
Or, well, is this mapping mechanism meaningful really for non-rdbs!? See
Castor, it's using map-to table="", xml="", etc.
 
- strip the ejb: away! Aren't we going to support
JDO/CastorJDO/bare-metal-cocobase/etc for example? Ain't ejb-only.

- I prefer a @tag with one name for both method and class level tags.

+1 to option 4 :o) @db:persistence isn't bad either.

Ara. 

> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:xdoclet-devel-
> [EMAIL PROTECTED]] On Behalf Of Patrick Lightbody
> Sent: Wednesday, March 06, 2002 7:48 AM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: [Xdoclet-devel] Re: Proposal - ejb:persistence tags
> 
> Making new tag handlers would be nice and fun, but maybe we should
also
> make
> <XDtClass:classTagValue> still be able to support a comma seperated
list?
> Then the template author can decide what is most "fun" or whatever.
> 
> As for the official tag names, we should settle on something soon. I'm
> fine
> with all suggestions so far:
> 
> -- Option One --
> Class-level
> @ejb:persistence table-name="foo" datasource="jdbc/FooDS"
> Method-level
> @ejb:persistence-field column="bar"
> 
> -- Option Two --
> Class-level
> @ejb:persistence table-name="foo" datasource="jdbc/FooDS"
> Method-level
> @ejb:persistence column="bar"
> 
> -- Option Three --
> Class-level
> @ejb:persistence schema="foo" datasource="jdbc/FooDS"
> Method-level
> @ejb:persistence attriubte="bar"
> 
> -- Option Four --
> Class-level
> @db:mapping table-name="foo" datasource="jdbc/FooDS"
> Method-level
> @db:mapping column="bar"
> 
> Votes? Just as an FYI: the pramati templates use option two currently.
> 
> -Pat
> 
> 
> >From: Marcus Brito <[EMAIL PROTECTED]>
> >To: Lista xdoclet-devel <[EMAIL PROTECTED]>
> >Subject: [Xdoclet-devel] Re: Proposal - ejb:persistence tags
> >Date: 05 Mar 2002 16:39:47 -0300
> >
> >
> >Read on. My answer is a bit long.
> >
> >Em Ter, 2002-03-05 às 12:49, Ara Abrahamian escreveu:
> > > > Class-level:
> > > > @ejb:persistence table-name="foo" datasrouce="jdbc/FooDS"
> > > >
> > > > method-level:
> > > > @ejb:persistence-field column="bar"
> > >
> > > Looks good.
> > >
> > > Marcus Brito (?)
> >
> >That's me :)
> >
> > > What do you think about @db:mapping instead of ejb:persistence? We
can
> > > support JDO too for example. I really prefer this one.
> >
> >I really prefer @ejb:persistence instead of @db:mapping.
"persistence"
> >is a more generic word and the one used in the EJB specification.
There
> >is no need to use "database".
> >
> >However "table" and "column" are very database-centric terms anyway
--
> >perhaps we should use "schema" and "attribute". But then this may
cause
> >some confusion... well, let's see what other people have to say.
> >
> >I also prefer a single "ejb:persistence" tag instead of
> >"ejb:persistence" and "ejb:persistence-field".
> >
> > > The other question is how we're going to start implementing it and
> from
> > > where.
> >
> >This is a task for people maintaing vendor tasks and templates. They
> >should always look on these tags *in addition* to the vendor-specific
> >tags.
> >
> >For example, in JBoss (which is my playing field) templates, it
should
> >look for @ejb:persistence table-name in addition no
@jboss:table-name.
> >The template would be something like this:
> >
> ><XDtClass:ifHasClassTag tagName="jboss:table-name">
> >   <table-name><XDtClass:classTagValue tagName="jboss:table-name"
> >paramName="table-name" paramNum="0"/></table-name>
> ></XDtClassifHasClassTag>
> ><XDtClass:ifDoesntHaveClassTag tagName="jboss:table-name">
> >   <XDtClass:ifHasClassTag tagName="ejb:persistence"
> >paramName="table-name">
> >   <table-name><XDtClass:classTagValue tagName="ejb:persistence"
> >paramName="table-name"/></table-name>
> >   </XDtClass:ifHasClassTag>
> ></XDtClass:ifDoesntHaveClassTag>
> >
> >Note that using this approach enables the vendor template to use the
> >"new" standard tags while retaining backwards compatibility. The bad
> >news is that as you can see from the above example, the template
editing
> >will be a boring task.
> >
> >Another approach is to write a JBossTagHandler with methods like
> >ifHasTableName and getTableName, that would already look for the
correct
> >tags. If done this way, the above template would be like this:
> >
> ><XDtJBoss:ifHasTableName>
> >   <table-name><XDtJBoss:tableName/></table-name>
> ></XDtJBoss:ifHasTableName>
> >
> >Much nicer, huh? The <XDtJBoss:tableName/> method would look first
for
> >the @jboss:table-name tag in the current class and if not found look
for
> >@ejb:persistence table-name="" tag.
> >
> >The good news here is that coding the JBossTagHandler class is more
fun
> >then editing templates. And far more easier to debug. The bad news
is,
> >well, that it would require coding a new class, what is a more
radical
> >approach then editing templates.
> >
> >My personal position on what was questioned above: The tags should
avoid
> >database-specific terms. The two mentioned examples could be:
> >
> >@ejb:persistence schema="table"
> >@ejb:persistence attribute="column"
> >
> >And about the option between modifying templates and writing new tag
> >handlers, I prefer writing new tag handlers. It's more elegant.
> >
> >
> >--
> >Ja ne,
> >    Marcus Brito
> >    mailto: [EMAIL PROTECTED]
> >
> >Anime Gaiden - De fãs para fãs, sempre.
> >http://www.animegaiden.com.br
> ><< signature.asc >>
> 
> 
> _________________________________________________________________
> MSN Photos is the easiest way to share and print your photos:
> http://photos.msn.com/support/worldwide.aspx
> 
> 
> _______________________________________________
> 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

Reply via email to