On 2002.10.17 18:10:05 -0400 Aslak Hellesøy wrote: > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:xdoclet-devel-admin@;lists.sourceforge.net]On Behalf Of David > > Jencks > > Sent: 17. oktober 2002 18:39 > > To: xdoclet-devel > > Subject: [Xdoclet-devel] How many jdo modules do we need? One per > > vendor? > > > > > > Hi, > > > > Ludovic Claude submitted some nice subtasks for doing vendor extensions > in > > the jdo module. He's written them as a separate module for each > > jdo vendor > > (currently 2, LiDO and Solarmetric/KODO) More are sure to come soon (I > > have to write one for tjdo). These vendor specific subtasks are going > to > > have about 2 files each. > > > > Do we want them as a separate module for each vendor or should they all > go > > under the jdo module? > > > > I think they should be kept as distinct modules. The new architecture (in > the xdoclet2 CVS module) will have a one-one relationship between > <subtask> > and plugin directory. (plugin is the new name for module). One per > vendor. >
OK. > > At a more fundamental level, he's implemented these based on tags like > > > > @kodo.table > > > > I think a lot of these tags will be essentially the same for all jdo > > implementations based on rdbms. I wonder if we should try to be more > > universal, like > > > > @jdo table="blah" > > > > or even > > > > @jdo persistence-location="blah" > > > > Any comments? > > > > I do :-) > > I participated in some email discussions a few days ago with the people > on > cc here about representing "database metadata" as tags. I wrote some > words > about this in my blog: http://roller.anthonyeden.com/page/rinkrank/. > Scroll > down to "Synergy!!" and read the last part of that post. > > My point is that I think we should settle on something even more generic > than @jdo and @ejb, because the information we put in these tags is the > same. IMO it should be @sql, @jdbc or @rdbms. > > Further, I think we should stick to namespaces (dotted tag names) for the > sake of consistency. Who knows, they might have a programmatic sense one > day, and it would be a shame if we invented lots of "namespace-less" > tags. > My suggestion is therefore: > > Instead of > @ejb.persistence table-name="blah" > @jdo table="blah" > > We could go for > @sql.table name="blah" > > Then who knows, maybe you can write a simple java bean, and let XDoclet > decide whether it should turn it into a JDO, EJB or some other > persistent-aware class. > > This is kind of the way I think when I do OO programming. Anything > generic > that can be used in different scenarios deserves its own class. It should > be > the same way for @tags, and I think this is a perfect example for that. > > We already have a (albeit dirty) mechanism for supporting BWC on the tag > level, and this can be made better in xdoclet2. > > What do you think? > In principle I think this is a good idea. There are some obstacles to overcome or issues to solve: - jdo uses fields, ejb (more appropriately IMO) uses abstract methods for persistent field access. - Not everyone uses a rdbms for their persistent storage. ODBMS, ERP systems, etc should be supported. - Even for rdbms, often you want to use stored procedures or similar function-like thingies to access your data. In other words, structural metadata (column names) may not be equivalent to behavioral metadata (sp names/params). These may not be hard, but lets think about them for a minute before we implement a new set of tags. btw codeunit looks really cool, I think it is really important. thanks david jencks ------------------------------------------------------- This sf.net email is sponsored by: viaVerio will pay you up to $1,000 for every account that you consolidate with us. http://ad.doubleclick.net/clk;4749864;7604308;v? http://www.viaverio.com/consolidator/osdn.cfm _______________________________________________ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
