[erlang-questions] parameterized modules alternative in chicago boss like use case

Frédéric Trottier-Hébert fred.hebert@REDACTED
Mon Jul 4 19:43:03 CEST 2011

Encoding stuff as Erlang terms means that if you're working with a designer, integrator, a front-end dev or just any developer who doesn't know about Erlang, you're now forcing them to understand Erlang to work on your site, rather than letting them stick to the technology stacks they already know.

To be on topic, I'm more likely to stick to dicts or gb_trees when dealing with ErlyDTL, and sometimes proplists when the semantics lend themselves to that. In most cases [that I encounter] these structures are good enough to handle everything efficiently.
Fred Hébert

On 2011-07-04, at 13:39 PM, Jachym Holecek wrote:

> # Pablo Platt 2011-07-04:
>> The powerful part is being able to use the model in an erl_dtl template:
>> {% for greeting in greetings %}
>> <li>{{ greeting.text }}</li>
>> {% endfor %}
> [I'll probably be slightly offtopic, but this caught my attention.]
> Hmm, looks like a particularly complicated way to say:
>  [{li, [], Greeting} || Greeting <- somehow_get_list_of_greetings()]
> And you'd pass that to a function that expands [{Tag, Attrs, Body}] to
> HTML (doing some quoting here and there). My point is: why do people keep
> inventing obscure ad-hoc languages instead of just encoding stuff as
> Erlang terms and having normal Erlang functions operate on them?
> Your other concerns then become the usual question of structuring your code
> properly, finding out appropriate representations of things, abstracting out
> common constructs etc.
> But then I must be missing something here; I always must be when it comes
> to Awesome Modern Intarweb Techniques.
> BR,
> 	-- Jachym
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

More information about the erlang-questions mailing list