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