At 02:50 PM 5/29/2001 +0200, Ruggier, Mario wrote:
>The (rather terse) discussion at the beginning of xyaptu.py tries
>to list the main requirements for something like xyaptu. Other than
>**simplicity**, an important feature is that the extra template-mark-up
>in a html/xml document must itself not invalidate the html/xml document.
>But, whether the html/xml document is valid or not in the first place
>is the responsability of the author.
Right, but I was also pointing out that TS might already allow this, or be
easy to modify to allow it. That would save you some re-invention as TS has
plenty of features, a growing test suite, etc.
>In the case of HTML/XML, such faithfullness is a significant
>advantage as this would keep open the option to manipulate
>templates (HTML/XML + extra template mark-up) with any tool in
>the ever-growing world of XML tools. (I am quite surprised that
>*sp frameworks throw away xml-compliancy so easily, making
>generation of asp or jsp pages, from obvious tool choices such
>as xslt, require unnecessary twists and acrobatics.)
I don't personally subscribe to the "XML tools" argument, which has been
presented to me for so long. As of today, I don't personally know anyone
both using various XML tools and requiring that they work with their
templates. Actually, I don't know anyone using XML tools. :-)
>And, even if only for HTML, something as innocuos-looking as:
>
> <table>
> #for logEntry in $logEntries:
> <tr ...
> ...
> </tr>
> #end for
>
>will choke an html parser, as text is not allowed between
>table and tr. Thus the option to use parser-based html tools,
>to process and rewrite templates, is lost.
I have an HTML parser (Webware.WebUtils.HTMLTag) that works fine for the
above. Knowing that HTML is not always precise and that various templating
languages are already out there, my parser allows arbitrary <tags> to
contain text. Whether or not you want to force the issue after parsing, is
up to you.
Likewise, most browsers will deal with the above in some fashion or another
without balking.
>Imagine a web application with an extensive user interface, and
>an abstract description of that interface in, naturally, xml.
Actually, I find these things to be _much_ more natural in CSV than XML.
Easier to read, edit and process. Admittedly, CSV doesn't do well with
arbitrarily nested structures. So far, that hasn't been an issue for me.
> From this description you want to generate every actual
>'pageview' that the user sees... targeted for different contexts
>(HTML, WML, ...), different languages, and so on. The interest in
>being able to use xml-based tools to straightforwardly generate
>all pageview templates would be rather high...
My choice here is Python, which is a simple, but complete language with
lots of power and libraries. I use XML only for communicating with other
systems. Not for "coding", generation and such.
>Admittedly, seeing the code in a (current web) browser is a
>convenience. But this is viewer dependent. XML viewers may be used.
An XML viewer will not *render* the [X]HTML. The page designers I work with
want to see a rendered page in Netscape or IE _with_ the templating
instructions. So do I.
>Also note that, xyaptu syntax can also change to something like:
><yaptu-open>for logEntry in LogEntries:</yaptu-open> ... for
>which, by default, web browsers would show the code when previewing.
>This, other than being very easy to do (change 4 regexp's), would
>be a bit of a design compromise in my view.
>
>No best way exists, ofcourse, and the gain some--lose some
>syndrome is always nagging. And then there are aesthetics...
>which is where I will stop ;-)
You're right. There are pros and cons on both sides and I've had numerous
discussions over the past few months about them. Ultimately, I came to the
conclusion that a Velocity-like syntax is the most productive for the most
cases.
BTW I CCed webware-devel where these discussions on templating design are
taking place. Although recently they have quieted down as we have phased
out of "What should it look like?" to "Who's implementation is doing what?".
-Chuck
_______________________________________________
Webware-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/webware-devel
