Template mechanisms...

Adrian Lienhard adi at netstyle.ch
Thu Dec 12 21:53:25 UTC 2002


I think this idea would be a really good approach. It's quite simple and
will work in 90% of the (my) cases.
So far I was used to develop web-apps as following: The designer created a
simple prototype. Then I started coding the web-app - producing ugly, simple
html (e.g. just forms without layout). The prototype was then used by the
designer to create some nicer design. During the development process we had
many iterations of "coding - designing".
Most produced html code by the designer is a) tables (some very complex) and
b) formatting (done with CSS).
I think, an approach which enables an iterative workflow between programmer
and designer would be what many people need.

If Avi's idea could be implemented, it would really be nice. The reminding
10 or 20% of special cases ("every 9th row has an image") would not be a too
big disadvantage or problem, I think.

Adrian

----- Original Message -----
From: "Avi Bryant" <avi at beta4.com>
Sent: Thursday, December 12, 2002 11:40 AM



> 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?
>
> > 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?
>
> Avi
>
>




More information about the Squeak-dev mailing list