Re: [TFUI] "if" in XSLT (Re: XML -> XSLT -> XHTML Nirvana)

Phlip wrote:
> The question regards the /WebXP/ book's Prime Directive. The 'if'
> statement exists because some titles are hot pink and some are not.
> 
> If you put the 'if' into the "real programming language" part of the
> GUI Layer, then you must transmit XML into the XSLT and thence into
> the XHTML, to follow the Prime Directive.

This is what I would think should happen. It seems like your XML is data 
that should be transformed into your view, without any presentation 
logic muddying it up.

> You could transmit it as a style attribute, and pass this into the
> XHTML style attribute:

...

> Or, I can put the entire title span, as preformatted XHTML, into the XML:

...

> I chose the latter, in a specific situation, for an unreviewed,
> temporary, in-house web site. I chose the simplest way to get a lot of
> flexibility. One cost is I must reformat the title itself as XHTML
> (replacing & with &, for example), before passing it into the XML.

I disagree on the flexibility. What if the XHTML 3.0 spec deprecates 
spans for magic_beans? Contrived example, I know, but if you need to 
change how your data gets displayed to the user, you now have to change 
your code. A slightly better way would be to using a class instead of a 
background-color, but even then, if you wanted to get away with spans, 
or highlight the entire row, or whatever other kind of magic, you've 
pushed that into your data creation layer, instead of being able to just 
change your XSLT.

> Without the need to target more than one XSLT, I just partitioned the
> flexibilities into the kinds of languages that make them easier.

And I think that's the key here. I'm by no means a perfect anything, and 
if I didn't have to target more than one platform using the same code, I 
probably would have done something similar. It's quick and easy and 
works - sometimes that's the important thing. While I may disagree on 
your comments about flexibility, I am only looking at a small snippet of 
code in relation to your overall system - if this is what works, then 
that's what is important.

> However, are you implying that the "real programming language" side is
> completely unaware whether the result appears on the web or in a cell
> phone? Otherwise, aren't you also partitioning your flexibilities,
> along different trade-offs?

Yes, I am implying that, at least in my case. One of our apps displays 
information to both web and mobile phones. This information spans across 
200 seperate jurisdictions, with their own rules of what information 
needs to go in, what comes out, and what needs to be returned. Since the 
entire app is primarily an information gathering and displaying app, it 
works. I'm using .NET, and have two sets of user controls - one for web 
and one for mobile. These controls implement a common interface. To get 
the data to the controls, I export things from the user controls into 
the interface.

For example, I have a UserList that displays a list of users a specific 
user can notify. On the web, this is bound through an IDictionary 
object. But on the mobile, we don't display it, because we don't support 
that option. My presentation logic and business logic stay the same, but 
my user controls can decide what capabilities to use of the client.

My first stab at this app led me down a path where I had seperate pages 
for each distinct funtion of the app, and then basically those same 
pages in a WAP form for the mobile phones. By moving all of that to a 
common set of user controls and a single class I haven't felt like I've 
lost any flexibility in what I'm doing.

I don't quite do what the WXP PD says, though. While a lot of my data 
goes through layers as XML, it ends up to the presentation logic layer 
as objects, which it can then decide what needs to be displayed or not. 
Unfortunately using XSLT to transform it wouldn't work as well for me 
because I rely on Viewstate and Cache, especially for the limited mobile 
devices. But it is a good topic.

Cory




To unsubscribe, email:
TestFirstUserInterfaces-unsubscribe-hHKSG33TihhbjbujkaE4pw@public.gmane.org
 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/TestFirstUserInterfaces/

<*> To unsubscribe from this group, send an email to:
    TestFirstUserInterfaces-unsubscribe-hHKSG33TihhbjbujkaE4pw@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/