Account Options

  1. Sign in
The old Google Groups will be going away soon.
Switch to the new Google Groups.
Google Groups Home
« Groups Home
erlyweb
Home
About this group
Apply for group membership
Message from discussion <title>s and other non-component data
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
David King  
View profile  
 More options Nov 16 2007, 6:24 pm
From: David King <dk...@ketralnis.com>
Date: Fri, 16 Nov 2007 15:24:15 -0800
Local: Fri, Nov 16 2007 6:24 pm
Subject: Re: [erlyweb-list] Re: <title>s and other non-component data
Print | View thread | Show original | Report this message | Find messages by this author

> - 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 <dk...@ketralnis.com> 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 must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2012 Google