[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
Hi Ganesh,
At 01:27 PM 10/27/2003, you wrote:
I'm not sure why that has to follow.
Your earlier mail posed the problem of retrieving the correct label for a node based on its field and fieldGroup, so that's what I looked at.
Keys are a useful mechanism for retrieving nodes based on pre-determined criteria (such as the values of associated nodes); how they would apply to control styling or rendering is rather an open question, in this case. Nevertheless I see no reason why the same lookup mechanism couldn't be used to handle, say, CSS styling attribute values. (Whether that would work in your case is a different question.)
Most likely. :->
Since this document has already been, or must be, processed to retrieve information from it, the changing of the context node by itself does not add significant overhead. And because of the way keys work, your context node has to be in the document where you apply the key: hence the for-each.
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Re: [xsl] Keys with different parents, but same name
Subject: Re: [xsl] Keys with different parents, but same name From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx> Date: Mon, 27 Oct 2003 14:48:24 -0500 |
Hi Ganesh,
At 01:27 PM 10/27/2003, you wrote:
Thanks for pointing me in right direction. This indeed worked. But did not solved the problem :-(. The reason for using different keys is there could be different types of groups and styling/rendering would change accordingly.
I'm not sure why that has to follow.
Your earlier mail posed the problem of retrieving the correct label for a node based on its field and fieldGroup, so that's what I looked at.
Keys are a useful mechanism for retrieving nodes based on pre-determined criteria (such as the values of associated nodes); how they would apply to control styling or rendering is rather an open question, in this case. Nevertheless I see no reason why the same lookup mechanism couldn't be used to handle, say, CSS styling attribute values. (Whether that would work in your case is a different question.)
For brevity, i had mentioned only field and fieldGroup. May be to resolve this I think will have to look into design stuff.
Most likely. :->
And another doubt is regarding the way of changing the context node to fieldHeaders document, if we use <xsl:for-each ...> wont this reduce the performance? I might be wrong here. <xsl:variable name="keyvalue" select="concat(@id,'-')"/> <xsl:for-each select="$fieldHeaders"> <xsl:value-of select="key('label-by-field', $keyvalue)"/> </xsl:for-each>
Since this document has already been, or must be, processed to retrieve information from it, the changing of the context node by itself does not add significant overhead. And because of the way keys work, your context node has to be in the document where you apply the key: hence the for-each.
Cheers, Wendell
====================================================================== Wendell Piez mailto:wapiez@xxxxxxxxxxxxxxxx Mulberry Technologies, Inc. http://www.mulberrytech.com 17 West Jefferson Street Direct Phone: 301/315-9635 Suite 207 Phone: 301/315-9631 Rockville, MD 20850 Fax: 301/315-8285 ---------------------------------------------------------------------- Mulberry Technologies: A Consultancy Specializing in SGML and XML ======================================================================
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Keys with different paren, Ganesh Sindigi | Thread | [xsl] XPathEvaluator.evaluate probl, meka v.krishna prasa |
Re: [xsl] Placing selective links i, J.Pietschmann | Date | [xsl] Re: Re: dynamic html table ge, Dimitre Novatchev |
Month |
Keywords