Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@ws.apache.org
Message-ID: <22828209.1182394345952.JavaMail.jira@brutus>
Date: Wed, 20 Jun 2007 19:52:25 -0700 (PDT)
From: "Peter Danielsen (JIRA)" <jira@apache.org>
To: axis-dev@ws.apache.org
Subject: [jira] Commented: (AXIS2-2749) Improved codegen XSLTIncludeResolver
 support for <xsl:include>
In-Reply-To: <30603512.1180665375585.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/AXIS2-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506745 ] 

Peter Danielsen commented on AXIS2-2749:
----------------------------------------

Amila,

I don't want to change how the databindsupporter works, but I would like to also be able to use <xsl:include> in the traditional way where the href just refers directly to a location that can be found with getResourceAsStream.  This issue is about making it easier to reuse code among template files.  

In the development of my templates, there were several places where I needed to do the same thing.  An example is generating a method signature.  It should be the same in the interface and in the implementation.  I could have copied and pasted that code.  Or, I could have created a named template and called it from each place, but I needed to use it in different template files.  To do that would have required me to copy the named template into each file, which would be time-consuming to fix if a bug was discovered. I'd rather just put that common template in a one file that could be included by the other files.  If a bug is found with that code, I only need to update one place.

In my case, I put the common template in a new file at     
  com/foo/axis2/wsdl/template/java/InterfaceMethodSignature.xsl

Without the patch, I'd have to write some Java code to modify the CodeGenConfiguration object to create a property and set its value as the path to the file, and then modify each template to add an <xsl:include> whose href attribute is that property name.

With the patch, I can just include that file with
  <xsl:include href="/com/foo/axis2/wsdl/template/java/InterfaceMethodSignature.xsl" /> 
and not have to write any Java code.

Regarding your question about affecting existing template processing system, I don't believe it will break it.  The only issue would be if a template is modified and an href is given an incorrect value.  When that occurs a TransformerException is thrown with the message id "resolver.templateNotFound". I saw that message appear in the console output in my test runs.  In the patch, I have a "TODO" in the "catch" of that exception because I didn't think there was anything further to do given that the message appeared in the console output.  What do you think should be done?

Once this patch is in place, there's an opportunity to take advantage of this feature to reduce the size of the existing templates by factoring out duplicate code to common files that they could include.


Peter


> Improved codegen XSLTIncludeResolver support for <xsl:include>
> --------------------------------------------------------------
>
>                 Key: AXIS2-2749
>                 URL: https://issues.apache.org/jira/browse/AXIS2-2749
>             Project: Axis 2.0 (Axis2)
>          Issue Type: Improvement
>          Components: codegen
>            Reporter: Peter Danielsen
>            Assignee: Amila Chinthaka Suriarachchi
>         Attachments: XSLTIncludeResolver.java.svn.diff, XSLTIncludeResolver.patch.txt, XSLTIncludeResolverTest.java, XSLTIncludeResolverTestTemplate.xsl
>
>
> I've been trying to create my own Axis2 codegen XSLT templates and would like to factor out some common templates to a separate file that can be included by others.  An example is a template that generates a method signature.  It would be included in a template that generates an interface and in one that generates an implementation class.
> The current URI resolver used by the AxisServiceBasedMultiLanguageEmitter, XSLTIncludeResolver, requires the value of an <xsl:include>'s href attribute to be a property that's in its CodeGenConfiguration object. It looks like the only way to set the property is to write code. It would be preferable refer to it directly in a template by setting the href to a value that can be resolved by XSLTIncludeResolver using getResourceAsStream.  Such a change to XSLTIncludeResolver will enable easier maintenance of the existing templates, once refactored, and easier development of new templates since there won't be multiple copies of the same code to update when something changes.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org