Re: WOComponents are dead, long live smart tags!
Re: WOComponents are dead, long live smart tags!
- Subject: Re: WOComponents are dead, long live smart tags!
- From: "Jerry W. Walker" <email@hidden>
- Date: Sun, 13 Aug 2006 12:00:42 -0400
Hi, Pierce, et al,
I strongly prefer the simplicity built into the current named-WO-tag
reference to attributes in the .wod file. At times I would prefer
slightly more convenience at product creation time when I'm hand
editing the files, but that always weighs against the limited amount
of trouble that the current scheme can allow neophytes to cause as
I'm professionally called in to clean up their messes.
I've never been tasked with creating a tool to replace WO Builder
and, if I were so tasked, I might be very open to changing my mind on
this. I would hate to see it go the direction of CSS in which I find
it ever more difficult in maintenance mode to determine what
attributes are active on a given tag and where they were set given
the possibilities of included files, in line attributes, inherited
attributes, generic attributes, etc., etc.
Beyond that, I'm sorry, but I'm feeling further and further out of
the loop. Apple made some significant announcement about the
direction of WO. Anyone who has heard the announcement is under NDA,
so can't tell the rest of us what the new direction is.
Ensuing discussions have strongly suggested something on a spectrum
between these two ends:
* Apple keeps and maintains the WO frameworks, has deprecated the
tools and is substituting new tools, made for other purposes (e.g.
Dashcode & Web Clip, or the Xcode EOModel Design Tool).
* Apple has pushed the whole kit and caboodle into open source and
is hoping that the community can come together constructively to
catch the ball.
Given Apple's dependence on WO as a production tool for their own
sites, I suspect that the actual announcement was closer to the
former rather than the latter.
However, the permutations of possibilities across that spectrum, even
with a probability bias towards the former, leaves me not wishing to
spend too much creative time right now either thinking of new,
improved ways of doing things, or commenting on suggestions by others
until I can shake this feeling of treading on quicksand and emerge
from its resulting and increasing ennui.
Please carry on without me until I've heard or read the Apple
announcement.
Regards,
Jerry
On Aug 12, 2006, at 10:23 PM, Pierce T. Wetter III wrote:
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
--
__ Jerry W. Walker,
WebObjects Developer/Instructor for High Performance Industrial
Strength Internet Enabled Systems
email@hidden
203 278-4085 office
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden