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