Hi,
If the parameter type is declater using the extension's NS prefix, XSLTC can support both runtime and static parameter type identification. The primary benefit of using runtime type resolution being polymorphism can be used in passing JavaObjects to the stylesheet. Since the code for runtime type identification is more, static resolution can be implemented at first and later enhanced to support runtime resolution. The XSL would not have to be modified when the enhancements are made.
When we declare the NS for JAVA extension, we have the option of specifying class, such as xmlns:date="http://xml.apache.org/xalan/java/java.util.Date";. The parameter type can be specified by qualifying the name with the correct namespace prefix, such as <xsl:param name="date:DateObjectInst"/>. This will enable the XSLTC compiler determine the parameter type at compile time. Ofcourse the correct param name with the NS should be used when calling setParameter().
For the external java data types (when the parameter type is an object specific to the project), a NS declaraton has to be made as follows : xmlns:counter="MyCounter" extension-element-prefixes="counter". The type assiciated with this NS prefix is declared using xalan:component element ( <xalan:component prefix="counter" elements="init incr" functions="read"> <xalan:script lang="javaclass" src="xalan://MyCounter"/> </xalan:component> ). In this case too, the parameter type can be specified by qualifying the name with the correct namespace prefix, such as <xsl:param name="counter:CounterObjectInst"/>.
-Siljan Simpson
----- Original Message ----- From: Santiago Pericas-Geertsen <[EMAIL PROTECTED]> Date: Wed, 03 Sep 2003 17:34:00 -0400 To: Morris Kwan <[EMAIL PROTECTED]> Subject: Re: XSLTC Extensions
Morris Kwan wrote:
>The runtime method resolving solution also has a benefit that a parameter can
>bind to different types at runtime. If the users value ease of use and
>extensibility as more important, this might be a better solution.
>
Yes, I agree. In the case of Java types, however, different runtime types may still be allowed via subtyping/subsumption. I.e., a user may declare the type of a parameter to be a base type of the possible runtime types (the current type system may need to be tweaked for this, but it is doable I think). The only caveat is that a Java method that takes such an XSLT parameter would have to be declared using that base type for the static binding algorithm to succeed.
-- Santiago
-- __________________________________________________________ Sign-up for your own personalized E-mail at Mail.com http://www.mail.com/?sr=signup
CareerBuilder.com has over 400,000 jobs. Be smarter about your job search http://corp.mail.com/careers
