[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
Thanks for the feedback,
On 2-Jan-06, Michael Kay" <mike@xxxxxxxxxxxx> wrote:
Thanks Michael - going to 2.0 is in the works...
On 3-Jan-06, James Fuller <jim.fuller@xxxxxxxxxxxxxx> wrote:
Currently 1.0, and looking at how much work vs. benefit in moving to 2.0 processing.
The XSL library is part of a CMS product, and the main audience are the CMS implementation developers.
Something light-weight would be preferable, to help speed up the implementation process.
hmmm... I haven't set up any test harnesses (beyond my own duct-tape versions); any thoughts / resources on testing strategies suited to XSL (versus other programming/dev environments)?
TIA,
Chris
:::
Re: [xsl] best practices for managing xsl library
Subject: Re: [xsl] best practices for managing xsl library From: Chris Johnson <cs.johnson@xxxxxxx> Date: Wed, 04 Jan 2006 23:45:48 -0800 |
Thanks for the feedback,
On 2-Jan-06, Michael Kay" <mike@xxxxxxxxxxxx> wrote:
Much better than naming conventions, in 2.0 you can declare the type of the
parameter. This should be a mandatory coding standard: it's really useful
documentation, and it also catches a great number of silly coding mistakes.
Thanks Michael - going to 2.0 is in the works...
On 3-Jan-06, James Fuller <jim.fuller@xxxxxxxxxxxxxx> wrote:
btw which version of XSLT > XSLT 1.0 or 2.0 ?
Currently 1.0, and looking at how much work vs. benefit in moving to 2.0 processing.
Do you intend the library to be consumed or contributed too by public users, if so striking the balance between the ease of 'submission' versus completeness (re doc, tests, etc) can be quite tricky.
The XSL library is part of a CMS product, and the main audience are the CMS implementation developers.
Do you intend to auto generate documentation from the library? If so you
may find embedding doc type elements directly inside xslt to be more
useful then have a seperate meta data document.
Something light-weight would be preferable, to help speed up the implementation process.
Also I would first setup various testing harnesses so you are able to
automate test running (be it xslt style unit tests, or simple transforms
with input and expected output); it is important to be able to run tests
against all major processors, I use Ant for this....you may find that
this influences how you design your distro.
hmmm... I haven't set up any test harnesses (beyond my own duct-tape versions); any thoughts / resources on testing strategies suited to XSL (versus other programming/dev environments)?
TIA,
Chris
:::
Chris Johnson cs.johnson@xxxxxxx
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] best practices for managi, James Fuller | Thread | Re: [xsl] best practices for managi, Dimitre Novatchev |
[xsl] How can you turn off xslt res, Cohen, Noah | Date | RE: [xsl] How can you turn off xslt, Joe Fawcett |
Month |