In any case, I respectfully (and without a great deal of deep
thought) disagree with your position. I have always appreciated how
relatively clean WO left the html template file with the only tag
added being a simple <webobjects name=x> tag that our graphics
designers had no trouble recognizing or working around.
I still prefer that over the clutter that some of the other web
serving technologies leave in their html templates.
There are good parts and bad parts to the current syntax.
Is <WEBOBJECT name="blah"/> clean? Absolutely. I also think the
separation between code and HTML is one of the strengths of WO.
But doing the following:
<WEBOBJECT name="form">
</WEBOBJECT>
form: WOForm
{
action=doit;
}
Bugs me... I think:
<FORM woname="form"></FORM>
Would be just as clean, and an HTML editor would know that FORM
tags can be enclosed.
If you've ever done complex XML with WO, you can see how it can
get weird quick.
<WEBOBJECT name="foo1">
<WEBOBJECT name="foo2">
<WEBOBJECT name="foo3">
<WEBOBJECT name="foo4">
</WEBOBJECT>
</WEBOBJECT>
</WEBOBJECT>
</WEBOBJECT>
If I was going to design a new templating system, it would be based
on the following ideas:
1. Code and HTML should be separate. So yes, Virginia, there will
be .wod files, especially because of feature #3. Rather then be
religious about it, some wo declarations can be in the .html, but the
wod wins.
i.e.
<FONT woname="userFont"></FONT>
userFont : attributes
{ name=user.preferences.fontName; }
Might be less readable/maintainable then:
<FONT wo:name=user.preferences.fontName></FONT>
So .wod files will be there, which implies a bundle
with .api, .java, .woo, but for simple tags, you can omit the
declaration. You might not want to, because of feature #3, because if
you're doing the same declaration over and over, it makes sense to be
in a common .wod.
2. Any tag can be made dynamic by adding the appropriate
attribute. An in-html attribute determines the action taken:
attributes sets the tag attributes leaving the tag and any contents
alone, replace replaces the tag and contents, contents replaces the
tag contents. (See HotMeTaL in Zope, Tapestry, etc.) This is
especially helpful in XML.
3. .WOD files can #include other files, providing both a primitive
form of inheritance (#include <super.wod>) and an easy way to have
constant declarations:
timeDisplay: WOString
{ timeformat=application.localization.timeFormat; }
This would save me cutting/pasting the superclasses .wod file
everytime I make a subclass, which means I've just copied all the
bugs as well! This would work pretty simply as last binding wins:
foo: WOString { value=x;}
foo: WOString { value=y; dateformat="%b"; }
foo: WOString { value=z; }
results in:
foo: WOString
{
value=z; dateformat="%b";
}
You can remove a binding this way:
dateformat= <NULL>;
4. It would understand at least one WYSIWYG include mechanism, so
that you can use their existing component like architecture. That is,
DreamWeaver lets you build sites out of pieces just like WO does.
5. <optional, because I'm not sure it would work>
There would be a mode you could put the application into that
leaves the WO specific stuff in such that an Artist could save the
HTML (with sample data!) to disk, edit the HTML and give it back to a
programmer.
That is, even as a hard-core-edit-the-raw-HTML person, I'd love
to be able
to store sample data in elements:
<TD><span woname=ignore>User Name></SPAN></TD>
What do you think of those principles?
Pierce
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to archive@mail-archive.com
