I agree especially with "@ejb:persistence" over "db:*". Hopefully soon we will have cmp to non-relational resource adapters/EIS
Maybe the multi-tag approach would keep templates reasonably simple while avoiding too many tag handler classes?? david jencks On 2002.03.05 14:39:47 -0500 Marcus Brito wrote: > > 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 > _______________________________________________ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
