At 01:40 PM 5/29/2001 -0500, Ian Bicking wrote:
>Though if IE had just kept the HTMLINPUT tag, that would have helped a
>lot too. It was such a good idea. Sigh.
What was that? I never heard of it.
>It's quite improper, but it works, and it gets around the fact that
><form> is paragraph-level.
Oh, yeah! I did the exact same thing to avoid the extra space. (sigh)
>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.
You're only annoyed because you're using a text editor.
Use any spreadsheet. Then you will be very happy.
>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.
You can do this now. Check out the test suite for UserKit. I create an MK
model there *in Python*.
Knock yourself out. ;-)
>Anyway, XML would still be much more readable for me, and better able
>to support future expansion without getting unreadable.
Well, you can add the support if you like. MK models can be created by CSV
or Python. XML would just be another technique.
I'm not sure at what point we should break out the reading of models into
mix-ins rather than the main base...
I'd also be curious if ArgoUML's flavor of XML could be read *and* if
ArgoUML is flexible enough to capture non-UML-corresponding aspects of MK's
model via attribute dictionaries (or some other technique) in the GUI.
Why? Because then you could define your object model in Argo and use it in
MiddleKit.
http://www.argouml.org/
>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'm not clear on why Velocity breaks images:
<IMG SRC=$foo>
$foo could expand to:
"foo.gif"
or even:
"foo.gif" width=10 height=10
What am I missing?
>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).
Would WebUtils.HTMLTag help at all here? It puts HTML into a Pythonic
structure. It doesn't have many manipulative conveniences right now. Just
searching and writing the HTML back out.
-Chuck
_______________________________________________
Webware-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/webware-devel
