Hello Magnus,
If you look at the "ejb.bean" tag, you can see that it is also possible to mark the parameters of a tag with a condition in xtags.xml. The genearted documentation is also very clear because the description is listed in the Applicability column.
<tag> <level>class</level> <name>ejb.bean</name> ... <parameter type="bool"> <name>reentrant</name> <usage-description> Defines the entity bean's reentrancy. </usage-description> <mandatory>false</mandatory> <default>true</default> <condition-description>Entity beans</condition-description> <condition type="type"> <condition-parameter>javax.ejb.EntityBean</condition-parameter> </condition> </parameter>
I think that the tag names in the websphere module are not consistent compared to the ejb module.
As a user of the module, i would ask the following questions:
Why does the WebSphere module not use a coarse-grained websphere.bean tag as the ejb module does?
If the module uses fine-grained tags, why is the tag for the sessions beans called websphere.bean (and not websphere.sb or so)?
How will the tag for the common attributes be named (shouldn't this be named websphere.bean)?
IMHO, we should switch to another naming as long as we do not have more tags and parameters.
I suggest to use the same approach as the ejb module uses. They have one coarse grained ejb.bean tag and use parameter-level conditions to distinguish between the bean types.
We could switch to a coarse-grained tag, mark the fine-grained tags deprecated and provide backward-compatibility for the old tags (and remove them in a future version).
Regards, Matthias
Magnus Larsson schrieb:
Hello again Matthias!
The websphere tags are actually designed to be "fine grained" by intention.
This is to avoid tags overloaded with attributes that are irrelevant.
So MDB-attributes goes to the mdb-tag, CMP-attributes to the cmp-tag and so on.
Since we can describe this in the xtags.xml - file we can make XDoclet aware of this as:
<tag> <level>class</level> <name>websphere.mdb</name> <unique>true</unique> <condition-description>Message Driven Beans</condition-description> <condition type="or"> <condition type="type"> <condition-parameter>javax.ejb.MessageDrivenBean</condition-parameter> </condition> </condition>
XDoclet uses this for example to add comments in the generated doc as: "Applies to: Message Driven Beans"
NOTE: If XDoclet uses this during execution to detect incorrect use of tags is actually out of my knowledge (easy to test however ;-)
I personally think that the generated doc makes a good work in both giving a good overview and at the same time give detailed infomation regarding the tags.
I'm currently working on some websphere-extensions (local-tran...) that are common to all three types of beans and they will therefore go into a common tag.
When it comes to "backward compatibility" we have no options.
We simply can't change tagnames since it will break existing code that uses the tags.
Regards, Magnus.
On Wednesday 22 December 2004 10:54, Matthias Germann wrote:
Hi,
I noticed that the structure of the tags in the IBM WebSphere module does not conform to the structure of the tags in the ejb module.
The ejb module definies one tag (ejb.bean) for all bean types (session, entity, message-driven). Condition tags are defined for the parameters which are not available for all bean types.
The IBM WebSphere module defines tags for each bean type (websphere.bean for session beans, websphere.mdb for message driven beans and websphere.cmp for entity beans).
IMHO this structure has two flaws: 1. there is no tag for parameters which are available for all bean types 2. it's confusing if the ejb and websphere module use different structures
I suggest to restructure the WebSphere tags and to use the same approach as for the ejb module. What do you think about this?
I'm creating a patch for some additional WebSphere parameters. Therefore, i could also restructurate the WebSphere tags.
What about backward compatibility? Should i leave the old tags or can i just remove them?
Regards, Matthias
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ xdoclet-devel mailing list https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/
_______________________________________________
xdoclet-devel mailing list
xdoclet-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
