xsl-list
[Top] [All Lists]

RE: XSLT In the Build Process?

2003-05-13 02:18:39
I've been doing this type of thing for awhile now, undoubtably my first 
attempts were modified as I gained experience ....but whenever the term ' 
framework' creeps into such code generation techniques, I found a couple of 
rules of thumb applied
 
- identifying data sinks and sources is important to identifying processing 
requirements for the build process e.g. can you control the process flow 
completely within XSLT or will the use of xsl:import / xsl:include, or some 
sort of template hiearchy, et al become too cumbersome as your 'framework' 
evolves...leading me to my cryptic Ant email. To a certain degree some of the 
new bits of functionality contained in XSLT 2.0 will undoubtably lead to 
greater ab/use of it in these types of situations....such things happen when 
there is a distinct lack of 'xml pipeline' type 
processing adoption.
 
- a good document centric definition of your data will tend to survive the 
stages of evolution your framework will process through ( messy kitchen, white 
box, black box... )..though others may argue against this point.... document 
centric data tend to stand alone and makes the architecture that grows around 
the processing of such data more forgiving.
 
- XSLT is undoubtably useful in performing these pre-compile time ( macro type 
) tasks; and I have used it at length in generating c++ code. I found that the 
greatest benefit was the stable 'specification' of the data bits that fell out 
of my logic over time..e.g. ultimately this resulted in standard bits of UML 
markup being pushed back to my model, strange because I was used to generating 
UML then coding, but I now firmly believe there exists a mystery step between 
modelling an application and writing it; we tend to write a lot of prototypes 
here, ultimately getting feedback back into your model is much easier if you 
are squeezing out xml data ( if your model is specified in xml ), and keeps 
your software model equivelent to code ! important if you are to use your model 
throughout the entire development lifecycle of software. How many of us have 
initially modelled software with all good intentions, only to update the UML at 
the very end of the project for documentation purpo
 s!
es !
 
- XSLT is powerful, but so are regular expressions in some tricky code 
generation situations...if you use something like ant as a pipeline processor, 
then this allows you to use the benefits of XSLT at arms length whilst being 
able to integrate other processes. 
 
- frameworks with XSLT are sprouting up aplenty, make sure you decide if your 
framework is a developer tool for generating code ( to be thrown away after 
code is generated, read no dependancies ) or it is part of a 
software/application framework which embodies some sort of code reuse / 
inheritance / customisation mechanism. You will find these 2 requirements will 
tend to converge, and there are some rather non-intuitive pitfalls where the 
twain meet.
 
just my 2 p.
 
cheers, Jim Fuller

ps: sorry if this is a double post....
------------------------------------------------------------
Jim Fuller
SLG Technical Manager
jim(_dot_)fuller(_at_)stuartlawrence(_dot_)com
www.stuartlawrence.com

-----Original Message-----
From: Passin, Tom [mailto:tpassin(_at_)mitretek(_dot_)org]
Sent: 12 May 2003 15:36
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
Subject: RE: [xsl] XSLT In the Build Process?


[Mitch Amiano]

However, I've found it is still difficult to get developers 
to understand the semantics - this being perhaps the most 
difficult part of transitioning and getting such a tool 
adopted by others - and moreso if the XML encodes just a 
characterization of the domain. If it attempts to be a 
programming language, it seems to be easier to get 
programmers to adopt it, but conversely less useful as a code 
factoring tool.


Right, for myself, maybe I have been doing markup and transformation too
long, but for a lot of tasks I have to do, I automatically look to see
how I can easily define things like where to insert one data chunk into
another, or how to define customization differences, or where I can
result some existing data.  Once I am clear on that, I look to see what
is the simplest xml driver file I can concoct that captures those
descriptions, then use that as input to an xslt transformation (or a
series of them).  If things are simple enough, the xslt may not even
need any driver file.

Earlier, I would have thought in terms of the steps I needed to take to
get the result.  I think that this evolution is very similar to the
progression from process-centric to data-centric view which been going
on for a decade or two.  For many (most?) business-type tasks the main
work can be seen as transforming data from one form to another.  Data
tends to be much more persistent than the procedures that created it,
and in those situations, data-centric is very valuable.

Have you seen Cleaveland's book "Program Generators with XML and Java"
(Prentice Hall PTR)?

Cheers,

Tom P

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list

This e-mail and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. If 
you are not the intended recipient please contact the sender immediately. Any 
disclosure, copying, distribution or any other use of this communication is 
strictly prohibitedand may be unlawful. Stuart Lawrence Marketing 
Communications Limited reserves the right to monitor and intercept 
communications for unlawful business purposes.

This also confirms that this message has been swept for viruses, although 
Stuart Lawrence Marketing Communications Limited accepts no responsibility for 
any loss or damage resulting directly or indirectly from the use of this email 
or contents.

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list



<Prev in Thread] Current Thread [Next in Thread>