> - A while ago somebody asked a similar question and Bryan Fink
> suggested returning a tuple of the form {title, Title} from the view
> function, and then later picking up this tuple in the
> html_container_controller and using its value to set the <title> tag.
That does only take into account <title>s, and not any other
metadata. And doesn't using erltl preclude returning something useful
from a view function other than the data itself? And then the
component receiving the rendered page would have to walk the
resultant IOlist looking for it, rather than being able to pattern-
match it. That just seems very brittle. I guess I could have one view
function like
contents([Title,[Contents,AuthorName]]) ->
[[{title,Title},
{other_metadata,etc}],
post_view_erltl:contents([Contents,AuthorName])].
And then another module with the erltl itself, but that also seems
rather contrived. Maybe it makes sense to have a list in the
html_container of controllers:functions that require meta-data and
know to call them and ask for the <title>, but that also seems
brittle as the controllers:functions change.
> - Use the process dictionary to store any values that need to be used
> later outside the current component.
Ech, that sounds terrible, and it relies on Erlyweb doing all of the
work in one process, which I don't see being a permanently viable
assumption.
Would it make sense to hack in a return value from the controller
function? Something like:
{return_with_meta,[{title,"Foo"},{link_rel,"next",link_to_page_2()}],
[{data,"foo"},
{ewc,...}]}
(with a better name, since "return_with_meta" doesn't sound all that
great to me). But then I'm not sure how one could extract that from
the rendered view. Maybe pass only the second tuple-item to the view,
and pass both the first item and the second to the controller. Many
many questions. I'll have to think about it some more.
> Btw, just curious, what parts of ErlyWeb are you rewriting?
Mostly large swaths of erlydb and erlydb_mnesia (in ways that make it
work better with mnesia, but that make it incompatible with other
DBMSs, which of course the current incarnation avoids). I may end up
having to revert this if mnesia can't handle millions of objects,
with which it seems to be having trouble once they start to become
larger objects than simple tuples. I've hacked in a few return and
'EXIT' handlers from controller functions for special circumstances,
like when I want to return a 400- or 500-level HTTP response along
with other information. I might try to hack in some WebDAV handling
stuff, as I'm considering writing a desktop client for my app in the
future and that seems the easiest way to get the data to and from the
desktop client. I haven't decided what that's going to look like yet.
It looks like I may be hacking in a return value to return extended
information to parent controller functions, like <title> tags. but I
want to decide how it should work, first. It sounds like it's just
not a concern to the two biggest users of erlyweb
>
> Yariv
>
> On Nov 16, 2007 10:19 AM, David King <[EMAIL PROTECTED]> wrote:
>>
>> erlyweb uses a component system for rendering pages. It makes most of
>> my controller functions return lists like this:
>>
>> [{data,post:title(Post)},
>> {ewc,post,contents,[A,Post]},
>> {ewc,comment,comments,[A,post:comments(Post)]}]
>>
>> The view function then looks like:
>>
>> <%@ show([Title,Contents,Comments]) %>
>> <h1><% Title %></h1>
>> <div class="post_contents"><% Contents %></div>
>> <ul class="comments><% Comments %></ul>
>>
>> I really like this, because it allows me to separate the view-logic
>> for things like contents and comments out from each other, which
>> makes changing the behaviour of these quite simple, localised, and
>> re-
>> useable. (In fact, as I re-write portions of erlyweb for my purposes,
>> the component system is something that I haven't touched at all
>> because it works quite well.) However, it has an inherent limitation:
>> none of those functions can return data to be rendered outside of
>> their components. In my case, I'd like to be able to set <title>
>> tags, which means that the top-level controller function (by top-
>> level, I mean the one referenced in the URL; like in /post/show/12,
>> the top-level controller function would be show/2) needs to somehow
>> return information to be rendered outside its little sandbox.
>>
>> I see that Vimagi doesn't set <title> tags (neither <http://
>> vimagi.com/p/0PXmMRe6hGV> nor <http://vimagi.com/users/feeling3_4>
>> set one, at least, and those are where I'd expect to see them), but
>> BeerRiot does (<http://beerriot.com/beer/view/1751>; BTW I do love
>> the idea of having a controller called "beer_controller").
>>
>> It isn't limited to <title>s (for instance, I may want to alert the
>> browser that an RSS equivalent of this page exists, or what the
>> caching TTL is for this page in the HTTP headers). Conceptually, how
>> would one go about returning this extra information, while still
>> using the component system (I now have a lot of code that uses it
>> that I'd like to not re-write :) )?
>>
>>
>>
>>>
>>
>
>
--~--~---------~--~----~------------~-------~--~----~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/erlyweb?hl=en
-~----------~----~----~----~------~----~------~--~---