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