My 2c... One of the biggest attractions of ErlyWeb to me (and I suspect many others) is that it gives a RAD environment, is MVC-based and ***runs fast***.
I know from my Zope days that introducing TAL (a tag mechanism for views that was specifically designed to be friendly to both developers and designers) in place of DTML (an ASP-like tag mechanism that was ugly for designers) resulted in a fairly massive slowdown of Zope apps. I can definitely see the attraction of making ErlyWeb tags more designer-friendly, but I think that if it involves slowing down ErlyWeb performance by any measurable amount, it probably should be avoided. Let's face it: if it wasn't for the speed of ErlyWeb, we may as well use Rails. Both can scale by adding hardware, but it's the speed of ErlyWeb that makes it shine. Any thoughts??? Regards Dave M. On 18/01/2008, 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? > > 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. > > 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 -~----------~----~----~----~------~----~------~--~---
