xsl-list
[Top] [All Lists]

Re: [xsl] XSL Project Shut Down

2007-06-29 08:33:35
Andrew, I think there are 2 major hang ups for my company with regards
to XSLT:  1)  it is not a design, drag and drop solution 2) there are
no 3rd party controls to purchase, which really means that we are in
"build" not "buy" position.  The echoed comment "XSLT is hard to
maintain" really goes unwarranted, since those commenting really do
not understand the language and therefore have not made a fair
assessment.  Now, in saying that, I have managed to create my own
nightmares:  raw text to the output, template rules which I didn't
realize were overriden and my changes to the child template do
nothing, and have witnessed the shear pain of finding a template rule
in sub XSLT documents.  My development in this language isn't perfect
but is improving, for example, I now create a catch-all template rule,
when I get started, and for each mode of template, in this catch-all,
I output all of the relevant details of the unhandled match.  This has
been a helpful technique for me.

How much more granularity can you ask for? You get the  ability to create html
from small , finite "functions" that are responsible for only doing 1 thing.
Its infinitely more re-useable than doing the same thing with a traditional
language   (unless your  using lisp as your templating language =)

Andrew, I love this comment and I also share the same excitement for
the language.  For me, once I have an XML doc on the left screen, and
a blank XSLT doc on the right, I think to myself, the skies the limit
here...

Karl..

On 6/28/07, Andrew Mason <andrew(_at_)katalyst(_dot_)com(_dot_)au> wrote:
On Friday June 29 2007 07:30:12 am Karl Stubsjoen wrote:
> My XSL project just got shut down.  Why?  Because it goes against our
> companies standard: .NET 2.0 .ASPX + 3rd party components (drag and
> drop controls).  Why else?  Because XSL is hard to maintain, and I'm
> really the only one here who knows it very well.  I am, of course
> echoing the reasons given to me.

I am at a loss to see why you or  others feel that XSL is hard to maintain?

If anything I find that the functional nature makes it significantly easier
than trying to maintain JSP/ASP/php/ruby riddled html templates. About the
only annoying thing is the lack of good xml diffing tools when you get a
conflict in <insert your source  control management system here>

How much more granularity can you ask for? You get the  ability to create html
from small , finite "functions" that are responsible for only doing 1 thing.
Its infinitely more re-useable than doing the same thing with a traditional
language   (unless your  using lisp as your templating language =)

I suspect the real reason is simply because "they"  can't be bothered thinking
and their current  solution means they don't have to think as they already
know it. XSL has it's problems. IMHO the former is not one of them and the
latter is the hardest to overcome.

Andrew M

>
> It is a sad day.
>
> Karl S.
>
> --~------------------------------------------------------------------
> XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
> To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
> or e-mail: 
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
> --~--


--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--



--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--

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