Chuck Esterbrook <[EMAIL PROTECTED]> wrote:
> >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.  :-)

While I myself wouldn't use many XML tools very often, I would
seriously consider suggesting them for complex, generalized data
entry.  Well, *if* I was aware of any tools that work that way.  HTML
forms for putting stuff in a database are sorely lacking in many
respects.  XML tools for the novice (not the programmer) could be
very useful to describe truly non-HTML structured data.

Though if IE had just kept the HTMLINPUT tag, that would have helped a
lot too.  It was such a good idea.  Sigh.

> 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.

I do it all the time in real HTML, as:

<table><tr>
<form action="something">
<td><input type="submit" value="something"></td>
</form>
<form action="somethingelse">
<td><input type="submit" value="something else"></td>
</form>
</tr></table>

It's quite improper, but it works, and it gets around the fact that
<form> is paragraph-level.

> >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.

I must say that MiddleKit's CSV model descriptions are awfully
annoying.  I write code in a text editor, the model is part of the
code (even if it declarative), and counting commas is difficult.

But I'd personally prefer it just be a Python expression, like maybe:

Klass('Video', isAbstract=True, attributes=[
    Attribute('title', 'string', isRequired=True, min=1, max=100),
    Attribute('directors', ['Person'], isRequired=False, max=100),
    Attribute('cast', ['Role'], isRequired=False),
    ])

Or something like that.  I don't like 'list of Person', but ['Person']
isn't that good either.

Anyway, XML would still be much more readable for me, and better able
to support future expansion without getting unreadable.

> 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?".

I have kind of moved elsewhere, as I've decided I've needed to do
more, um, concretely productive work.  But I still kind of like the
ZPT syntax.  Specifically, there's no good way to do table-row
repetition solely within a WYSIWYG editor with the Velocity-style
syntaxes (which is, on the larger level, the same syntax that most
template systems use -- i.e., on the text level).  It's also nice with
dynamic SRC attributes in a IMG tag, where Velocity-style means you
get a broken image, and also don't get automatic HEIGHT and WIDTH
tags, or whatever else your WYSIWYG editor can do for you.

I also like the ability to use the same system to do HTML-level
transformations.  Similar to XSLT, except in a procedural language we
already know (Python).

  Ian

_______________________________________________
Webware-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/webware-devel

Reply via email to