Avi Bryant <avi at beta4.com> wrote:
> On Thu, 12 Dec 2002 goran.hultgren at bluefish.se wrote:
> 
> > I have my doubts. But the idea of going with the "programmatic" approach
> > being able to add "tracking device ids and divs", then feeding the pages
> > to the designer and back and producing some kind of internal template
> > DOM-kindof thing and finally simply "turn off" the minimal visual fluff
> > that was needed from the start feels like a real cool way of doing it.
> > Sortof XMLC inspired but a bit more "round-trippy". :-)
> 
> I think generated tracking ids are going to be more trouble than they're
> worth - if they're generated, all they can really reflect is sequence, and
> that's not terribly stable.  So I think we should be going on
> developer-provided ids, which means we might as well use the CSS id
> attribute (and ensure that everything thus has a CSS id while we're at
> it).

I actually was thinking of the CSS id. That's how XMLC does it I think
and it wouldn't trip up any HTML tool. But what do you gain from having
them "developer provided"?

> So what we're building is an HTML merge tool - you have to merge
> the HTML generation code with the HTML template from the designer.
> I've been thinking about how you would manage this with HtmlRenderer (or
> HV's HtmlBuilder), but actually, I think it would be much, much easier to
> do at the HTML level, when you have two complete pieces of output.  That
> also means it could stand on its own, apart from either Seaside or HV.

Hmmm, possibly. (this starts to sound like XSL... Hrmph.)

> So we narrow to this: you have two HTML documents, both with
> matching CSS ids, one with content, and one with presentation fluff.  You
> want to merge the content from one into the fluff of the other.
> 
> As a first pass, how about this: take the fluffed document.  Any element
> that is found that matches an element (same id) in the content document,
> has its attributes replaced with the equivalents from the content
> document.  Elements whose only child is a piece of text, should have
> that text treated as an attribute as well.  The tag names are always taken
> from the fluff document.
> 
> Once an element has been matched, its children should be matched against
> the children of the corresponding content element.
> 
> If a content element repeats, the corresponding template element should
> also be repeated.
> 
> So, if your content output is this:
> 
> <h1>Edit Names</h1>
> 
> <form id="names" action="1245">
> <div id="nameRow">
>   <span class="label">1</td>
>   <input type="text" name="1" id="name" value="Avi">
> </div>
> 
> <div id="nameRow">
>   <span class="label">2</span>
>   <input type="text" name="2" id="name" value="Goran">
> </div>
> 
> <input type="submit">
> </form>
> 
> and your template is this:
> 
> <form id="names">
> <table>
> <tr>
>  <td colspan="2">Edit Names</td>
> </tr>
> <tr id="nameRow">
>  <td class="label" align="right">42</td>
>  <td><input type="text" id="name" size="40"></td>
> </tr>
> <tr>
>   <td colspan="2"><input type="submit" value="Save"></td>
> </tr>
> </table>
> 
> then the final output should be this:
> 
> <form id="names" action="12345">
> <table>
> <tr>
>  <td colspan="2">Edit Names</td>
> </tr>
> <tr id="nameRow">
>   <td class="label" align="right">1</td>
>   <td><input type="text" id="name" size="40" name="1" value="Avi"></td>
> </tr>
> <tr id="nameRow">
>   <td class="label" align="right">2</td>
>   <td><input type="text" id="name" size="40" name="2" value="Goran"></td>
> </tr>
> <tr>
>   <td colspan="2"><input type="submit" value="Save"></td>
> </tr>
> </table>
> 
> Now obviously those rules are somewhat open to interpretation, and we need
> to write some solid test cases, but I don't think they're impossible to
> implement, and they may be flexible enough to do what you want.
> 
> But then, it's late, so this may be gibberish.
> 
> The hardest part, incidentally, will be handling non-regular repeats.
> What if every nth row has an image in it that the others don't?  How can
> the template represent that?

Right, it gets complicated. When stuff gets dynamic it falls somewhat
apart.
But I like the general approach - more or less like I envision it - even
though I can't see why you need "developer assigned" ids.

> > The only thing I can't really see is how to handle the "component"
> > aspect. The webdesigner wants to work with pages (I guess) but a page
> > may be composed of Seaside/HttpView components of some sort. What do we
> > do with the glorified page when it comes back? How would the mapping be
> > done?
> 
> Yes, it's awkward.  Put some comments marking the beginning and end of
> each component, and split the template into those segments when you read
> it in.  The comments will have info about which component class those
> segments should be attached to.  The difficult part is that the same
> components will show up in multiple templates, and how do you pick which
> version to use?

Exactly. You need to somehow map "skins" onto the components depending
on some form of context. "When this component is used in this page it
should have this skin but not otherwise" or "This component should have
this skin in all cases except when otherwise noted" etc.

The end result I am "after" is to provide an "active" application that
the webdesigner can edit and run at the same time. More or less he/she
saves the HTML into Dreamweaver, edits it, saves it in a special folder.
Seaside/HttpView picks it up, finds a "page id" inside the file and
"applies" the fluff somehow to the system. The designer does a reload
and voíla it looks better (almost Swikilike in behaviour). Repeat. :-)

> Avi

regards, Göran