I wonder if you are experiencing the old spaghetti code problem: you
can write good,
readable programs in assembly code and nasty, unreadable spaghetti in
(insert your
view of the perfect programming language). If this is the case, I
sympathise with you
because you have apparently inherited something awful and now have to
sort it all
out.
I suspect there is a lot of awful XSL out there (not just in your
application) because
many people cannot get their minds round the applicative style needed
for idiomatic
XSL.
It seems to me that you need to get a grip on the global structure of
the application
and you seem to have recognised that you need to throw out the
superfluous
stuff first. It is more or less axiomatic that there will be no
programs to help you with
this, or else the original developers would have used it and you
wouldn't be in
this situation. I fear this stage is just going to be classical hard
work.
Once you've done that you'll have a good view of how it should have
been done too
and can transition to a better application architecture and better
structured XSL
(i.e. refactoring).
Of course, you could just rewrite it all from scratch, which may be
more fun, but I
suspect it may cost more down the line.
I doubt whether the blame for your situation can be fairly laid at
Cocoon's door: it is -
after all - a framework that people are free to use in any way they
can. However, I
would agree that with the appropriate tools it would be easier to
construct and
maintain Cocoon applications. On this theme, see the recent threads
on the demise
of Lepido... :-(
To scale up virtually any application that was ever written, you need
good programming
standards (e.g what is where and how is it named?). I don't think XSL
is any more or
less deficient than other programming languages in this respect.
I hope you can get to see your task as an interesting challenge and
wish you success!
Steve
On 22 Jun 2006, at 12:25, Gnatz, Michael wrote:
OK, I see the problem is not unknown...
The more pages you have the harder it is. I just can't crawl all
the pages in all existing variants (logged in or not, things in
basket or not, ...).
A gui test suite would be helpful, but we dont have one at the
moment... Setting up gui tests, so that they are complete, and then
maintaining them is not easy as well...
From an academic point of view I think xslt seems to be a
misconception! In general decoupling and seperation of concerns are
good ideas, but you need to be forced to maintain the dependencies
between the decoupled parts in a way or you need a tool for
analyzing them. This analyzer seems to be hard to realize thinking
of the complexity of the template matching mechanism.
XSLT might be nice for small applications, but it does not scale
up. So in general template matching is a misconception for larger
applications, in my opinion at least...
Regards,
Michael
________________________________
Von: Ard Schrijvers [mailto:[EMAIL PROTECTED]
Gesendet: Do 22.06.2006 11:00
An: [email protected]
Betreff: RE: Is using Cocoon a good idea?
On 6/22/06, Gnatz, Michael <[EMAIL PROTECTED]> wrote:
...When I just delete a template it might be in use
anywhere in those 500 pagees and I might not recognize...
I don't know of a tool that would help find out which XSLT templates
are not used (which does not mean that such a tool does not exist).
Given that XSLTs can process any well-formed input, such a tool would
have to be dynamic, static analysis won't do unless coupled with
schemas, and in that case the whole thing would get fairly complex.
If you have a way to extensively test your application (and without
that, refactoring sounds a bit dangerous), you could try adding
<xsl:message terminate="yes"> statements to templates that you think
are not used, run the app and see if it breaks.
And then it might still run untill you happened to save the xsl
that actually imports the xsl you set to terminate because you used
caching (frequently, you have to a templates "parent template" to
get the change visible. Although we use the TraxTranformer with
check-includes set to true). So you might get into real problems if
you dont know the "flow" through your xsls.
But still, I really think this problem is a real pain in the ass. A
few weeks ago I had to give a course in Servie and Montenegro
explaining them how a site worked they where going to do the
maintainance of (www.minfin.nl).
Explaining how it worked was quite easy...we use a frame.xsl, which
imports many other xsls, using the precedence capability of xsl,
making lots of xsls re-usable. For example, a std.xsl, with very
generic matchers, transforming standard repository content into html.
Then, when they started fixing bugs, I got questions like: "I want
to change that on the frontend, can you tell me which xsl matcher
is used for that"...and all I could help them with is "try to debug
and put 'foo' in a matcher you think might be the one and look in
the frontend, ooh yeah, dont forget to save the xsls that imports
the one, although I am not sure which one that is".
But when you come to think about it, this just really really really
makes it hard to maintain stuff, certainly when you did not build
it yourself. Fixing one part of an xsl might again create a bug for
another part of the website. Is there anybody really smart/
inventive out there who has some good ideas/sollutions for it?
Though, my guess is that I really doubt if there is a solution for
it, and the more generic you your xsls, the higher price you pay
for not knowing how to refactor.
Finding unused xsls might be more easily achieved by the way: you
can see in the status generator for example which xsls are used.
So, after crawling your site, you can easily keep track of all used
xsls.
Harder it would be, to be able to track all used parts (matchers/
calls/templates) of xsls.
Sorry to be unable to really help you out...
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<winmail.dat>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
