On Mon, Sep 05, 2011 at 07:46:55PM +0100, Andrew Welch scripsit:
On 5 September 2011 19:19, Graydon <graydon(_at_)marost(_dot_)ca> wrote:
On Fri, Sep 02, 2011 at 04:49:36PM +0100, Andrew Welch scripsit:
Thanks for your post, just to query one part:
And having multiple smaller files helps collaboration
Why do you think mutiple smaller files helps collaboration?
Because that way you have have one small file locked by programmer A in
the version control system and another small file locked by programmer B
in the version control system.
Which version control do you use.. is it SourceSafe? :) No vcs
locks files any more...
TFS -- Team Foundation Server. Not my first choice; not my *last*
choice, if I got a choice. But I don't, I have to work with the
client's existing infrastructure. So TFS it is.
XSLT is not all that good at being used in large, multi-programmer
projects;
That's just not true, there's nothing different or special about xslt
than any other language used in a large project.
Many other languages have more support for the idea. (Since there are
(apparently) very few really big, 10+ programmer, XSLT projects, this is
not surprising.)
XSLT, for instance, doesn't have an equivalent of header files, or a
notion of "partial build".
there's little-to-no automerge support for version control,
Again not true... what makes you say that?
The gibbering horrors you get when a version control system with really
very good line-based code merge algorithms tries to do line-based merge
on XSLT, where you really do want a node-based merge.
and various processors throw warnings at you if you have a file included
in more than one place (as you want to do if you're defining a bunch of
utility functions in a big mass of XSLT code.)
Can you post an example?
I should have said "import".
So I have, say, "globalVars.xsl" -- a list of where to find external
resources -- and "basic.xsl" -- named templates that do things like emit
the path of the source element for error reporting -- and
utilityFunctions.xsl -- which is just what it sounds like, common
standard functions that do things like check internal links for
correctness, create number labels following depth-based rules, and so
on.
basic.xsl depends on globalVars.xsl and utilityFunctions.xsl depends on
basic.xsl.
Then I have, say, convertGenerally.xsl, the main, point-of-entry
transform, and it includes my organized-for-convenience actual
path-match transforms; call these files inline.xsl and block.xsl and
container.xsl, all of which make use of variables, named templates, or
functions defined "upstream" in globalVars.xsl, basic.xsl, and
utilityFunctions.xsl.
So for convertGenerally.xsl to be valid, it must include
utilityFunctions.xsl, so I get a pattern rather like:
<xsl:include href="utilityFunctions.xsl"/>
<xsl:include href="inline.xsl"/>
<xsl:include href="block.xsl"/>
<xsl:include href="container.xsl"/>
The problem is that I want to be able to individually validate
inline.xsl, block.xsl, and container.xsl, too.
So, I say, I have this nice linear sequence of includes -- globalVars ->
basic -> utilityFunctions ->convertGenerally -- so I should be able to
have each of the actual path-match transform files *import* that linear
sequence so the individual files can be valid and I don't mess up the
behaviour of the overall transform in some subtle (and thus unfindable)
way. So inline.xsl, block.xsl, and container.xsl should all start with
<xsl:import href="utilityFunctions.xsl"/>
And this works, but every single (you understand that this is a much
simplified example; the real case gives me many warnings) such import
produces a "imported or included more than once" warning. Which both
hides things I would care about in the warning list, and makes the "was
there anything in the log file?" check for "that transform worked" less
useful in a batch-processing context.
So I suspect that there's a better way to do this. What that way might
be I have yet to discover, though.
-- Graydon
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--