I'm quite hesitant to borrow ideas from people who create web
frameworks in *Java* of all languages ;), but I just briefly looked at
Tapestry and it looks like they use both special tags and optional tag
attributes as an alternative.  It seems like a nice idea, but I doubt
that non-html tags really cause such havoc in Dreamweaver et al. Those
editors probably just ignore them, no? Plus, I always wonder about the
assertion that template languages must be designer-friendly. In most
places I worked, designers produced static HTML and/or graphics and
the coders converted it to working code. No designer was harmed by the
blight of turing-completeness in their templates. But then again, I'm
just speaking from limited life experience :)

Yariv

On Jan 15, 2008 10:00 PM, David Bergman <[EMAIL PROTECTED]> wrote:
>
> I hope this is not OT, but talking about templates, I must say the
> following:
>
> I have used a *lot* of templating systems over the years and the only
> one that stood out was that of Tapestry (a Java-based web framework.)
> So, what can we learn from that system? Well, first of all, we ditch
> the slow and verbose language they use ;-) After that, we should
> acknowledge that they:
>
> 1. Do *not* add any "special tags" but instead
>
> 2. Add *special attributes* of existing HTML tags, and
>
> 3. Add a special attribute for HTML tags that should *only* exist
> during visual editing and *not* during (dynamic) use.
>
> I think - humbly, of course - that this decision is genius. To enable
> those artsy fartsy guys to do their thing (in DreamWeaver or what have
> you) without strange text output (#1 + #2) and with reasonable sample
> data to fill in the template parameters (#3). Ok, the document would
> not be valid XHTML, but what the heck, you win some and you lose
> some ;-)
>
> /David
>
>
> On Jan 16, 2008, at 12:48 AM, Yariv Sadan wrote:
>
> >
> > Being able to plug in tags will be very useful for some applications,
> > e.g. if you want to create an FBML clone in Erlang :)
> >
> > On Jan 11, 2008 7:23 AM, macrocreation <[EMAIL PROTECTED]> wrote:
> >>
> >> Hi Yariv,
> >>
> >> I see the et:if tag as a starting point - all templating systems end
> >> up like the others. Check the tags that openacs ended up with.
> >>
> >> http://openacs.org/doc/acs-templating/tagref/
> >>
> >> What I really liked though was the way the openacs tag system was
> >> implemented - you could plug in arbitrary tags. Essentially you
> >> implemented a function in tcl
> >>
> >> proc process_tag {tag name attribs txt} {
> >>
> >> }
> >> register tag "<sometag>"
> >>
> >> this allows some very clever extensions rather then creating some
> >> hardcoded syntax. I am sure with smerl you appreciate the meta
> >> trickery stuff and how wickedly cool it is.
> >>
> >> Hafeez
> >>
> >> On Jan 11, 7:11pm, "Dmitrii 'Mamut' Dimandt" <[EMAIL PROTECTED]>
> >> wrote:
> >>
> >>> Yariv Sadan wrote:
> >>>> Hi,
> >>>
> >>>> I've seen a few ErlTL enhancement proposals and I'd like to bring
> >>>> them
> >>>> all together and add some of my ideas to the mix so hopefully we
> >>>> can
> >>>> end up with an improved ErlTL. I think the current ErlTL is a good
> >>>> start but after using it for a while I saw some areas where it
> >>>> can use
> >>>> some refinement. Specifically, I think ErlTL could use new syntax
> >>>> for
> >>>> the following expressions: if, case, and map. Below is an example
> >>>> showing the use of the current and proposed syntax (for 'if' and
> >>>> 'map'):
> >>>
> >>>> current:
> >>>
> >>>> <%@ index(Album, Songs, ShowSongs) %>
> >>>> album: <% Album %><br/>
> >>>> <% if ShowSongs ->
> >>>> songs(S);
> >>>> true ->
> >>>> []
> >>>> end %>
> >>>
> >>>> <%@ songs(Songs) %>
> >>>> songs: <br/>
> >>>> <% [song(S) || S <- Songs] %>
> >>>
> >>>> <%@ song(Song) %>
> >>>> song: <% Song %><br/>
> >>>
> >>>> Improved:
> >>>
> >>>> <%@ index(Album, Songs, ShowSongs) %>
> >>>> album: <% Album %><br/>
> >>>> <et:if expr="ShowSongs">
> >>>> songs:<br/>
> >>>> <et:map expr="S <- Songs">
> >>>> song: <% S %><br/>
> >>>> </et:map>
> >>>> </et:if>
> >>>
> >>>> In more detaul, the new syntax would be:
> >>>
> >>>> if:
> >>>
> >>>> <et:if expr="Expr">
> >>>> <et:elseif expr="Expr"> (optional)
> >>>> <et:else> (optional)
> >>>> </et:if>
> >>>
> >>>> case:
> >>>
> >>>> <et:switch expr="Expr">
> >>>> <et:case expr="Expr">
> >>>> stuff...
> >>>> </et:case>
> >>>> <et:case expr="Expr">
> >>>> stuf..
> >>>> </et:case>
> >>>> <et:default> (optional)
> >>>> stuff...
> >>>> </et:default>
> >>>> </et:switch>
> >>>
> >>>> map:
> >>>
> >>>> <et:map expr="Elem <- List, Elem =/= foo">stuff <% Elem %></et:map>
> >>>
> >>>> This syntax is pretty self explanatory. All three constructs
> >>>> would be
> >>>> translated to their Erlang equivalents by the ErlTL parser.
> >>>
> >>>> I think this is a step in the right direction, but I'm not sure
> >>>> that
> >>>> this is the ideal syntax so I'll be happy to hear some other
> >>>> suggestions.
> >>>
> >>> I like it :)
> >>>
> >>> I presume that the old way of doing things will still be available?
> >>>
> >>
> >
> > >
>
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"erlyweb" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/erlyweb?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to