Erlang Mailing Lists

Author Message

<  Erlyweb mailing list  ~  ErlTL enhancements

Guest
Posted: Thu Jan 17, 2008 8:31 am Reply with quote
Guest
I'm quite hesitant to borrow ideas from people who create web
frameworks in *Java* of all languages Wink, 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 Smile

Yariv

On Jan 15, 2008 10:00 PM, David Bergman <davber@gmail.com> 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 Wink 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 Wink
>
> /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 Smile
> >
> > On Jan 11, 2008 7:23 AM, macrocreation <hafeez.bana@gmail.com> 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" <dmitr...@gmail.com>
> >> 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 Smile
> >>>
> >>> 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 erlyweb@googlegroups.com
To unsubscribe from this group, send email to erlyweb-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/erlyweb?hl=en
-~----------~----~----~----~------~----~------~--~---

Post recived from mailinglist
dmitriid
Posted: Thu Jan 17, 2008 12:44 pm Reply with quote
User Joined: 17 Aug 2006 Posts: 213
Yariv Sadan wrote:
> Wow, that looks cool, and I haven't known about it.
I'm running an "Erlang in Russian" site with a regularly updated news
page. I have subscribed to probably every "Erlang planet" RSS feed out
there Smile Sometimes I get the news before it gets spread around the blogs Smile

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

Post recived from mailinglist
View user's profile Send private message
rsaccon
Posted: Thu Jan 17, 2008 3:12 pm Reply with quote
User Joined: 09 Aug 2006 Posts: 144
ErlyDTL is in most aspects (simplicity, enforcing Model/View
separation, exposing Erlang to templates) the opposite of ErlTL,
expect for performance, of course, so I wouldn't recommend to replace
ErlTL with it. But offering both, that makes sense to me.

On Jan 17, 4:49 am, "Yariv Sadan" <yarivsa...@gmail.com> wrote:
> Wow, that looks cool, and I haven't known about it. It would be pretty
> easy to integrate this into ErlyWeb, actually. I'm not sure yet if I
> prefer it to an enhanced ErlTL, but I all for giving developers the
> choice of which one they should use.
>
> On Jan 16, 2008 4:09 AM, Dmitrii 'Mamut' Dimandt <dmitr...@gmail.com> wrote:
>
> > Yariv Sadan wrote:
> > > Hi,
>
> > > I've seen a few ErlTL enhancement proposals
> > There's also ErlyDTL,
> >http://www.rsaccon.com/2008/01/erlydtl-django-template-language-in.html
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "erlyweb" group.
To post to this group, send email to erlyweb@googlegroups.com
To unsubscribe from this group, send email to erlyweb-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/erlyweb?hl=en
-~----------~----~----~----~------~----~------~--~---

Post recived from mailinglist
View user's profile Send private message
Guest
Posted: Thu Jan 17, 2008 4:09 pm Reply with quote
Guest
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 Wink - 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 Wink, 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 Smile
>
> Yariv
>
> On Jan 15, 2008 10:00 PM, David Bergman <davber@gmail.com> 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 Wink 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 Wink
>>
>> /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 Smile
>>>
>>> On Jan 11, 2008 7:23 AM, macrocreation <hafeez.bana@gmail.com>
>>> 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" <dmitr...@gmail.com>
>>>> 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 Smile
>>>>>
>>>>> 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 erlyweb@googlegroups.com
To unsubscribe from this group, send email to erlyweb-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/erlyweb?hl=en
-~----------~----~----~----~------~----~------~--~---

Post recived from mailinglist
Guest
Posted: Thu Jan 17, 2008 4:57 pm Reply with quote
Guest
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 Wink, 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 Smile
>
> Yariv
>
> On Jan 15, 2008 10:00 PM, David Bergman <davber@gmail.com> 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 Wink 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 Wink
>>
>> /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 Smile
>>>
>>> On Jan 11, 2008 7:23 AM, macrocreation <hafeez.bana@gmail.com>
>>> 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" <dmitr...@gmail.com>
>>>> 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 Smile
>>>>>
>>>>> 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 erlyweb@googlegroups.com
To unsubscribe from this group, send email to erlyweb-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/erlyweb?hl=en
-~----------~----~----~----~------~----~------~--~---

Post recived from mailinglist
Guest
Posted: Thu Jan 17, 2008 8:25 pm Reply with quote
Guest
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 <bmunat@gmail.com> 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 Wink, 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 Smile
> >
> > Yariv
> >
> > On Jan 15, 2008 10:00 PM, David Bergman <davber@gmail.com> 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 Wink 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 Wink
> >>
> >> /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 Smile
> >>>
> >>> On Jan 11, 2008 7:23 AM, macrocreation <hafeez.bana@gmail.com>
> >>> 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" <dmitr...@gmail.com>
> >>>> 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 Smile
> >>>>>
> >>>>> 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 erlyweb@googlegroups.com
To unsubscribe from this group, send email to erlyweb-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/erlyweb?hl=en
-~----------~----~----~----~------~----~------~--~---

Post recived from mailinglist
Guest
Posted: Fri Jan 18, 2008 6:06 am Reply with quote
Guest
ErlyDTL doesn't seem to be opposite the ErlTL, at least in terms of
enforcing model/view separation. It is indeed more complex, but it has
some nice features that ErlTL doesn't have. The real question is what
template language most developers prefer -- an enhanced ErlTL with
custom tags or ErlyDTL. I'm not planning on replacing ErlTL, but if
enough developers want ErlyDTL I think it would be good to support it.

On Jan 17, 2008 7:11 AM, Roberto Saccon <rsaccon@gmail.com> wrote:
>
> ErlyDTL is in most aspects (simplicity, enforcing Model/View
> separation, exposing Erlang to templates) the opposite of ErlTL,
> expect for performance, of course, so I wouldn't recommend to replace
> ErlTL with it. But offering both, that makes sense to me.
>
> On Jan 17, 4:49 am, "Yariv Sadan" <yarivsa...@gmail.com> wrote:
> > Wow, that looks cool, and I haven't known about it. It would be pretty
> > easy to integrate this into ErlyWeb, actually. I'm not sure yet if I
> > prefer it to an enhanced ErlTL, but I all for giving developers the
> > choice of which one they should use.
> >
>
> > On Jan 16, 2008 4:09 AM, Dmitrii 'Mamut' Dimandt <dmitr...@gmail.com> wrote:
> >
> > > Yariv Sadan wrote:
> > > > Hi,
> >
> > > > I've seen a few ErlTL enhancement proposals
> > > There's also ErlyDTL,
> > >http://www.rsaccon.com/2008/01/erlydtl-django-template-language-in.html
> >
>

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

Post recived from mailinglist
Guest
Posted: Fri Jan 18, 2008 6:14 am Reply with quote
Guest
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 Smile

Yariv

On Jan 17, 2008 8:08 AM, David Bergman <davber@gmail.com> 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 Wink - 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 Wink, 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 Smile
> >
> > Yariv
> >
> > On Jan 15, 2008 10:00 PM, David Bergman <davber@gmail.com> 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 Wink 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 Wink
> >>
> >> /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 Smile
> >>>
> >>> On Jan 11, 2008 7:23 AM, macrocreation <hafeez.bana@gmail.com>
> >>> 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" <dmitr...@gmail.com>
> >>>> 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 Smile
> >>>>>
> >>>>> 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 erlyweb@googlegroups.com
To unsubscribe from this group, send email to erlyweb-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/erlyweb?hl=en
-~----------~----~----~----~------~----~------~--~---

Post recived from mailinglist
Guest
Posted: Fri Jan 18, 2008 6:18 am Reply with quote
Guest
On Jan 17, 2008 8:57 AM, Ben Munat <bmunat@gmail.com> 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 Wink, 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 Smile
> >
> > Yariv
> >
> > On Jan 15, 2008 10:00 PM, David Bergman <davber@gmail.com> 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 Wink 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 Wink
> >>
> >> /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 Smile
> >>>
> >>> On Jan 11, 2008 7:23 AM, macrocreation <hafeez.bana@gmail.com>
> >>> 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" <dmitr...@gmail.com>
> >>>> 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 Smile
> >>>>>
> >>>>> 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 erlyweb@googlegroups.com
To unsubscribe from this group, send email to erlyweb-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/erlyweb?hl=en
-~----------~----~----~----~------~----~------~--~---

Post recived from mailinglist
Guest
Posted: Fri Jan 18, 2008 6:42 am Reply with quote
Guest
On Jan 17, 2008 12:24 PM, David Mitchell <monch1962@gmail.com> wrote:
>
> 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.

Adding custom tags won't slow ErlTL down. Those tags would be compiled
to Erlang beam code just like existing Erlang expressions in ErlTL
templates. It's just syntactic suger, nothing more.

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

I think there many reasons to pick ErlyWeb over Rails besides speed:

- Concurrency. There are many ways you can use concurrency in your
webapp both to enable new features (e.g. comet, which you have to be
insane to try with Rails) and to improve existing ones (do things in
parallel or in the background to improve page load times). I think the
area of concurrency in webapps is relatively unexplored because most
web developers use languages that make using concurrency too
hard/impractical/unscalable. With ErlyWeb you have a green field of
exploration in front of you. (Here's something I ran into recently: in
a Facebook app, instead of updating user's profile FBML or feed or
sending notification in the same flow as the controller action, you
can spawn those actions into different processes to get faster
perceived response time. It's pretty cool I think. Don't try it with
Rails.)

- Elegance. ErlyWeb has a much nicer component system than Rails' soup
of partials/layouts/components. Erlang code is also more readable than
Rails code IMHO due to immutable variables and generally side-effects
free programming. Plus, functional programming really is nicer than
imperative/OO programming. It's admittedly subjective, but I've used
plenty of imperative languages and I just like the functional style
more. (Erlang can admittedly be awkward sometimes, but the benefits
outweigh the awkwardness.)

- Pushing the boundaries. Rails is only good for CRUD apps. With
ErlyWeb, you can build CRUD apps just as easily as in Rails, but you
can also build a backend that rivals Amazon/Ericsson/Yahoo/Google
scale systems. Rails narrows your imagination -- ErlyWeb expands it.

- Reliability. Compare Twitter to an Ericcson phone switch or Amazon SQS.

- Community. Just ask Zed
http://www.zedshaw.com/rants/rails_is_a_ghetto.html Smile

Yariv

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

Post recived from mailinglist
dmitriid
Posted: Fri Jan 18, 2008 8:57 am Reply with quote
User Joined: 17 Aug 2006 Posts: 213
Yariv Sadan wrote:
> I think there many reasons to pick ErlyWeb over Rails besides speed:
>
> - Concurrency. There are many ways you can use concurrency in your
> webapp both to enable new features (e.g. comet, which you have to be
> insane to try with Rails) and to improve existing ones (do things in
> parallel or in the background to improve page load times). I think the
> area of concurrency in webapps is relatively unexplored because most
> web developers use languages that make using concurrency too
> hard/impractical/unscalable. With ErlyWeb you have a green field of
> exploration in front of you. (Here's something I ran into recently: in
> a Facebook app, instead of updating user's profile FBML or feed or
> sending notification in the same flow as the controller action, you
> can spawn those actions into different processes to get faster
> perceived response time. It's pretty cool I think. Don't try it with
> Rails.)
>

Here's a scenario I'm looking forward to:
Start a pool of Python nodes for complex image processing using Python
Imaging Library
When images are uploaded, queue them for processing in the pool, return
to the user

There are other interesting scenarios where ErlyWeb can easily defer
processing to some node/suprevision tree running in the background and
return to user immediately without having to wait indefinitely long for
a process to finish.

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

Post recived from mailinglist
View user's profile Send private message
wuji
Posted: Tue Aug 14, 2012 7:44 am Reply with quote
User Joined: 10 Aug 2012 Posts: 654
for information leading to the capture of Miguel Angel and and cheap polo ralph lauren and Omar.The brothers, whose numeric aliases refer to their alleged
within the Zetas at the time of the cartel's creation creation [h4]jordan 6[/h4] creation several years ago, are now allegedly top leaders of
organization that controls drug trafficking in the east and south south [h4]cheap jordans[/h4] south of Mexico. Miguel, or "40," allegedly runs the Zetas
with "3," Heriberto Lazcano.The Zetas began in 1999 when former former jordan 6 former members of the Mexican military signed on to work
security for the Gulf drug cartel. The Zetas went into into knockoff designer *beep* into business for themselves and are now at war with
View user's profile Send private message

Display posts from previous:  

All times are GMT
Page 2 of 2
Goto page Previous  1, 2
This forum is locked: you cannot post, reply to, or edit topics.

Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum