On Jan 17, 2008 8:57 AM, Ben Munat <[EMAIL PROTECTED]> wrote: > > I have to jump in here with my two cents... I think this is a big > mistake. Ok, maybe not a mistake per se... Going the plain old code- > mixed-with-markup template route would be what most of the web dev > world would expect. And that's not really something to take lightly. > > However, the designer/developer disconnect is not something to blow > off so easily either. I have seen problems and frustrations arise from > this in several places. I don't use dreamweaver, but I would imagine > that it deals with special tags the same way as a browser: it prints > them in the page! At this point your designer is having an epileptic > fit. Also, the statement that "designers produced static HTML and/or > graphics and the coders converted it to working code" is rather > naive... no one ever makes changes in your world?
I would think designers work off the original designs when they make changes and the developers apply the changes to the templates, but I understand that it's not the way everyone or even most people work. I just think it's weird that all the popular web frameworks *don't* attempt to shield designers from code yet almost everyone uses their template languages. What gives? > > However, like I was saying above, the holy mess of template hell is > the status quo. No one would be expecting your web framework do do > anything differently. And actually, if people are trying to pick up > erlang at the same time, not taking the template approach might add to > the intellectual load. > > Oh, and Tapestry actually isn't the best model for this approach... at > least the last time I looked at it ( a few years back), they were > adding their own attributes to html tags. This is not valid according > to the html DTDs. A better approach is what Wicket does, which is > adding namespaced attributes. Interesting... I'll look at Wicket. > > I think that this is just one extra level of indirection and gives > excellent separation of concerns. > > Ben > > > > On Jan 17, 2008, at 12: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 -~----------~----~----~----~------~----~------~--~---
