[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Legibility, repetition, nesting
Hi David, Why is it necessary at all to use <xsl:choose> ? On Mon, Jul 20, 2020 at 10:03 AM David Birnbaum djbpitt@xxxxxxxxx < xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote: > Dear XSL-list, > > I write here for advice about Best Practice. The question is at the end; > because I am constitutionally unable to be concise, the long narrative > before it is context. > > I'm developing an XSLT stylesheet that processes 134 different types of > items (same generic identifier, distinguished by an attribute value). For > each item, regardless of type, I create several variables, do an > <xsl:copy>, and inside that first create some other content that is common > to all items, regardless of type, and then use <xsl:choose> to handle the > types differently, according to their idiosyncrasies. I began by > implementing this as a single template with a long <xsl:choose> deeply > nested inside it, which has the advantage of avoiding unnecessary > repetition, since the shared operations are outside the <xsl:choose>. It > works, but perfectionism is a terrible curse ... > > Perhaps I'm being arbitrarily fastidious, but the <xsl:choose> inside the > deep nesting feels awkward; I wind up with one template that runs to more > than a thousand lines, where the <xsl:choose> is seven levels deep. This > made me wonder whether off-loading the type-specific tasks to separate > templates or functions, which could be called from the appropriate place, > would keep the main template down to a more manageable size. Specifically, > I'd like to be able to put the code blocks currently inside of the > <xsl:when> statements somewhere other than deep inside a single main > template. > > One implementation of this approach that works, but comes with its own > issues, is using an <xsl:next-match> with auxiliary lower-priority > templates that match item[@type eq 'x']. This lets me break out the > type-specific code into separate templates. The reason this is not wholly > satisfactory is that I have to pass all of the variables into these > separate templates as parameters, so I wind up repeating the same > <xsl:param> statements inside each of the secondary templates. That much > repetition feels suboptimal. > > The only approach that occurs to me that might simultaneously eliminate > repetition and avoid putting all of the processing inside a single > thousand-line template, most of which is the <xsl:choose> with all of the > type-specific handling inside <xsl:when> children, is to put the > type-specific processing into separate files, with an <xsl:when> root, and > then <xsl:include> them inside the <xsl:choose>. One downside seems to be > that they will not be valid XSLT (they wonbt have the necessary wrapper > boilerplate and the variables they use wonbt be defined inside them), which > I think I could overcome by using an <oXygen/> "master document", which > would cause them to be validated in context. That isn't ideal, since it's > tied to a specific development environment, but since that happens to be my > usual development environment, the objection is philosophical (= can be > ignored in the interest of Getting The Job Done), rather than practical. > > So: Is there a Best Practice approach to breaking out the type-specific > treatment of the different types of items that avoids both 1) unnecessary > repetition and 2) embedding a single thousand-line <xsl:choose>, which > contains all of the type-specific operations, seven levels deep inside a > template? > > Thanks, > > David > > XSL-List info and archive <http://www.mulberrytech.com/xsl/xsl-list> > EasyUnsubscribe <http://lists.mulberrytech.com/unsub/xsl-list/782854> (by > email <>) > -- Cheers, Dimitre Novatchev --------------------------------------- Truly great madness cannot be achieved without significant intelligence. --------------------------------------- To invent, you need a good imagination and a pile of junk ------------------------------------- Never fight an inanimate object ------------------------------------- To avoid situations in which you might make mistakes may be the biggest mistake of all ------------------------------------ Quality means doing it right when no one is looking. ------------------------------------- You've achieved success in your field when you don't know whether what you're doing is work or play ------------------------------------- To achieve the impossible dream, try going to sleep. ------------------------------------- Facts do not cease to exist because they are ignored. ------------------------------------- Typing monkeys will write all Shakespeare's works in 200yrs.Will they write all patents, too? :) ------------------------------------- Sanity is madness put to good use. ------------------------------------- I finally figured out the only reason to be alive is to enjoy it.
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|