[erlang-questions] Thoughts on EHE - the PHP killer

Tim Watson <>
Mon Feb 20 22:59:31 CET 2012


On 20 February 2012 19:54, Edmond Begumisa <> wrote:
> On Mon, 20 Feb 2012 01:17:19 +1100, Tim Watson <>
> wrote:
>
>> On 19 February 2012 03:39, Steve Vinoski <> wrote:
>>>
>>> To paraphrase:
>>>
>>> .yaws file: sprinkle a little Erlang into your HTML
>>> appmod: sprinkle a little HTML/XML/JSON/whatever into your Erlang
>>>
>>> An appmod is like a servlet, I suppose. It's code that handles
>>> requests made to a configured portion of the server URI space (the
>>> path can be "/" to handle all requests to that server), and can do
>>> pretty much anything it needs to in order to fulfill each request.
>>>
>>> In my own development work with yaws, I use appmods almost exclusively
>>> because they're totally flexible.
>>>
>>> --steve
>>
>>
>> Thanks steve, that was the understand I had come to from looking at
>> what's on the site. What I haven't quite figured out is how the stuff
>> in an out/1 function gets interspersed with the surrounding HTML and
>> what happens when there are multiple out/1 definitions and so on.
>
>
> Say you have a file:
>
> ...blah1...
> <erl>.. out/1...</erl>
> ...blah2...
> <erl>.. out/1...</erl>
> ...blah3...
>
> IIRC, the individual <erl></erl> tags within the same file are compiled into
> seperate Erlang modules at runtime when the file is first requested and the
> compiled modules are cached. out/1 is then called for each module and the
> outputs combined with the text outside the <erl> tags. Something like...
>
> send(Blah1),
> send(mod1:out(Arg)),
> send(Blah2),
> send(mod2:out(Arg)),
> send(Blah3)
>
>
>> But frankly, I'm *much* more likely to use appmods anyway, as like you say
>> they're a lot more like a servlet.
>>
>> I think I might go away and wire up some
>> https://github.com/hyperthunk/annotations with so that you can write a
>> handler that takes parts of the request URL and other bits from the
>> Arg record declaratively. I think it will be quite easy to write an
>> appmod that uses this to reroute the request, giving me something that
>> looks a bit like this:
>>
>> -controller({"/accounts/{account_type}", 'POST', include_body}).
>> get_account(AccountType, PostBody, YawsArg) ->
>>    ....
>>
>> -controller({"/accounts/{account_type}/{account_number}/", 'GET'}).
>> get_account(AccountType, AccountNum, YawsArg) ->
>>    ....
>>
>> Obviously this isn't as cool as a webmachine-a-like running on YAWS,
>> but I *think* I can make it work quite easily and it makes for more
>> convenient mapping of URLs to controller/handler module + function.
>>
>> Next question I have is, how hard would it be to do something like a
>> servlet filter in YAWS? I could do this quite well using annotations -
>> that's how ErlangWeb does it, albeit with macros instead - but is that
>> the best way? It would look something like this (and is quite easy to
>> implement using annotations):
>>
>> -secured({auth_provider, oauth}).
>> -controller({"/accounts/{account_type}/{account_number}/", 'GET'}).
>> get_account(AccountType, AccountNum, YawsArg) -> ....
>>
>>
>> Is there something else in YAWS like appmod that'll do a filter chain,
>> or am I better off using annotations?
>
>
> This is a great idea. Your annotations tools would be really useful here.
>
> What would REALLY be cool is a set of general-puprose reusable annotations
> specifically for yaws, not only for code but for default content too.
>
>

I'd love to do that, but I actually have *no idea* when I'm actually
going to find time to even play with YAWS properly at the moment
(which I want to do) but I am making a mental note (on google :) about
this. :)



More information about the erlang-questions mailing list