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]
