I see your point, but it would be easier to decide if you could propose an alternative to special tags that wouldn't be more cumbersome to write. <et:if Expr> <et:case Expr> <et:map Expr List> etc are quite succinct, more so than, e.g., <span type="et:if">. Having said that, I wouldn't be opposed to having both options and let the developers decide.
Would you want to implement this? You're much better than me at writing compilers :) Yariv On Jan 17, 2008 8:08 AM, David Bergman <[EMAIL PROTECTED]> wrote: > > Y, > > Regarding the two phase approach (idea ---[artsy fartsy people > designing]---> pretty pictures ---[real men coding some life into the > pictures]---> cool product that makes millions for the real men!), I > too want it that way, but it has rarely been my experience in > commercial projects that the designers does not want - and sometimes > need - to change the look of things after the first iteration. > > So, having a template system that allows for designers to do their > thing while we men can stand aside without fear of (i) them messing up > our special tags, since they show up as Weird Stuff in their editor or > (ii) give us something that will change its visual appearance > considerably when dynamic data is added is a good thing. > > Again - hoping that repetition will make my case stronger > intrinsically ;-) - I do believe in not having non-HTML tags and > having filler tags that will be skipped by the runtime system, just to > create a realistic static layout and look for designers. > > /David > > > On Jan 17, 2008, at 3:20 AM, Yariv Sadan wrote: > > > > > 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 -~----------~----~----~----~------~----~------~--~---
