What is pros/cons of using XSLT?

[Fred]

Not much expertise on XSLT and trying to understand it's uses when creating
apps in VS.NET?

If I wanted flexibility on the UI (View aspect of M.V.C.):
- How does it compare with creating business components that can be consumed
by WebForms, WinForms, mobile devices, etc? Is it even fair to compare the
such technologies?
- How about for cases when you need to display dynamic elements on the
form/grid (as compared to knowing data elements during design time)?

[JiangZemin]

Hi, once i got over the XSLT "hump" (basically by forcing myself to stop
reading about XSLT and starting to actually apply it), i found it to be much
nicer than expected esp. with dynamic form elements. If UI flexibility is
important in your app, then XSLT could be helpful even though/because its
not as straightfwd coding (ive never tried doing a grid-like control thru
XSLT however).

I dont think XSLT can be compared to business components except in the sense
that a business component can emit some XML which is fed to XSLT which spits
out nice HTML. So they can work together very well, ie. you could use the
same business component's XML targeted to different devices, just apply
different XSLT. And vice versa where you could reuse XSLT across different
parts of your site.

But there is definitely a learning curve and it helps tremendously if theres
someone in your team who has previous experience. You could also take baby
steps and try doing one or two sections within pages using XSLT and see how
you like it. There's nothing that says youre forced to go 100% one way or
the other.

HTH,
Premier JiangZemin

"Fred" <Fr**@discussions.microsoft.com> wrote in message
news:67**********************************@microsof t.com...

Not much expertise on XSLT and trying to understand it's uses when
creating
apps in VS.NET?

If I wanted flexibility on the UI (View aspect of M.V.C.):
- How does it compare with creating business components that can be
consumed
by WebForms, WinForms, mobile devices, etc? Is it even fair to compare the
such technologies?
- How about for cases when you need to display dynamic elements on the
form/grid (as compared to knowing data elements during design time)?

[CMM]

I dunno. XSLT seems redundant to me... at least in relation to ASP.NET and
presenting xml as html. I often find that creating actual code (C# or VB) to
read the xml file and generate the html is a lot more productive and robust.
Also much easier to read. However, xslt is nice when translating between
different schemas... but, for html translation there's no beating writing
actual code to render the xml.

"Fred" wrote:

Not much expertise on XSLT and trying to understand it's uses when creating
apps in VS.NET?

If I wanted flexibility on the UI (View aspect of M.V.C.):
- How does it compare with creating business components that can be consumed
by WebForms, WinForms, mobile devices, etc? Is it even fair to compare the
such technologies?
- How about for cases when you need to display dynamic elements on the
form/grid (as compared to knowing data elements during design time)?

[Fred]

Are these valid assumptions?

XSLT
Pros
- Flexibility on platforms
- Flexibility on dynamic form elements

Cons
- Learning curve

..NET Forms
Pros
- Ease of development

Cons
- Microsoft-specific implementation
- Need to know form/grid elements during design-time

How about if you want to target different UI i.e. browser, mobile device,
Win32, etc?
Thanks.
"CMM" wrote:

I dunno. XSLT seems redundant to me... at least in relation to ASP.NET and
presenting xml as html. I often find that creating actual code (C# or VB) to
read the xml file and generate the html is a lot more productive and robust.
Also much easier to read. However, xslt is nice when translating between
different schemas... but, for html translation there's no beating writing
actual code to render the xml.

"Fred" wrote:

Not much expertise on XSLT and trying to understand it's uses when creating
apps in VS.NET?

If I wanted flexibility on the UI (View aspect of M.V.C.):
- How does it compare with creating business components that can be consumed
by WebForms, WinForms, mobile devices, etc? Is it even fair to compare the
such technologies?
- How about for cases when you need to display dynamic elements on the
form/grid (as compared to knowing data elements during design time)?

[CMM]

I don't know what "need to know form/grid elements during design-time" means.
You can render any HTML dynamically at runtime using ASP.NET. However, if you
want to use the Webform/Event Postback model (which mimics a classic desktop
programming paradigm) then you would use "design-time" controls... which
incidentally also produce standard HTML. :-) Additionally, I don't know of
any reason why these same "design-time" controls can't be solely instantiated
at runtime and still take advantage of their event postbacks. I believe that
ASP.NET Controls model allows for this very easily via both placeholder
controls and list/grid/repeater controls.

But if you just need to *display* information... who needs 'em? Just
generate the HTML yourself using a StringBuilder object and some smart code.

Basically it boils down to this:
1) Using XSLT to transform XML into HTML is no different than reading an XML
file using a real high-level language and generating the HTML in code. In
fact, the latter is tons more flexible.
2) ASP.NET produces HTML that can be consumed by ANY browser on ANY
platform. However, of course, ASP.NET on the server-side requires IIS.
3) I am NOT saying that XSLT is useless... in fact, it serves many great
purposes and you can still use XSLT in ASP.NET. In fact, ASP.NET provides
some really nice classes to do so. It's just that sometimes plain ol' code is
the easiest route to take.


"Fred" wrote:

Are these valid assumptions?

XSLT
Pros
- Flexibility on platforms
- Flexibility on dynamic form elements

Cons
- Learning curve

.NET Forms
Pros
- Ease of development

Cons
- Microsoft-specific implementation
- Need to know form/grid elements during design-time

How about if you want to target different UI i.e. browser, mobile device,
Win32, etc?
Thanks.
"CMM" wrote:

I dunno. XSLT seems redundant to me... at least in relation to ASP.NET and
presenting xml as html. I often find that creating actual code (C# or VB) to
read the xml file and generate the html is a lot more productive and robust.
Also much easier to read. However, xslt is nice when translating between
different schemas... but, for html translation there's no beating writing
actual code to render the xml.

"Fred" wrote:

Not much expertise on XSLT and trying to understand it's uses when creating
apps in VS.NET?

If I wanted flexibility on the UI (View aspect of M.V.C.):
- How does it compare with creating business components that can be consumed
by WebForms, WinForms, mobile devices, etc? Is it even fair to compare the
such technologies?
- How about for cases when you need to display dynamic elements on the
form/grid (as compared to knowing data elements during design time)?

[JiangZemin]

Hi,
i wouldnt put "need to know form/grid elements at design time" under .NET
Form "Cons". You can work with dynamic controls from code-behind in .NET
Forms.

I agree with CMM's points that generating the HTML from .NET code is more
direct and will be easier to get up and running with quickly. But precisely
because XSLT is more indirect, there is some benefit to that too. It
really encourages you to think about presentation layer coding as a separate
exercise, which is a good thing IMO. So it can make it easier to adapt a
plug-and-play approach to targeting different device, and also if you want
to reuse the same bit of HTML in different parts of your site. But a lot
depends on how disciplined your developers are/need to be. Also, if i
recall correctly, its possible to update XSLT files directly on the server
without deploying a new build, which youd need to do if you generated the
HTML from code-behind.
I mention "if i recall correctly" because lately ive been doing all HTML
generation as CMM describes, and not using XSLT. The projects im working on
now wouldnt really benefit from XSLT, but if they did, id use it.

Thats why i suggest trying it out in a small area of your project, cause
theres no way to know if XSLT will help in this or future projects unless
you actually use it. The key, at least for me, was to stop reading
technical articles and tutorials about it.

PS. Im not sure that XSLT will help you target Win32 devices at all.

HTH,
Premier JiangZemin, MCSD.NET

"Fred" <Fr**@discussions.microsoft.com> wrote in message
news:20**********************************@microsof t.com...

Are these valid assumptions?

XSLT
Pros
- Flexibility on platforms
- Flexibility on dynamic form elements

Cons
- Learning curve

.NET Forms
Pros
- Ease of development

Cons
- Microsoft-specific implementation
- Need to know form/grid elements during design-time

How about if you want to target different UI i.e. browser, mobile device,
Win32, etc?
Thanks.
"CMM" wrote:

I dunno. XSLT seems redundant to me... at least in relation to ASP.NET
and
presenting xml as html. I often find that creating actual code (C# or VB)
to
read the xml file and generate the html is a lot more productive and
robust.
Also much easier to read. However, xslt is nice when translating between
different schemas... but, for html translation there's no beating writing
actual code to render the xml.

"Fred" wrote:

> Not much expertise on XSLT and trying to understand it's uses when
> creating
> apps in VS.NET?
>
> If I wanted flexibility on the UI (View aspect of M.V.C.):
> - How does it compare with creating business components that can be
> consumed
> by WebForms, WinForms, mobile devices, etc? Is it even fair to compare
> the
> such technologies?
> - How about for cases when you need to display dynamic elements on the
> form/grid (as compared to knowing data elements during design time)?
>