Note that all of xdoclet is a synonym.
The reason xdoclet is popular is *not* that it does something that was impossible before. There is already a perfectly complete way of writing EJBs without it. However, that way is cumbersome, error-prone, and impedes understanding. Xdoclet is a facade over the unwieldy EJB spec, a synonym which solves a real problem. Using xdoclet, I've found that it's much, much easier to manage and understand EJB code -- but one remaining constant point of confusion is the transaction terminology. So, in the spirit of the whole project, I propose a facade over something unwieldy and error-prone, a synonym which solves a real problem. Note also that I didn't pull that translation table out of thin air. It is a direct transcription of the description the EJB spec itself gives for the transaction types (page 360 in the rev of the spec I have here). So this synonym isn't even that far-fetched. Is xdoclet a tool for managing and understanding complexity, or merely for saving keystrokes? > -1 > Same reasons. > > Ara Abrahamian wrote: >> -1, but I don't veto. If ppl are happy with it then I'm happy >> as far as >> it's compatible with classic ejb:transaction stuff. >> I prefer the familiar/standard terms. It seems to be just a >> synonym. So >> many ways to do the same thing is bad. >> Ara. >>> -----Original Message----- >>> From: [EMAIL PROTECTED] [mailto:xdoclet-user- >>> [EMAIL PROTECTED]] On Behalf Of Aslak Helles�y >>> Sent: Friday, June 14, 2002 9:14 AM >>> To: Paul Cantrell; [EMAIL PROTECTED] >>> Subject: RE: [Xdoclet-user] A clarifying extension for >>> ejb:transaction >>> >>> Hi Paul, >>> >>> If it's really backwards compatible, I like it. Upload it to patches >> (make >>> sure it's patched against latest CVS). If we accept it we'll >>> apply it. >> If >>> not, we'll throw it away. >>> >>> +1 >>> >>> Aslak >>> >>> >>>> -----Original Message----- >>>> From: [EMAIL PROTECTED] >>>> [mailto:[EMAIL PROTECTED]]On Behalf Of Paul >>>> Cantrell >>>> Sent: 14. juni 2002 00:06 >>>> To: [EMAIL PROTECTED] >>>> Subject: [Xdoclet-user] A clarifying extension for ejb:transaction >>>> >>>> >>>> I made a mod to the ejb:transaction tag that I thought others >>>> might be interested in, so I'm describing it here for discussion. >>>> >>>> I've always been really bothered by the EJB terminology for >>>> transaction types. Quick, what's the difference between >>>> "Required" and "Mandatory"? "NotSupported" and "Never"? OK, I >>>> know the answers, and so do you, probably -- but being used to >>>> it doesn't make the terminology any less horrid. And bad >>>> terminology can really thwart the high-level discussion and >>>> analysis the EJBs are supposed to make easier. >>>> >>>> So, I added support for a clearer alternative. With the patch, >>>> instead of this: >>>> >>>> @ejb:transaction >>>> type="Supports" >>>> >>>> ...you can specify the rules in a much more comprehensible way, >>>> specifying the action to take depending on whether a transaction >>>> is present or absent in the current context: >>>> >>>> @ejb:transaction >>>> present="use" >>>> absent="ignore" >>>> >>>> It's backward-compatible -- either way works -- you can specify >>>> either "type" or the "present" / "absent" pair (but not both) in >>>> your ejb:transaction tag. The allowable values for the "present" >>>> attribute are: ignore, use, create, and error; "absent" is the >>>> same, except it doesn't allow "use" because it wouldn't have any >>>> meaning. >>>> >>>> The modified tag handler will translate the present/absent pair >>>> into the appropriate EJB transaction type, or give an error if >>>> you choose a combination not allowed by the spec. The full >>>> translation table is as follows: >>>> >>>> absent / present => type >>>> ---------------------------------- >>>> ignore / ignore => NotSupported >>>> ignore / use => Supports >>>> create / use => Required >>>> create / create => RequiresNew >>>> error / use => Mandatory >>>> ignore / error => Never >>>> >>>> Now I think this is cool, and am pleased with its effect on my >>>> code's readability. Questions: Is this a patch others would >>>> like? Do people have suggestions for improvement? Might we >>>> consider adding this as a standard feature of ejbdoclet? >>>> >>>> If there is interest on this list, I'll send my code out. >>>> >>>> Cheers, >>>> >>>> Paul >>>> >>>> >>>> _______________________________________________________________ >>>> >>>> Don't miss the 2002 Sprint PCS Application Developer's Conference >>>> August 25-28 in Las Vegas - >>> >>> http://devcon.sprintpcs.com/adp/index.cfm?source=dntextlink >>> >>> _______________________________________________ >>> Xdoclet-user mailing list >>> [EMAIL PROTECTED] >>> https://lists.sourceforge.net/lists/listinfo/xdoclet-user >>> >>> >>> _______________________________________________________________ >>> >>> Don't miss the 2002 Sprint PCS Application Developer's Conference >>> August 25-28 in Las Vegas - >>> http://devcon.sprintpcs.com/adp/index.cfm?source=dntextlink >>> >>> _______________________________________________ >>> Xdoclet-user mailing list >>> [EMAIL PROTECTED] >>> https://lists.sourceforge.net/lists/listinfo/xdoclet-user >> _______________________________________________________________ >> Don't miss the 2002 Sprint PCS Application Developer's Conference >> August 25-28 in Las Vegas - >> http://devcon.sprintpcs.com/adp/index.cfm?source >> _______________________________________________ >> Xdoclet-user mailing list >> [EMAIL PROTECTED] >> https://lists.sourceforge.net/lists/listinfo/xdoclet-user > > > > > _______________________________________________________________ > > Sponsored by: > ThinkGeek at http://www.ThinkGeek.com/ > _______________________________________________ > Xdoclet-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/xdoclet-user > _______________________________________________________________ Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ _______________________________________________ Xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user
