Re: Why I use mod_perl (PR stuff)

[James G Smith <JG...@TAMU.Edu>]

modperl@att.net wrote:
>This is also what I am trying to suggest. Back to your other post 
>yesterday, I may propose that you go directly to the XHTML and use
>libXML to parse data into it. The modern browsers (the latest IE and 
>Mozilla) themselves understant XSLT tranlation and so even this parsing 
>may not be needed.

For many applications, you are correct.  However, some situations
require support of the most basic systems.

Part of the problem with XHTML is that it is a page description
language instead of a semantic markup language.  We need to be able
to support both screen displays as well as handhelds, phones, etc.,
that might not be able to use all the stuff we want in the richer
screen media.  Part of the other problem is that people writing with
XHTML will try to make the page appear as they want instead of
letting the stylesheet do it for them -- all the management in the
world can't change government workers.

The other thing I was trying to avoid was drastic changes in markup
when there hasn't been a significant change in the semantics.  Forms
come to mind for this.  XHTML form elements are too closely tied to
presentation and not closely enough to the semantics.

For example (based on our system):
  <selection id="neo">
    <caption>E-Mail forwarding for @neo:</caption>
    <option id="bounce"><caption>Return to sender</caption></option>
    <option id="tamu"><caption>Forward to @tamu.edu</caption></option>
    <option id="local"><caption>Store on Neo</caption></option>
    <option id="forward">
      <form>
	<textline><caption>Forward to:</caption></textline>
      </form>
    </option>
  </selection>
  <selection id="tamu">
    <caption>E-Mail forwarding for @tamu:</caption>
    <!-- cut-n-paste above options -->
  </selection>

These elements would render (using my current XSLT) as a drop-down
selection if the forward option were not present.  Because it is
present, I render each as a series of radio buttons with the last
having a single-line text input for the forwarding address.  The
semantics of the two (without and with the forward option) are not
very different, but the XHTML required to render it is.

One thing I do with the data is insert the default / current values
in the DOM from the Perl code instead of requiring it be done in the
TT2 code (so the controller can set up the data and it appears in the
view automagically).  This simplifies the views for the people that
will be managing them.

We also can't depend on customers having modern browsers (and
sometimes fear that they do, in the case of IE 6).  We have customers
all over the globe that must be able to manage their account
information.  This also means that we don't use any scripting except
to make things easier -- everything has to work without scripting on
the client side.
-- 
James Smith <JG...@TAMU.Edu>, 979-862-3725
Texas A&M CIS Operating Systems Group, Unix

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html