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: Thomas <email@hidden>
- Date: Sun, 13 Aug 2006 18:02:12 +1000
These are great ideas. I'd like to add my bit by asking what we are
trying to achieve. Here's my list:
a - do useful template editing without WOBuilder
b - send a working template file to the graphic designer and get it
back still working
c - use a commercial WYSIWYG editor (or other editor of your choice)
to edit a working .wo file
d - edit "WO-smart" content using a web-page-based WYSIWYG editor in
a Content Management System.
e - serve WO components in all sorts of places, like from a database.
a, b and c can be done with separate HTML and WOD files, although I'd
worry about b. They can also be done with some form of pre- and post-
scripting to convert separate HTML and WOD files into a single file
and then back again for return to WebObjects.
d and e require the ability to serve a WO component from a single
file. Contributors to this list, including me, have mentioned ways
they already do this.
I like Pierce's idea of having an optional WOD file, or optional
internal/external tag attributes.
I also like the idea of any tag being converted to a WO tag by adding
suitable attributes. Less chance of the various editors going insane
from semantically improper HTML. Just have to make sure the editors
leave the attributes alone.
So this is my vote for Pierce's idea:
1 - as long as it's optional
2 - yes
3 - lovely! But why don't we extend that to attributes in the HTML
tag including other stuff...
4 - I guess so. I never use this feature in GoLive because I do all
my component re-use in WO.
5 - sounds great! It shouldn't be hard to leave all the tags in
place when the page was generated, but it would get very messy
deciding what was generated and what was in the template. Although
the graphic designers love to have multiple instances of a
repetition, I'd put this one in the too-hard basket right now.
Regards
Thomas
On 13/08/2006, at 12:23, 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
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40woomeranet.com.au
This email sent to email@hidden
_______________________________________________
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