Hi,
So you have something like @bluestone:ejb-ref-map
flag="co-located|distributed" blabla... for each ejb:ejb-ref? If so then
I think you should change it and add bluestone-blabla parameters to
ejb:ejb-ref instead, because there can be multiple ejb:ejb-ref tags in a
class header and if you want to relate a @bluestone:ejb-ref-map to a
ejb:ejb-ref user has to put bluestone:ejb-ref-map after ejb:ejb-ref and
there's no template tag for this case and it's maybe a bit confusing for
user too. For orion's query string I added a orion-query parameter to
ejb:finder instead of creating a orion-finder and documented it that
way.
So if you consolidate the two you have one @tags and it's easy to loop
with just forAllClassTags; otherwise you have to write an iterator tag,
based on the assumption (which is a correct assumption AFAIK in Sun's
Doclet API) that the list of class tags are passed in the same order
that user put, and relate the two to each other.
Now regarding:
> Or is it going to need custom tags to loop
> through the locations, and loop through the references for the current
> location?
What's this location thing? A tag? Or?
For all locations
For all ejb-refs of that location
Blabla
Do something like this:
For all locations
/put the location name in match variable (I don't remember the
exact tag name, but it ends with "Match")
<setclassTagValueMatch tagName="location" paramName="name"/>
For all ejb-refs
ifClassTagValueEquals tagName="@bluestone:ejb-ref-map"
paramName="location" value="<getclassTagValueMatch/>"
//current tag is ejb-ref for current location
But anyway I really think you should write a custom tag instead of
polluting the template with logic, just a simple forAllLocations and a
forAllEjbRefsForLocation and use an internal struct to hold current
location and ejb-ref. The limitation imho is a good thing actually, you
have to write clean templates this way :o)
PS: Seems like HP Bluestone has one of those nasty deployment
descriptors! Don't try to make everything a @tag, many things are
deployment-oriented, so provide merge-points, but create @tags for
development-oriented ones.
Ara.
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:xdoclet-devel-
> [EMAIL PROTECTED]] On Behalf Of Andrew Stevens
> Sent: Friday, January 11, 2002 12:58 AM
> To: [EMAIL PROTECTED]
> Subject: [Xdoclet-devel] Another template tag question
>
> The Bluestone template is starting to take shape, however, I have
another
> puzzle...
>
> Its ejb-refs can be flagged as "co-located" (same app) or
"distributed"; I
> assume that's so it can use local calls for performance. The
co-located
> ones only include the ejb-ref & JNDI name, the distributed ones also
have
> the app name, name server hostname & name server port. However, so
far as
> I can tell from the schema, it's expecting them to be grouped by
> app+hostname+port i.e. an optional <co-located> section, then zero or
more
> <distributed application-name="..." name-server-host="..."
> name-server-port="..."> sections, with each section containing all the
> applicable <ejb-ref-map advertised-name="..." ejb-ref-name="..."/>
> entries. Assuming I just want to put a bunch of
@bluestone:ejb-ref-map
> tags in the class, is there any (simple) way to do the grouping with
the
> existing template tags? Or is it going to need custom tags to loop
> through the locations, and loop through the references for the current
> location?
>
>
> Andrew.
>
> _______________________________________________
> Xdoclet-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
_______________________________________________
Xdoclet-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
