| Author |
Message |
< Erlyweb mailing list ~ s and other non-component data</h2></td>
</tr>
<tr>
<td class="row3 one"><a id="34338"></a>ketralnis</td>
<td class="row3 two">
<table cellspacing="0">
<tr>
<td><a href="viewtopic.php?p=34338&sid=6ad65ce0d8e7e5873bcd5525cbbcee49#34338"><img src="templates/TrapExit/images/icon_minipost.gif" style="width: 12px; height: 9px; border: 0;" alt="" /></a>Posted: Fri Nov 16, 2007 9:07 pm</td>
<td class="txtright"><a href="posting.php?mode=quote&p=34338&sid=6ad65ce0d8e7e5873bcd5525cbbcee49"><img src="templates/TrapExit/images/lang_english/icon_quote.gif" alt="Reply with quote" title="Reply with quote" border="0" /></a> </td>
</tr>
</table>
</td>
</tr>
<tr>
<td class="row1 three">
<span class="avatar"></span>
<span class="block">User</span>
<span class="block"></span>
<span class="block">Joined: 20 Jul 2007</span>
<span class="block">Posts: 151</span>
<span class="block">Location: San Francisco, CA</span>
</td>
<td class="row1 four">
<table cellspacing="0">
<tr>
<td class="txttop">erlyweb uses a component system for rendering pages. It makes most of
<br />
my controller functions return lists like this:
<br />
<br />
[{data,post:title(Post)},
<br />
{ewc,post,contents,[A,Post]},
<br />
{ewc,comment,comments,[A,post:comments(Post)]}]
<br />
<br />
The view function then looks like:
<br />
<br />
<%@ show([Title,Contents,Comments]) %>
<br />
<h1><% Title %></h1>
<br />
<div class="post_contents"><% Contents %></div>
<br />
<ul class="comments><% Comments %></ul>
<br />
<br />
I really like this, because it allows me to separate the view-logic
<br />
for things like contents and comments out from each other, which
<br />
makes changing the behaviour of these quite simple, localised, and re-
<br />
useable. (In fact, as I re-write portions of erlyweb for my purposes,
<br />
the component system is something that I haven't touched at all
<br />
because it works quite well.) However, it has an inherent limitation:
<br />
none of those functions can return data to be rendered outside of
<br />
their components. In my case, I'd like to be able to set <title>
<br />
tags, which means that the top-level controller function (by top-
<br />
level, I mean the one referenced in the URL; like in /post/show/12,
<br />
the top-level controller function would be show/2) needs to somehow
<br />
return information to be rendered outside its little sandbox.
<br />
<br />
I see that Vimagi doesn't set <title> tags (neither <http://
<br />
vimagi.com/p/0PXmMRe6hGV> nor <http://vimagi.com/users/feeling3_4>
<br />
set one, at least, and those are where I'd expect to see them), but
<br />
BeerRiot does (<http://beerriot.com/beer/view/1751>; BTW I do love
<br />
the idea of having a controller called "beer_controller").
<br />
<br />
It isn't limited to <title>s (for instance, I may want to alert the
<br />
browser that an RSS equivalent of this page exists, or what the
<br />
caching TTL is for this page in the HTTP headers). Conceptually, how
<br />
would one go about returning this extra information, while still
<br />
using the component system (I now have a lot of code that uses it
<br />
that I'd like to not re-write <img src="images/smiles/icon_smile.gif" alt="Smile" border="0" /> )?
<br />
<br />
<br />
<br />
--~--~---------~--~----~------------~-------~--~----~
<br />
You received this message because you are subscribed to the Google Groups "erlyweb" group.
<br />
To post to this group, send email to <a href="mailto:erlyweb@googlegroups.com">erlyweb@googlegroups.com</a>
<br />
To unsubscribe from this group, send email to <a href="mailto:erlyweb-unsubscribe@googlegroups.com">erlyweb-unsubscribe@googlegroups.com</a>
<br />
For more options, visit this group at <a href="http://groups.google.com/group/erlyweb?hl=en" target="_blank">http://groups.google.com/group/erlyweb?hl=en</a>
<br />
-~----------~----~----~----~------~----~------~--~---
<br />
<br />
Post recived from mailinglist</td>
</tr>
<tr>
<td class="txtbottom"><span class="edited"></span></td>
</tr>
</table>
</td>
</tr>
<tr>
<td class="row1 five blacklink"><a href="#top">Back to top</a></td>
<td class="row1 six">
<a href="profile.php?mode=viewprofile&u=1210&sid=6ad65ce0d8e7e5873bcd5525cbbcee49"><img src="templates/TrapExit/images/lang_english/icon_profile.gif" alt="View user's profile" title="View user's profile" border="0" /></a> <a href="privmsg.php?mode=post&u=1210&sid=6ad65ce0d8e7e5873bcd5525cbbcee49"><img src="templates/TrapExit/images/lang_english/icon_pm.gif" alt="Send private message" title="Send private message" border="0" /></a> <a href="aim:goim?screenname=Ketralnis&message=Hello+Are+you+there?"><img src="templates/TrapExit/images/lang_english/icon_aim.gif" alt="AIM Address" title="AIM Address" border="0" /></a>
</td>
</tr>
<tr>
<td class="row3 one"><a id="34347"></a>Guest</td>
<td class="row3 two">
<table cellspacing="0">
<tr>
<td><a href="viewtopic.php?p=34347&sid=6ad65ce0d8e7e5873bcd5525cbbcee49#34347"><img src="templates/TrapExit/images/icon_minipost.gif" style="width: 12px; height: 9px; border: 0;" alt="" /></a>Posted: Fri Nov 16, 2007 10:30 pm</td>
<td class="txtright"><a href="posting.php?mode=quote&p=34347&sid=6ad65ce0d8e7e5873bcd5525cbbcee49"><img src="templates/TrapExit/images/lang_english/icon_quote.gif" alt="Reply with quote" title="Reply with quote" border="0" /></a> </td>
</tr>
</table>
</td>
</tr>
<tr>
<td class="row2 three">
<span class="avatar"></span>
<span class="block">Guest</span>
<span class="block"></span>
<span class="block"></span>
<span class="block"></span>
<span class="block"></span>
</td>
<td class="row2 four">
<table cellspacing="0">
<tr>
<td class="txttop">Hi David,
<br />
<br />
There are a couple of things I can suggest.
<br />
<br />
- A while ago somebody asked a similar question and Bryan Fink
<br />
suggested returning a tuple of the form {title, Title} from the view
<br />
function, and then later picking up this tuple in the
<br />
html_container_controller and using its value to set the <title> tag.
<br />
<br />
- Use the process dictionary to store any values that need to be used
<br />
later outside the current component.
<br />
<br />
Let me know if it works for you.
<br />
<br />
Btw, just curious, what parts of ErlyWeb are you rewriting?
<br />
<br />
Yariv
<br />
<br />
On Nov 16, 2007 10:19 AM, David King <dking@ketralnis.com> wrote:
<br />
>
<br />
> erlyweb uses a component system for rendering pages. It makes most of
<br />
> my controller functions return lists like this:
<br />
>
<br />
> [{data,post:title(Post)},
<br />
> {ewc,post,contents,[A,Post]},
<br />
> {ewc,comment,comments,[A,post:comments(Post)]}]
<br />
>
<br />
> The view function then looks like:
<br />
>
<br />
> <%@ show([Title,Contents,Comments]) %>
<br />
> <h1><% Title %></h1>
<br />
> <div class="post_contents"><% Contents %></div>
<br />
> <ul class="comments><% Comments %></ul>
<br />
>
<br />
> I really like this, because it allows me to separate the view-logic
<br />
> for things like contents and comments out from each other, which
<br />
> makes changing the behaviour of these quite simple, localised, and re-
<br />
> useable. (In fact, as I re-write portions of erlyweb for my purposes,
<br />
> the component system is something that I haven't touched at all
<br />
> because it works quite well.) However, it has an inherent limitation:
<br />
> none of those functions can return data to be rendered outside of
<br />
> their components. In my case, I'd like to be able to set <title>
<br />
> tags, which means that the top-level controller function (by top-
<br />
> level, I mean the one referenced in the URL; like in /post/show/12,
<br />
> the top-level controller function would be show/2) needs to somehow
<br />
> return information to be rendered outside its little sandbox.
<br />
>
<br />
> I see that Vimagi doesn't set <title> tags (neither <http://
<br />
> vimagi.com/p/0PXmMRe6hGV> nor <http://vimagi.com/users/feeling3_4>
<br />
> set one, at least, and those are where I'd expect to see them), but
<br />
> BeerRiot does (<http://beerriot.com/beer/view/1751>; BTW I do love
<br />
> the idea of having a controller called "beer_controller").
<br />
>
<br />
> It isn't limited to <title>s (for instance, I may want to alert the
<br />
> browser that an RSS equivalent of this page exists, or what the
<br />
> caching TTL is for this page in the HTTP headers). Conceptually, how
<br />
> would one go about returning this extra information, while still
<br />
> using the component system (I now have a lot of code that uses it
<br />
> that I'd like to not re-write <img src="images/smiles/icon_smile.gif" alt="Smile" border="0" /> )?
<br />
>
<br />
>
<br />
>
<br />
> >
<br />
>
<br />
<br />
--~--~---------~--~----~------------~-------~--~----~
<br />
You received this message because you are subscribed to the Google Groups "erlyweb" group.
<br />
To post to this group, send email to <a href="mailto:erlyweb@googlegroups.com">erlyweb@googlegroups.com</a>
<br />
To unsubscribe from this group, send email to <a href="mailto:erlyweb-unsubscribe@googlegroups.com">erlyweb-unsubscribe@googlegroups.com</a>
<br />
For more options, visit this group at <a href="http://groups.google.com/group/erlyweb?hl=en" target="_blank">http://groups.google.com/group/erlyweb?hl=en</a>
<br />
-~----------~----~----~----~------~----~------~--~---
<br />
<br />
Post recived from mailinglist</td>
</tr>
<tr>
<td class="txtbottom"><span class="edited"></span></td>
</tr>
</table>
</td>
</tr>
<tr>
<td class="row2 five blacklink"><a href="#top">Back to top</a></td>
<td class="row2 six">
</td>
</tr>
<tr>
<td class="row3 one"><a id="34352"></a>ketralnis</td>
<td class="row3 two">
<table cellspacing="0">
<tr>
<td><a href="viewtopic.php?p=34352&sid=6ad65ce0d8e7e5873bcd5525cbbcee49#34352"><img src="templates/TrapExit/images/icon_minipost.gif" style="width: 12px; height: 9px; border: 0;" alt="" /></a>Posted: Fri Nov 16, 2007 11:25 pm</td>
<td class="txtright"><a href="posting.php?mode=quote&p=34352&sid=6ad65ce0d8e7e5873bcd5525cbbcee49"><img src="templates/TrapExit/images/lang_english/icon_quote.gif" alt="Reply with quote" title="Reply with quote" border="0" /></a> </td>
</tr>
</table>
</td>
</tr>
<tr>
<td class="row1 three">
<span class="avatar"></span>
<span class="block">User</span>
<span class="block"></span>
<span class="block">Joined: 20 Jul 2007</span>
<span class="block">Posts: 151</span>
<span class="block">Location: San Francisco, CA</span>
</td>
<td class="row1 four">
<table cellspacing="0">
<tr>
<td class="txttop">> - A while ago somebody asked a similar question and Bryan Fink
<br />
> suggested returning a tuple of the form {title, Title} from the view
<br />
> function, and then later picking up this tuple in the
<br />
> html_container_controller and using its value to set the <title> tag.
<br />
<br />
That does only take into account <title>s, and not any other
<br />
metadata. And doesn't using erltl preclude returning something useful
<br />
from a view function other than the data itself? And then the
<br />
component receiving the rendered page would have to walk the
<br />
resultant IOlist looking for it, rather than being able to pattern-
<br />
match it. That just seems very brittle. I guess I could have one view
<br />
function like
<br />
<br />
contents([Title,[Contents,AuthorName]]) ->
<br />
[[{title,Title},
<br />
{other_metadata,etc}],
<br />
post_view_erltl:contents([Contents,AuthorName])].
<br />
<br />
And then another module with the erltl itself, but that also seems
<br />
rather contrived. Maybe it makes sense to have a list in the
<br />
html_container of controllers:functions that require meta-data and
<br />
know to call them and ask for the <title>, but that also seems
<br />
brittle as the controllers:functions change.
<br />
<br />
> - Use the process dictionary to store any values that need to be used
<br />
> later outside the current component.
<br />
<br />
Ech, that sounds terrible, and it relies on Erlyweb doing all of the
<br />
work in one process, which I don't see being a permanently viable
<br />
assumption.
<br />
<br />
Would it make sense to hack in a return value from the controller
<br />
function? Something like:
<br />
<br />
{return_with_meta,[{title,"Foo"},{link_rel,"next",link_to_page_2()}],
<br />
[{data,"foo"},
<br />
{ewc,...}]}
<br />
<br />
(with a better name, since "return_with_meta" doesn't sound all that
<br />
great to me). But then I'm not sure how one could extract that from
<br />
the rendered view. Maybe pass only the second tuple-item to the view,
<br />
and pass both the first item and the second to the controller. Many
<br />
many questions. I'll have to think about it some more.
<br />
<br />
> Btw, just curious, what parts of ErlyWeb are you rewriting?
<br />
<br />
Mostly large swaths of erlydb and erlydb_mnesia (in ways that make it
<br />
work better with mnesia, but that make it incompatible with other
<br />
DBMSs, which of course the current incarnation avoids). I may end up
<br />
having to revert this if mnesia can't handle millions of objects,
<br />
with which it seems to be having trouble once they start to become
<br />
larger objects than simple tuples. I've hacked in a few return and
<br />
'EXIT' handlers from controller functions for special circumstances,
<br />
like when I want to return a 400- or 500-level HTTP response along
<br />
with other information. I might try to hack in some WebDAV handling
<br />
stuff, as I'm considering writing a desktop client for my app in the
<br />
future and that seems the easiest way to get the data to and from the
<br />
desktop client. I haven't decided what that's going to look like yet.
<br />
It looks like I may be hacking in a return value to return extended
<br />
information to parent controller functions, like <title> tags. but I
<br />
want to decide how it should work, first. It sounds like it's just
<br />
not a concern to the two biggest users of erlyweb
<br />
<br />
>
<br />
> Yariv
<br />
>
<br />
> On Nov 16, 2007 10:19 AM, David King <dking@ketralnis.com> wrote:
<br />
>>
<br />
>> erlyweb uses a component system for rendering pages. It makes most of
<br />
>> my controller functions return lists like this:
<br />
>>
<br />
>> [{data,post:title(Post)},
<br />
>> {ewc,post,contents,[A,Post]},
<br />
>> {ewc,comment,comments,[A,post:comments(Post)]}]
<br />
>>
<br />
>> The view function then looks like:
<br />
>>
<br />
>> <%@ show([Title,Contents,Comments]) %>
<br />
>> <h1><% Title %></h1>
<br />
>> <div class="post_contents"><% Contents %></div>
<br />
>> <ul class="comments><% Comments %></ul>
<br />
>>
<br />
>> I really like this, because it allows me to separate the view-logic
<br />
>> for things like contents and comments out from each other, which
<br />
>> makes changing the behaviour of these quite simple, localised, and
<br />
>> re-
<br />
>> useable. (In fact, as I re-write portions of erlyweb for my purposes,
<br />
>> the component system is something that I haven't touched at all
<br />
>> because it works quite well.) However, it has an inherent limitation:
<br />
>> none of those functions can return data to be rendered outside of
<br />
>> their components. In my case, I'd like to be able to set <title>
<br />
>> tags, which means that the top-level controller function (by top-
<br />
>> level, I mean the one referenced in the URL; like in /post/show/12,
<br />
>> the top-level controller function would be show/2) needs to somehow
<br />
>> return information to be rendered outside its little sandbox.
<br />
>>
<br />
>> I see that Vimagi doesn't set <title> tags (neither <http://
<br />
>> vimagi.com/p/0PXmMRe6hGV> nor <http://vimagi.com/users/feeling3_4>
<br />
>> set one, at least, and those are where I'd expect to see them), but
<br />
>> BeerRiot does (<http://beerriot.com/beer/view/1751>; BTW I do love
<br />
>> the idea of having a controller called "beer_controller").
<br />
>>
<br />
>> It isn't limited to <title>s (for instance, I may want to alert the
<br />
>> browser that an RSS equivalent of this page exists, or what the
<br />
>> caching TTL is for this page in the HTTP headers). Conceptually, how
<br />
>> would one go about returning this extra information, while still
<br />
>> using the component system (I now have a lot of code that uses it
<br />
>> that I'd like to not re-write <img src="images/smiles/icon_smile.gif" alt="Smile" border="0" /> )?
<br />
>>
<br />
>>
<br />
>>
<br />
>>>
<br />
>>
<br />
>
<br />
>
<br />
<br />
--~--~---------~--~----~------------~-------~--~----~
<br />
You received this message because you are subscribed to the Google Groups "erlyweb" group.
<br />
To post to this group, send email to <a href="mailto:erlyweb@googlegroups.com">erlyweb@googlegroups.com</a>
<br />
To unsubscribe from this group, send email to <a href="mailto:erlyweb-unsubscribe@googlegroups.com">erlyweb-unsubscribe@googlegroups.com</a>
<br />
For more options, visit this group at <a href="http://groups.google.com/group/erlyweb?hl=en" target="_blank">http://groups.google.com/group/erlyweb?hl=en</a>
<br />
-~----------~----~----~----~------~----~------~--~---
<br />
<br />
Post recived from mailinglist</td>
</tr>
<tr>
<td class="txtbottom"><span class="edited"></span></td>
</tr>
</table>
</td>
</tr>
<tr>
<td class="row1 five blacklink"><a href="#top">Back to top</a></td>
<td class="row1 six">
<a href="profile.php?mode=viewprofile&u=1210&sid=6ad65ce0d8e7e5873bcd5525cbbcee49"><img src="templates/TrapExit/images/lang_english/icon_profile.gif" alt="View user's profile" title="View user's profile" border="0" /></a> <a href="privmsg.php?mode=post&u=1210&sid=6ad65ce0d8e7e5873bcd5525cbbcee49"><img src="templates/TrapExit/images/lang_english/icon_pm.gif" alt="Send private message" title="Send private message" border="0" /></a> <a href="aim:goim?screenname=Ketralnis&message=Hello+Are+you+there?"><img src="templates/TrapExit/images/lang_english/icon_aim.gif" alt="AIM Address" title="AIM Address" border="0" /></a>
</td>
</tr>
<tr>
<td class="row3 one"><a id="34354"></a>Guest</td>
<td class="row3 two">
<table cellspacing="0">
<tr>
<td><a href="viewtopic.php?p=34354&sid=6ad65ce0d8e7e5873bcd5525cbbcee49#34354"><img src="templates/TrapExit/images/icon_minipost.gif" style="width: 12px; height: 9px; border: 0;" alt="" /></a>Posted: Sat Nov 17, 2007 12:19 am</td>
<td class="txtright"><a href="posting.php?mode=quote&p=34354&sid=6ad65ce0d8e7e5873bcd5525cbbcee49"><img src="templates/TrapExit/images/lang_english/icon_quote.gif" alt="Reply with quote" title="Reply with quote" border="0" /></a> </td>
</tr>
</table>
</td>
</tr>
<tr>
<td class="row2 three">
<span class="avatar"></span>
<span class="block">Guest</span>
<span class="block"></span>
<span class="block"></span>
<span class="block"></span>
<span class="block"></span>
</td>
<td class="row2 four">
<table cellspacing="0">
<tr>
<td class="txttop">On Nov 16, 2007 3:24 PM, David King <dking@ketralnis.com> wrote:
<br />
>
<br />
> > - A while ago somebody asked a similar question and Bryan Fink
<br />
> > suggested returning a tuple of the form {title, Title} from the view
<br />
> > function, and then later picking up this tuple in the
<br />
> > html_container_controller and using its value to set the <title> tag.
<br />
>
<br />
> That does only take into account <title>s, and not any other
<br />
> metadata. And doesn't using erltl preclude returning something useful
<br />
> from a view function other than the data itself? And then the
<br />
> component receiving the rendered page would have to walk the
<br />
> resultant IOlist looking for it, rather than being able to pattern-
<br />
> match it. That just seems very brittle. I guess I could have one view
<br />
> function like
<br />
>
<br />
> contents([Title,[Contents,AuthorName]]) ->
<br />
> [[{title,Title},
<br />
> {other_metadata,etc}],
<br />
> post_view_erltl:contents([Contents,AuthorName])].
<br />
>
<br />
> And then another module with the erltl itself, but that also seems
<br />
> rather contrived. Maybe it makes sense to have a list in the
<br />
> html_container of controllers:functions that require meta-data and
<br />
> know to call them and ask for the <title>, but that also seems
<br />
> brittle as the controllers:functions change.
<br />
>
<br />
> > - Use the process dictionary to store any values that need to be used
<br />
> > later outside the current component.
<br />
>
<br />
> Ech, that sounds terrible, and it relies on Erlyweb doing all of the
<br />
> work in one process, which I don't see being a permanently viable
<br />
> assumption.
<br />
>
<br />
> Would it make sense to hack in a return value from the controller
<br />
> function? Something like:
<br />
>
<br />
> {return_with_meta,[{title,"Foo"},{link_rel,"next",link_to_page_2()}],
<br />
> [{data,"foo"},
<br />
> {ewc,...}]}
<br />
>
<br />
> (with a better name, since "return_with_meta" doesn't sound all that
<br />
> great to me). But then I'm not sure how one could extract that from
<br />
> the rendered view. Maybe pass only the second tuple-item to the view,
<br />
> and pass both the first item and the second to the controller. Many
<br />
> many questions. I'll have to think about it some more.
<br />
<br />
I think that's a very good idea. There may be issues if multiple
<br />
subcomponents return the same metadata (or at least the same keys),
<br />
but then I guess ErlyWeb will just pick the first one. There are also
<br />
questions regarding how the metadata will be passed around (should it
<br />
be passed to a components siblings and or only its parents?) -- I'll
<br />
have to think about it and make sure all the bases are covered.
<br />
<br />
>
<br />
> > Btw, just curious, what parts of ErlyWeb are you rewriting?
<br />
>
<br />
> Mostly large swaths of erlydb and erlydb_mnesia (in ways that make it
<br />
> work better with mnesia, but that make it incompatible with other
<br />
> DBMSs, which of course the current incarnation avoids). I may end up
<br />
> having to revert this if mnesia can't handle millions of objects,
<br />
> with which it seems to be having trouble once they start to become
<br />
> larger objects than simple tuples. I've hacked in a few return and
<br />
> 'EXIT' handlers from controller functions for special circumstances,
<br />
> like when I want to return a 400- or 500-level HTTP response along
<br />
> with other information. I might try to hack in some WebDAV handling
<br />
> stuff, as I'm considering writing a desktop client for my app in the
<br />
> future and that seems the easiest way to get the data to and from the
<br />
> desktop client. I haven't decided what that's going to look like yet.
<br />
> It looks like I may be hacking in a return value to return extended
<br />
> information to parent controller functions, like <title> tags. but I
<br />
> want to decide how it should work, first. It sounds like it's just
<br />
> not a concern to the two biggest users of erlyweb
<br />
<br />
If you want to contribute this feature (or any other feature that you
<br />
think will be useful to other ErlyWeb users) I'll be happy to accept
<br />
your code.
<br />
<br />
Yariv
<br />
<br />
>
<br />
>
<br />
> >
<br />
> > Yariv
<br />
> >
<br />
> > On Nov 16, 2007 10:19 AM, David King <dking@ketralnis.com> wrote:
<br />
> >>
<br />
> >> erlyweb uses a component system for rendering pages. It makes most of
<br />
> >> my controller functions return lists like this:
<br />
> >>
<br />
> >> [{data,post:title(Post)},
<br />
> >> {ewc,post,contents,[A,Post]},
<br />
> >> {ewc,comment,comments,[A,post:comments(Post)]}]
<br />
> >>
<br />
> >> The view function then looks like:
<br />
> >>
<br />
> >> <%@ show([Title,Contents,Comments]) %>
<br />
> >> <h1><% Title %></h1>
<br />
> >> <div class="post_contents"><% Contents %></div>
<br />
> >> <ul class="comments><% Comments %></ul>
<br />
> >>
<br />
> >> I really like this, because it allows me to separate the view-logic
<br />
> >> for things like contents and comments out from each other, which
<br />
> >> makes changing the behaviour of these quite simple, localised, and
<br />
> >> re-
<br />
> >> useable. (In fact, as I re-write portions of erlyweb for my purposes,
<br />
> >> the component system is something that I haven't touched at all
<br />
> >> because it works quite well.) However, it has an inherent limitation:
<br />
> >> none of those functions can return data to be rendered outside of
<br />
> >> their components. In my case, I'd like to be able to set <title>
<br />
> >> tags, which means that the top-level controller function (by top-
<br />
> >> level, I mean the one referenced in the URL; like in /post/show/12,
<br />
> >> the top-level controller function would be show/2) needs to somehow
<br />
> >> return information to be rendered outside its little sandbox.
<br />
> >>
<br />
> >> I see that Vimagi doesn't set <title> tags (neither <http://
<br />
> >> vimagi.com/p/0PXmMRe6hGV> nor <http://vimagi.com/users/feeling3_4>
<br />
> >> set one, at least, and those are where I'd expect to see them), but
<br />
> >> BeerRiot does (<http://beerriot.com/beer/view/1751>; BTW I do love
<br />
> >> the idea of having a controller called "beer_controller").
<br />
> >>
<br />
> >> It isn't limited to <title>s (for instance, I may want to alert the
<br />
> >> browser that an RSS equivalent of this page exists, or what the
<br />
> >> caching TTL is for this page in the HTTP headers). Conceptually, how
<br />
> >> would one go about returning this extra information, while still
<br />
> >> using the component system (I now have a lot of code that uses it
<br />
> >> that I'd like to not re-write <img src="images/smiles/icon_smile.gif" alt="Smile" border="0" /> )?
<br />
> >>
<br />
> >>
<br />
> >>
<br />
> >>>
<br />
> >>
<br />
> >
<br />
> >
<br />
>
<br />
> >
<br />
>
<br />
<br />
--~--~---------~--~----~------------~-------~--~----~
<br />
You received this message because you are subscribed to the Google Groups "erlyweb" group.
<br />
To post to this group, send email to <a href="mailto:erlyweb@googlegroups.com">erlyweb@googlegroups.com</a>
<br />
To unsubscribe from this group, send email to <a href="mailto:erlyweb-unsubscribe@googlegroups.com">erlyweb-unsubscribe@googlegroups.com</a>
<br />
For more options, visit this group at <a href="http://groups.google.com/group/erlyweb?hl=en" target="_blank">http://groups.google.com/group/erlyweb?hl=en</a>
<br />
-~----------~----~----~----~------~----~------~--~---
<br />
<br />
Post recived from mailinglist</td>
</tr>
<tr>
<td class="txtbottom"><span class="edited"></span></td>
</tr>
</table>
</td>
</tr>
<tr>
<td class="row2 five blacklink"><a href="#top">Back to top</a></td>
<td class="row2 six">
</td>
</tr>
<tr>
<td class="row3 one"><a id="34364"></a>ketralnis</td>
<td class="row3 two">
<table cellspacing="0">
<tr>
<td><a href="viewtopic.php?p=34364&sid=6ad65ce0d8e7e5873bcd5525cbbcee49#34364"><img src="templates/TrapExit/images/icon_minipost.gif" style="width: 12px; height: 9px; border: 0;" alt="" /></a>Posted: Sat Nov 17, 2007 3:19 am</td>
<td class="txtright"><a href="posting.php?mode=quote&p=34364&sid=6ad65ce0d8e7e5873bcd5525cbbcee49"><img src="templates/TrapExit/images/lang_english/icon_quote.gif" alt="Reply with quote" title="Reply with quote" border="0" /></a> </td>
</tr>
</table>
</td>
</tr>
<tr>
<td class="row1 three">
<span class="avatar"></span>
<span class="block">User</span>
<span class="block"></span>
<span class="block">Joined: 20 Jul 2007</span>
<span class="block">Posts: 151</span>
<span class="block">Location: San Francisco, CA</span>
</td>
<td class="row1 four">
<table cellspacing="0">
<tr>
<td class="txttop">>> Would it make sense to hack in a return value from the controller
<br />
>> function? Something like:
<br />
>> {return_with_meta,[{title,"Foo"},{link_rel,"next",link_to_page_2()}],
<br />
>> [{data,"foo"},
<br />
>> {ewc,...}]}
<br />
>> (with a better name, since "return_with_meta" doesn't sound all that
<br />
>> great to me). But then I'm not sure how one could extract that from
<br />
>> the rendered view. Maybe pass only the second tuple-item to the view,
<br />
>> and pass both the first item and the second to the controller. Many
<br />
>> many questions. I'll have to think about it some more.
<br />
> I think that's a very good idea. There may be issues if multiple
<br />
> subcomponents return the same metadata (or at least the same keys),
<br />
> but then I guess ErlyWeb will just pick the first one. There are also
<br />
> questions regarding how the metadata will be passed around (should it
<br />
> be passed to a components siblings and or only its parents?) -- I'll
<br />
> have to think about it and make sure all the bases are covered.
<br />
<br />
I really like the component system, so I'd definitely like to get
<br />
your feedback on my ideas since it's already going in a good direction.
<br />
<br />
I wouldn't expect the siblings to be guaranteed to receive it (since
<br />
clearly you can't guarantee that they all do, since some may have
<br />
already been evaluated, or may be being evaluated at the same time),
<br />
but I wouldn't expect them to be guaranteed to *not* receive it.
<br />
<br />
Since the yaws_arg is being re-vamped anyway, maybe this should be
<br />
carried around on the yaws_arg. A simple plist is probably fine for
<br />
it. Then as the yaws_arg is returned changed it can be passed through
<br />
changed. Then make all subcomponents pass the yaws_arg implicitly: so
<br />
instead of {ewc,controller,func,[A,Foo]} calling func(A,Foo), make
<br />
{ewc,controller,func,[Foo]]} call fun(A,Foo). That way you're not
<br />
passing a stale yaws_arg accidentally. This is of course a backwards-
<br />
breaking change, but not a difficult one to fix, since all of the
<br />
erlyweb code that I've seen and written passes it to the sub-
<br />
components anyway (even if it's not necessarily used).
<br />
<br />
Otherwise, you end up all of the components doing something like this:
<br />
<br />
show(A,Foo)
<br />
NewA=yaws_arg:add_meta(A,[{title,get_the_title()}]),
<br />
<br />
{return_with_meta,[{ewc,func,[NewA,Foo]}],
<br />
NewA}.
<br />
<br />
(once again, with better names than return_with_meta and add_meta)
<br />
The worry here is that the subcomponents have to be called with NewA
<br />
instead of A, which seems ripe for forgetting to me (especially if
<br />
the yaws_arg some some validation before it passes it on; you could
<br />
pass invalid data to sub-components this way).
<br />
<br />
I haven't looked at the contents of the yaws_arg, but if it's tagged
<br />
with a type, then you could just do this:
<br />
<br />
show(A,Foo)
<br />
[_New_yaws_arg=yaws_arg:add_property(A,[{title,get_the_title()}]),
<br />
{ewc,func,[Foo]}].
<br />
<br />
Since erlyweb already knows to check the returned list for {ewc} and
<br />
whatnot, it could just check for a new yaws_arg and start using that
<br />
one. The problem there is that it forces {ewc}s to be processed
<br />
serially (since what do you do when you get two conflicting
<br />
yaws_args?), which my erlyweb does not (and given your blog post on a
<br />
potential {concurrent,[{ewc,...}]}, I suspect this won't be a
<br />
guarantee forever). Another idea is to just add another return value
<br />
from controller functions:
<br />
<br />
show(A,Foo)
<br />
[{add_property,{title,get_the_title()}},
<br />
{add_property,{time_to_live,two_weeks()}}
<br />
{ewc,controller,func,[Foo]},
<br />
{ewc,controller,fun2,[yaws_arg:get_property(cookies)]].
<br />
<br />
(this was has my implicit-passing of yaws_args, but it's not
<br />
necessary; not doing so does preclude children retrieving properties
<br />
from parents, but if they need that they should pass it as an
<br />
argument anyway). That doesn't carry the assumption that they are
<br />
processed serially. It prevents parents from getting to children's
<br />
properties without using {phased,Ewcs,...}, but that's probably not a
<br />
problem, and isn't very avoidable. (I think all of these options do,
<br />
if they want to do post-processing of any kind).
<br />
<br />
Personally, I like the last option, but it looks like it would
<br />
require quite a few changes to the way that the erlyweb:ewc/N
<br />
functions work
<br />
<br />
Any other ideas? How does that last one look?
<br />
<br />
<br />
<br />
>>> Btw, just curious, what parts of ErlyWeb are you rewriting?
<br />
>> [...]
<br />
>> Mostly large swaths of erlydb and erlydb_mnesia (in ways that make it
<br />
>> work better with mnesia, but that make it incompatible with other
<br />
>> DBMSs, which of course the current incarnation avoids). I may end up
<br />
>> having to revert this if mnesia can't handle millions of objects,
<br />
>> with which it seems to be having trouble once they start to become
<br />
>> larger objects than simple tuples. I've hacked in a few return and
<br />
>> 'EXIT' handlers from controller functions for special circumstances,
<br />
>> like when I want to return a 400- or 500-level HTTP response along
<br />
>> with other information. I might try to hack in some WebDAV handling
<br />
>> stuff, as I'm considering writing a desktop client for my app in the
<br />
>> future and that seems the easiest way to get the data to and from the
<br />
>> desktop client. I haven't decided what that's going to look like yet.
<br />
>> It looks like I may be hacking in a return value to return extended
<br />
>> information to parent controller functions, like <title> tags. but I
<br />
>> want to decide how it should work, first. It sounds like it's just
<br />
>> not a concern to the two biggest users of erlyweb
<br />
>
<br />
> If you want to contribute this feature (or any other feature that you
<br />
> think will be useful to other ErlyWeb users) I'll be happy to accept
<br />
> your code.
<br />
>
<br />
> Yariv
<br />
>
<br />
>>
<br />
>>
<br />
>>>
<br />
>>> Yariv
<br />
>>>
<br />
>>> On Nov 16, 2007 10:19 AM, David King <dking@ketralnis.com> wrote:
<br />
>>>>
<br />
>>>> erlyweb uses a component system for rendering pages. It makes
<br />
>>>> most of
<br />
>>>> my controller functions return lists like this:
<br />
>>>>
<br />
>>>> [{data,post:title(Post)},
<br />
>>>> {ewc,post,contents,[A,Post]},
<br />
>>>> {ewc,comment,comments,[A,post:comments(Post)]}]
<br />
>>>>
<br />
>>>> The view function then looks like:
<br />
>>>>
<br />
>>>> <%@ show([Title,Contents,Comments]) %>
<br />
>>>> <h1><% Title %></h1>
<br />
>>>> <div class="post_contents"><% Contents %></div>
<br />
>>>> <ul class="comments><% Comments %></ul>
<br />
>>>>
<br />
>>>> I really like this, because it allows me to separate the view-logic
<br />
>>>> for things like contents and comments out from each other, which
<br />
>>>> makes changing the behaviour of these quite simple, localised, and
<br />
>>>> re-
<br />
>>>> useable. (In fact, as I re-write portions of erlyweb for my
<br />
>>>> purposes,
<br />
>>>> the component system is something that I haven't touched at all
<br />
>>>> because it works quite well.) However, it has an inherent
<br />
>>>> limitation:
<br />
>>>> none of those functions can return data to be rendered outside of
<br />
>>>> their components. In my case, I'd like to be able to set <title>
<br />
>>>> tags, which means that the top-level controller function (by top-
<br />
>>>> level, I mean the one referenced in the URL; like in /post/show/12,
<br />
>>>> the top-level controller function would be show/2) needs to somehow
<br />
>>>> return information to be rendered outside its little sandbox.
<br />
>>>>
<br />
>>>> I see that Vimagi doesn't set <title> tags (neither <http://
<br />
>>>> vimagi.com/p/0PXmMRe6hGV> nor <http://vimagi.com/users/feeling3_4>
<br />
>>>> set one, at least, and those are where I'd expect to see them), but
<br />
>>>> BeerRiot does (<http://beerriot.com/beer/view/1751>; BTW I do love
<br />
>>>> the idea of having a controller called "beer_controller").
<br />
>>>>
<br />
>>>> It isn't limited to <title>s (for instance, I may want to alert the
<br />
>>>> browser that an RSS equivalent of this page exists, or what the
<br />
>>>> caching TTL is for this page in the HTTP headers). Conceptually,
<br />
>>>> how
<br />
>>>> would one go about returning this extra information, while still
<br />
>>>> using the component system (I now have a lot of code that uses it
<br />
>>>> that I'd like to not re-write <img src="images/smiles/icon_smile.gif" alt="Smile" border="0" /> )?
<br />
>>>>
<br />
>>>>
<br />
>>>>
<br />
>>>>>
<br />
>>>>
<br />
>>>
<br />
>>>
<br />
>>
<br />
>>>
<br />
>>
<br />
>
<br />
>
<br />
<br />
--~--~---------~--~----~------------~-------~--~----~
<br />
You received this message because you are subscribed to the Google Groups "erlyweb" group.
<br />
To post to this group, send email to <a href="mailto:erlyweb@googlegroups.com">erlyweb@googlegroups.com</a>
<br />
To unsubscribe from this group, send email to <a href="mailto:erlyweb-unsubscribe@googlegroups.com">erlyweb-unsubscribe@googlegroups.com</a>
<br />
For more options, visit this group at <a href="http://groups.google.com/group/erlyweb?hl=en" target="_blank">http://groups.google.com/group/erlyweb?hl=en</a>
<br />
-~----------~----~----~----~------~----~------~--~---
<br />
<br />
Post recived from mailinglist</td>
</tr>
<tr>
<td class="txtbottom"><span class="edited"></span></td>
</tr>
</table>
</td>
</tr>
<tr>
<td class="row1 five blacklink"><a href="#top">Back to top</a></td>
<td class="row1 six">
<a href="profile.php?mode=viewprofile&u=1210&sid=6ad65ce0d8e7e5873bcd5525cbbcee49"><img src="templates/TrapExit/images/lang_english/icon_profile.gif" alt="View user's profile" title="View user's profile" border="0" /></a> <a href="privmsg.php?mode=post&u=1210&sid=6ad65ce0d8e7e5873bcd5525cbbcee49"><img src="templates/TrapExit/images/lang_english/icon_pm.gif" alt="Send private message" title="Send private message" border="0" /></a> <a href="aim:goim?screenname=Ketralnis&message=Hello+Are+you+there?"><img src="templates/TrapExit/images/lang_english/icon_aim.gif" alt="AIM Address" title="AIM Address" border="0" /></a>
</td>
</tr>
<tr>
<td class="row3 one"><a id="34391"></a>Guest</td>
<td class="row3 two">
<table cellspacing="0">
<tr>
<td><a href="viewtopic.php?p=34391&sid=6ad65ce0d8e7e5873bcd5525cbbcee49#34391"><img src="templates/TrapExit/images/icon_minipost.gif" style="width: 12px; height: 9px; border: 0;" alt="" /></a>Posted: Sun Nov 18, 2007 12:50 am</td>
<td class="txtright"><a href="posting.php?mode=quote&p=34391&sid=6ad65ce0d8e7e5873bcd5525cbbcee49"><img src="templates/TrapExit/images/lang_english/icon_quote.gif" alt="Reply with quote" title="Reply with quote" border="0" /></a> </td>
</tr>
</table>
</td>
</tr>
<tr>
<td class="row2 three">
<span class="avatar"></span>
<span class="block">Guest</span>
<span class="block"></span>
<span class="block"></span>
<span class="block"></span>
<span class="block"></span>
</td>
<td class="row2 four">
<table cellspacing="0">
<tr>
<td class="txttop">Thanks, David. Interesting thoughts. After thinking about the problem
<br />
more, I'm not sure that I would like to propagate changes to the arg
<br />
up the chain. It feels like we'd be overloading the arg for purposes
<br />
it wasn't designed to have. Plus, if we let subcomponents change the
<br />
arg, it would make debugging more difficult. (Imagine that component A
<br />
works if you test it independently, but then it breaks if you render
<br />
component B before A.) This feels imperative to me -- like having
<br />
global mutable state. I prefer subcomponents side-effect free. I also
<br />
like thinking of the components relationships as a tree where the
<br />
parents control the children and not vice versa.
<br />
<br />
I think that the best solution is to add a new return value, e.g.
<br />
{meta, Val}, to controller functions. ErlyWeb will accumulate those
<br />
values in a list and pass it to the 'phased' Fun as an extra
<br />
parameter. So, you could write
<br />
<br />
{phased, {ewc, A},
<br />
fun(ExpandedEwc, MetaVals, Rendered) ->
<br />
{ewc, html_container, [A, MetaVals, Rendered]}
<br />
end}.
<br />
<br />
This would simplify setting the Title, Header, etc from the
<br />
controllers without using Bryan's clever ErlTL tricks (which may be
<br />
less-than-intuitive for some people <img src="images/smiles/icon_smile.gif" alt="Smile" border="0" /> ), add too much magic to the
<br />
framework, or even changing it much. It would also work trivially even
<br />
when subcomponents are rendered in parallel because this is
<br />
effectively a side-effect-free accumulator.
<br />
<br />
What do you think?
<br />
<br />
Yariv
<br />
<br />
<br />
>
<br />
> I really like the component system, so I'd definitely like to get
<br />
> your feedback on my ideas since it's already going in a good direction.
<br />
>
<br />
> I wouldn't expect the siblings to be guaranteed to receive it (since
<br />
> clearly you can't guarantee that they all do, since some may have
<br />
> already been evaluated, or may be being evaluated at the same time),
<br />
> but I wouldn't expect them to be guaranteed to *not* receive it.
<br />
>
<br />
> Since the yaws_arg is being re-vamped anyway, maybe this should be
<br />
> carried around on the yaws_arg. A simple plist is probably fine for
<br />
> it. Then as the yaws_arg is returned changed it can be passed through
<br />
> changed. Then make all subcomponents pass the yaws_arg implicitly: so
<br />
> instead of {ewc,controller,func,[A,Foo]} calling func(A,Foo), make
<br />
> {ewc,controller,func,[Foo]]} call fun(A,Foo). That way you're not
<br />
> passing a stale yaws_arg accidentally. This is of course a backwards-
<br />
> breaking change, but not a difficult one to fix, since all of the
<br />
> erlyweb code that I've seen and written passes it to the sub-
<br />
> components anyway (even if it's not necessarily used).
<br />
>
<br />
> Otherwise, you end up all of the components doing something like this:
<br />
>
<br />
> show(A,Foo)
<br />
> NewA=yaws_arg:add_meta(A,[{title,get_the_title()}]),
<br />
>
<br />
> {return_with_meta,[{ewc,func,[NewA,Foo]}],
<br />
> NewA}.
<br />
>
<br />
> (once again, with better names than return_with_meta and add_meta)
<br />
> The worry here is that the subcomponents have to be called with NewA
<br />
> instead of A, which seems ripe for forgetting to me (especially if
<br />
> the yaws_arg some some validation before it passes it on; you could
<br />
> pass invalid data to sub-components this way).
<br />
>
<br />
> I haven't looked at the contents of the yaws_arg, but if it's tagged
<br />
> with a type, then you could just do this:
<br />
>
<br />
> show(A,Foo)
<br />
> [_New_yaws_arg=yaws_arg:add_property(A,[{title,get_the_title()}]),
<br />
> {ewc,func,[Foo]}].
<br />
>
<br />
> Since erlyweb already knows to check the returned list for {ewc} and
<br />
> whatnot, it could just check for a new yaws_arg and start using that
<br />
> one. The problem there is that it forces {ewc}s to be processed
<br />
> serially (since what do you do when you get two conflicting
<br />
> yaws_args?), which my erlyweb does not (and given your blog post on a
<br />
> potential {concurrent,[{ewc,...}]}, I suspect this won't be a
<br />
> guarantee forever). Another idea is to just add another return value
<br />
> from controller functions:
<br />
>
<br />
> show(A,Foo)
<br />
> [{add_property,{title,get_the_title()}},
<br />
> {add_property,{time_to_live,two_weeks()}}
<br />
> {ewc,controller,func,[Foo]},
<br />
> {ewc,controller,fun2,[yaws_arg:get_property(cookies)]].
<br />
>
<br />
> (this was has my implicit-passing of yaws_args, but it's not
<br />
> necessary; not doing so does preclude children retrieving properties
<br />
> from parents, but if they need that they should pass it as an
<br />
> argument anyway). That doesn't carry the assumption that they are
<br />
> processed serially. It prevents parents from getting to children's
<br />
> properties without using {phased,Ewcs,...}, but that's probably not a
<br />
> problem, and isn't very avoidable. (I think all of these options do,
<br />
> if they want to do post-processing of any kind).
<br />
>
<br />
> Personally, I like the last option, but it looks like it would
<br />
> require quite a few changes to the way that the erlyweb:ewc/N
<br />
> functions work
<br />
>
<br />
> Any other ideas? How does that last one look?
<br />
<br />
<br />
<br />
<br />
>
<br />
>
<br />
>
<br />
>
<br />
> >>> Btw, just curious, what parts of ErlyWeb are you rewriting?
<br />
> >> [...]
<br />
> >> Mostly large swaths of erlydb and erlydb_mnesia (in ways that make it
<br />
> >> work better with mnesia, but that make it incompatible with other
<br />
> >> DBMSs, which of course the current incarnation avoids). I may end up
<br />
> >> having to revert this if mnesia can't handle millions of objects,
<br />
> >> with which it seems to be having trouble once they start to become
<br />
> >> larger objects than simple tuples. I've hacked in a few return and
<br />
> >> 'EXIT' handlers from controller functions for special circumstances,
<br />
> >> like when I want to return a 400- or 500-level HTTP response along
<br />
> >> with other information. I might try to hack in some WebDAV handling
<br />
> >> stuff, as I'm considering writing a desktop client for my app in the
<br />
> >> future and that seems the easiest way to get the data to and from the
<br />
> >> desktop client. I haven't decided what that's going to look like yet.
<br />
> >> It looks like I may be hacking in a return value to return extended
<br />
> >> information to parent controller functions, like <title> tags. but I
<br />
> >> want to decide how it should work, first. It sounds like it's just
<br />
> >> not a concern to the two biggest users of erlyweb
<br />
> >
<br />
> > If you want to contribute this feature (or any other feature that you
<br />
> > think will be useful to other ErlyWeb users) I'll be happy to accept
<br />
> > your code.
<br />
> >
<br />
> > Yariv
<br />
> >
<br />
> >>
<br />
> >>
<br />
> >>>
<br />
> >>> Yariv
<br />
> >>>
<br />
> >>> On Nov 16, 2007 10:19 AM, David King <dking@ketralnis.com> wrote:
<br />
> >>>>
<br />
> >>>> erlyweb uses a component system for rendering pages. It makes
<br />
> >>>> most of
<br />
> >>>> my controller functions return lists like this:
<br />
> >>>>
<br />
> >>>> [{data,post:title(Post)},
<br />
> >>>> {ewc,post,contents,[A,Post]},
<br />
> >>>> {ewc,comment,comments,[A,post:comments(Post)]}]
<br />
> >>>>
<br />
> >>>> The view function then looks like:
<br />
> >>>>
<br />
> >>>> <%@ show([Title,Contents,Comments]) %>
<br />
> >>>> <h1><% Title %></h1>
<br />
> >>>> <div class="post_contents"><% Contents %></div>
<br />
> >>>> <ul class="comments><% Comments %></ul>
<br />
> >>>>
<br />
> >>>> I really like this, because it allows me to separate the view-logic
<br />
> >>>> for things like contents and comments out from each other, which
<br />
> >>>> makes changing the behaviour of these quite simple, localised, and
<br />
> >>>> re-
<br />
> >>>> useable. (In fact, as I re-write portions of erlyweb for my
<br />
> >>>> purposes,
<br />
> >>>> the component system is something that I haven't touched at all
<br />
> >>>> because it works quite well.) However, it has an inherent
<br />
> >>>> limitation:
<br />
> >>>> none of those functions can return data to be rendered outside of
<br />
> >>>> their components. In my case, I'd like to be able to set <title>
<br />
> >>>> tags, which means that the top-level controller function (by top-
<br />
> >>>> level, I mean the one referenced in the URL; like in /post/show/12,
<br />
> >>>> the top-level controller function would be show/2) needs to somehow
<br />
> >>>> return information to be rendered outside its little sandbox.
<br />
> >>>>
<br />
> >>>> I see that Vimagi doesn't set <title> tags (neither <http://
<br />
> >>>> vimagi.com/p/0PXmMRe6hGV> nor <http://vimagi.com/users/feeling3_4>
<br />
> >>>> set one, at least, and those are where I'd expect to see them), but
<br />
> >>>> BeerRiot does (<http://beerriot.com/beer/view/1751>; BTW I do love
<br />
> >>>> the idea of having a controller called "beer_controller").
<br />
> >>>>
<br />
> >>>> It isn't limited to <title>s (for instance, I may want to alert the
<br />
> >>>> browser that an RSS equivalent of this page exists, or what the
<br />
> >>>> caching TTL is for this page in the HTTP headers). Conceptually,
<br />
> >>>> how
<br />
> >>>> would one go about returning this extra information, while still
<br />
> >>>> using the component system (I now have a lot of code that uses it
<br />
> >>>> that I'd like to not re-write <img src="images/smiles/icon_smile.gif" alt="Smile" border="0" /> )?
<br />
> >>>>
<br />
> >>>>
<br />
> >>>>
<br />
> >>>>>
<br />
> >>>>
<br />
> >>>
<br />
> >>>
<br />
> >>
<br />
> >>>
<br />
> >>
<br />
> >
<br />
> >
<br />
>
<br />
> >
<br />
>
<br />
<br />
--~--~---------~--~----~------------~-------~--~----~
<br />
You received this message because you are subscribed to the Google Groups "erlyweb" group.
<br />
To post to this group, send email to <a href="mailto:erlyweb@googlegroups.com">erlyweb@googlegroups.com</a>
<br />
To unsubscribe from this group, send email to <a href="mailto:erlyweb-unsubscribe@googlegroups.com">erlyweb-unsubscribe@googlegroups.com</a>
<br />
For more options, visit this group at <a href="http://groups.google.com/group/erlyweb?hl=en" target="_blank">http://groups.google.com/group/erlyweb?hl=en</a>
<br />
-~----------~----~----~----~------~----~------~--~---
<br />
<br />
Post recived from mailinglist</td>
</tr>
<tr>
<td class="txtbottom"><span class="edited"></span></td>
</tr>
</table>
</td>
</tr>
<tr>
<td class="row2 five blacklink"><a href="#top">Back to top</a></td>
<td class="row2 six">
</td>
</tr>
<tr>
<td class="row3 one"><a id="34392"></a>ketralnis</td>
<td class="row3 two">
<table cellspacing="0">
<tr>
<td><a href="viewtopic.php?p=34392&sid=6ad65ce0d8e7e5873bcd5525cbbcee49#34392"><img src="templates/TrapExit/images/icon_minipost.gif" style="width: 12px; height: 9px; border: 0;" alt="" /></a>Posted: Sun Nov 18, 2007 1:34 am</td>
<td class="txtright"><a href="posting.php?mode=quote&p=34392&sid=6ad65ce0d8e7e5873bcd5525cbbcee49"><img src="templates/TrapExit/images/lang_english/icon_quote.gif" alt="Reply with quote" title="Reply with quote" border="0" /></a> </td>
</tr>
</table>
</td>
</tr>
<tr>
<td class="row1 three">
<span class="avatar"></span>
<span class="block">User</span>
<span class="block"></span>
<span class="block">Joined: 20 Jul 2007</span>
<span class="block">Posts: 151</span>
<span class="block">Location: San Francisco, CA</span>
</td>
<td class="row1 four">
<table cellspacing="0">
<tr>
<td class="txttop">> I think that the best solution is to add a new return value, e.g.
<br />
> {meta, Val}, to controller functions. ErlyWeb will accumulate those
<br />
> values in a list and pass it to the 'phased' Fun as an extra
<br />
> parameter. So, you could write
<br />
> {phased, {ewc, A},
<br />
> fun(ExpandedEwc, MetaVals, Rendered) ->
<br />
> {ewc, html_container, [A, MetaVals, Rendered]}
<br />
> end}.
<br />
> This would simplify setting the Title, Header, etc from the
<br />
> controllers without using Bryan's clever ErlTL tricks (which may be
<br />
> less-than-intuitive for some people <img src="images/smiles/icon_smile.gif" alt="Smile" border="0" /> ), add too much magic to the
<br />
> framework, or even changing it much. It would also work trivially even
<br />
> when subcomponents are rendered in parallel because this is
<br />
> effectively a side-effect-free accumulator.
<br />
<br />
That sounds good, and it avoids breaking backwards compatibility as
<br />
well. I do agree about changes to yaws_arg being a bad idea (although
<br />
it is currently possible for programs to change it before passing it
<br />
to children, that would be to be deliberate).
<br />
<br />
The only problem I see is that if my controller function returns:
<br />
<br />
[{add_property,{title,"The Title!"}},
<br />
{data,"foo"}]
<br />
<br />
Then what does my view function look like? These could both make sense:
<br />
<br />
<%@ fun([_,Data]) %> <!-- pass it through -->
<br />
<br />
<%@ fun([Data]) %> <!-- pretend it didn't exist -->
<br />
<br />
I wouldn't mind passing it through, but that does seem a bit strange
<br />
for children to be getting data intended for parents. Pretending it
<br />
didn't exist seems even stranger.
<br />
<br />
<br />
<br />
>
<br />
>>
<br />
>> I really like the component system, so I'd definitely like to get
<br />
>> your feedback on my ideas since it's already going in a good
<br />
>> direction.
<br />
>>
<br />
>> I wouldn't expect the siblings to be guaranteed to receive it (since
<br />
>> clearly you can't guarantee that they all do, since some may have
<br />
>> already been evaluated, or may be being evaluated at the same time),
<br />
>> but I wouldn't expect them to be guaranteed to *not* receive it.
<br />
>>
<br />
>> Since the yaws_arg is being re-vamped anyway, maybe this should be
<br />
>> carried around on the yaws_arg. A simple plist is probably fine for
<br />
>> it. Then as the yaws_arg is returned changed it can be passed through
<br />
>> changed. Then make all subcomponents pass the yaws_arg implicitly: so
<br />
>> instead of {ewc,controller,func,[A,Foo]} calling func(A,Foo), make
<br />
>> {ewc,controller,func,[Foo]]} call fun(A,Foo). That way you're not
<br />
>> passing a stale yaws_arg accidentally. This is of course a backwards-
<br />
>> breaking change, but not a difficult one to fix, since all of the
<br />
>> erlyweb code that I've seen and written passes it to the sub-
<br />
>> components anyway (even if it's not necessarily used).
<br />
>>
<br />
>> Otherwise, you end up all of the components doing something like
<br />
>> this:
<br />
>>
<br />
>> show(A,Foo)
<br />
>> NewA=yaws_arg:add_meta(A,[{title,get_the_title()}]),
<br />
>>
<br />
>> {return_with_meta,[{ewc,func,[NewA,Foo]}],
<br />
>> NewA}.
<br />
>>
<br />
>> (once again, with better names than return_with_meta and add_meta)
<br />
>> The worry here is that the subcomponents have to be called with NewA
<br />
>> instead of A, which seems ripe for forgetting to me (especially if
<br />
>> the yaws_arg some some validation before it passes it on; you could
<br />
>> pass invalid data to sub-components this way).
<br />
>>
<br />
>> I haven't looked at the contents of the yaws_arg, but if it's tagged
<br />
>> with a type, then you could just do this:
<br />
>>
<br />
>> show(A,Foo)
<br />
>> [_New_yaws_arg=yaws_arg:add_property(A,[{title,get_the_title()}]),
<br />
>> {ewc,func,[Foo]}].
<br />
>>
<br />
>> Since erlyweb already knows to check the returned list for {ewc} and
<br />
>> whatnot, it could just check for a new yaws_arg and start using that
<br />
>> one. The problem there is that it forces {ewc}s to be processed
<br />
>> serially (since what do you do when you get two conflicting
<br />
>> yaws_args?), which my erlyweb does not (and given your blog post on a
<br />
>> potential {concurrent,[{ewc,...}]}, I suspect this won't be a
<br />
>> guarantee forever). Another idea is to just add another return value
<br />
>> from controller functions:
<br />
>>
<br />
>> show(A,Foo)
<br />
>> [{add_property,{title,get_the_title()}},
<br />
>> {add_property,{time_to_live,two_weeks()}}
<br />
>> {ewc,controller,func,[Foo]},
<br />
>> {ewc,controller,fun2,[yaws_arg:get_property(cookies)]].
<br />
>>
<br />
>> (this was has my implicit-passing of yaws_args, but it's not
<br />
>> necessary; not doing so does preclude children retrieving properties
<br />
>> from parents, but if they need that they should pass it as an
<br />
>> argument anyway). That doesn't carry the assumption that they are
<br />
>> processed serially. It prevents parents from getting to children's
<br />
>> properties without using {phased,Ewcs,...}, but that's probably not a
<br />
>> problem, and isn't very avoidable. (I think all of these options do,
<br />
>> if they want to do post-processing of any kind).
<br />
>>
<br />
>> Personally, I like the last option, but it looks like it would
<br />
>> require quite a few changes to the way that the erlyweb:ewc/N
<br />
>> functions work
<br />
>>
<br />
>> Any other ideas? How does that last one look?
<br />
>
<br />
>
<br />
>
<br />
>
<br />
>>
<br />
>>
<br />
>>
<br />
>>
<br />
>>>>> Btw, just curious, what parts of ErlyWeb are you rewriting?
<br />
>>>> [...]
<br />
>>>> Mostly large swaths of erlydb and erlydb_mnesia (in ways that
<br />
>>>> make it
<br />
>>>> work better with mnesia, but that make it incompatible with other
<br />
>>>> DBMSs, which of course the current incarnation avoids). I may
<br />
>>>> end up
<br />
>>>> having to revert this if mnesia can't handle millions of objects,
<br />
>>>> with which it seems to be having trouble once they start to become
<br />
>>>> larger objects than simple tuples. I've hacked in a few return and
<br />
>>>> 'EXIT' handlers from controller functions for special
<br />
>>>> circumstances,
<br />
>>>> like when I want to return a 400- or 500-level HTTP response along
<br />
>>>> with other information. I might try to hack in some WebDAV handling
<br />
>>>> stuff, as I'm considering writing a desktop client for my app in
<br />
>>>> the
<br />
>>>> future and that seems the easiest way to get the data to and
<br />
>>>> from the
<br />
>>>> desktop client. I haven't decided what that's going to look like
<br />
>>>> yet.
<br />
>>>> It looks like I may be hacking in a return value to return extended
<br />
>>>> information to parent controller functions, like <title> tags.
<br />
>>>> but I
<br />
>>>> want to decide how it should work, first. It sounds like it's just
<br />
>>>> not a concern to the two biggest users of erlyweb
<br />
>>>
<br />
>>> If you want to contribute this feature (or any other feature that
<br />
>>> you
<br />
>>> think will be useful to other ErlyWeb users) I'll be happy to accept
<br />
>>> your code.
<br />
>>>
<br />
>>> Yariv
<br />
>>>
<br />
>>>>
<br />
>>>>
<br />
>>>>>
<br />
>>>>> Yariv
<br />
>>>>>
<br />
>>>>> On Nov 16, 2007 10:19 AM, David King <dking@ketralnis.com> wrote:
<br />
>>>>>>
<br />
>>>>>> erlyweb uses a component system for rendering pages. It makes
<br />
>>>>>> most of
<br />
>>>>>> my controller functions return lists like this:
<br />
>>>>>>
<br />
>>>>>> [{data,post:title(Post)},
<br />
>>>>>> {ewc,post,contents,[A,Post]},
<br />
>>>>>> {ewc,comment,comments,[A,post:comments(Post)]}]
<br />
>>>>>>
<br />
>>>>>> The view function then looks like:
<br />
>>>>>>
<br />
>>>>>> <%@ show([Title,Contents,Comments]) %>
<br />
>>>>>> <h1><% Title %></h1>
<br />
>>>>>> <div class="post_contents"><% Contents %></div>
<br />
>>>>>> <ul class="comments><% Comments %></ul>
<br />
>>>>>>
<br />
>>>>>> I really like this, because it allows me to separate the view-
<br />
>>>>>> logic
<br />
>>>>>> for things like contents and comments out from each other, which
<br />
>>>>>> makes changing the behaviour of these quite simple, localised,
<br />
>>>>>> and
<br />
>>>>>> re-
<br />
>>>>>> useable. (In fact, as I re-write portions of erlyweb for my
<br />
>>>>>> purposes,
<br />
>>>>>> the component system is something that I haven't touched at all
<br />
>>>>>> because it works quite well.) However, it has an inherent
<br />
>>>>>> limitation:
<br />
>>>>>> none of those functions can return data to be rendered outside of
<br />
>>>>>> their components. In my case, I'd like to be able to set <title>
<br />
>>>>>> tags, which means that the top-level controller function (by top-
<br />
>>>>>> level, I mean the one referenced in the URL; like in /post/
<br />
>>>>>> show/12,
<br />
>>>>>> the top-level controller function would be show/2) needs to
<br />
>>>>>> somehow
<br />
>>>>>> return information to be rendered outside its little sandbox.
<br />
>>>>>>
<br />
>>>>>> I see that Vimagi doesn't set <title> tags (neither <http://
<br />
>>>>>> vimagi.com/p/0PXmMRe6hGV> nor <http://vimagi.com/users/
<br />
>>>>>> feeling3_4>
<br />
>>>>>> set one, at least, and those are where I'd expect to see
<br />
>>>>>> them), but
<br />
>>>>>> BeerRiot does (<http://beerriot.com/beer/view/1751>; BTW I do
<br />
>>>>>> love
<br />
>>>>>> the idea of having a controller called "beer_controller").
<br />
>>>>>>
<br />
>>>>>> It isn't limited to <title>s (for instance, I may want to
<br />
>>>>>> alert the
<br />
>>>>>> browser that an RSS equivalent of this page exists, or what the
<br />
>>>>>> caching TTL is for this page in the HTTP headers). Conceptually,
<br />
>>>>>> how
<br />
>>>>>> would one go about returning this extra information, while still
<br />
>>>>>> using the component system (I now have a lot of code that uses it
<br />
>>>>>> that I'd like to not re-write <img src="images/smiles/icon_smile.gif" alt="Smile" border="0" /> )?
<br />
>>>>>>
<br />
>>>>>>
<br />
>>>>>>
<br />
>>>>>>>
<br />
>>>>>>
<br />
>>>>>
<br />
>>>>>
<br />
>>>>
<br />
>>>>>
<br />
>>>>
<br />
>>>
<br />
>>>
<br />
>>
<br />
>>>
<br />
>>
<br />
>
<br />
>
<br />
<br />
--~--~---------~--~----~------------~-------~--~----~
<br />
You received this message because you are subscribed to the Google Groups "erlyweb" group.
<br />
To post to this group, send email to <a href="mailto:erlyweb@googlegroups.com">erlyweb@googlegroups.com</a>
<br />
To unsubscribe from this group, send email to <a href="mailto:erlyweb-unsubscribe@googlegroups.com">erlyweb-unsubscribe@googlegroups.com</a>
<br />
For more options, visit this group at <a href="http://groups.google.com/group/erlyweb?hl=en" target="_blank">http://groups.google.com/group/erlyweb?hl=en</a>
<br />
-~----------~----~----~----~------~----~------~--~---
<br />
<br />
Post recived from mailinglist</td>
</tr>
<tr>
<td class="txtbottom"><span class="edited"></span></td>
</tr>
</table>
</td>
</tr>
<tr>
<td class="row1 five blacklink"><a href="#top">Back to top</a></td>
<td class="row1 six">
<a href="profile.php?mode=viewprofile&u=1210&sid=6ad65ce0d8e7e5873bcd5525cbbcee49"><img src="templates/TrapExit/images/lang_english/icon_profile.gif" alt="View user's profile" title="View user's profile" border="0" /></a> <a href="privmsg.php?mode=post&u=1210&sid=6ad65ce0d8e7e5873bcd5525cbbcee49"><img src="templates/TrapExit/images/lang_english/icon_pm.gif" alt="Send private message" title="Send private message" border="0" /></a> <a href="aim:goim?screenname=Ketralnis&message=Hello+Are+you+there?"><img src="templates/TrapExit/images/lang_english/icon_aim.gif" alt="AIM Address" title="AIM Address" border="0" /></a>
</td>
</tr>
<tr>
<td class="row3 one"><a id="34393"></a>Guest</td>
<td class="row3 two">
<table cellspacing="0">
<tr>
<td><a href="viewtopic.php?p=34393&sid=6ad65ce0d8e7e5873bcd5525cbbcee49#34393"><img src="templates/TrapExit/images/icon_minipost.gif" style="width: 12px; height: 9px; border: 0;" alt="" /></a>Posted: Sun Nov 18, 2007 1:47 am</td>
<td class="txtright"><a href="posting.php?mode=quote&p=34393&sid=6ad65ce0d8e7e5873bcd5525cbbcee49"><img src="templates/TrapExit/images/lang_english/icon_quote.gif" alt="Reply with quote" title="Reply with quote" border="0" /></a> </td>
</tr>
</table>
</td>
</tr>
<tr>
<td class="row2 three">
<span class="avatar"></span>
<span class="block">Guest</span>
<span class="block"></span>
<span class="block"></span>
<span class="block"></span>
<span class="block"></span>
</td>
<td class="row2 four">
<table cellspacing="0">
<tr>
<td class="txttop">On Nov 17, 2007 5:33 PM, David King <dking@ketralnis.com> wrote:
<br />
>
<br />
> > I think that the best solution is to add a new return value, e.g.
<br />
> > {meta, Val}, to controller functions. ErlyWeb will accumulate those
<br />
> > values in a list and pass it to the 'phased' Fun as an extra
<br />
> > parameter. So, you could write
<br />
> > {phased, {ewc, A},
<br />
> > fun(ExpandedEwc, MetaVals, Rendered) ->
<br />
> > {ewc, html_container, [A, MetaVals, Rendered]}
<br />
> > end}.
<br />
> > This would simplify setting the Title, Header, etc from the
<br />
> > controllers without using Bryan's clever ErlTL tricks (which may be
<br />
> > less-than-intuitive for some people <img src="images/smiles/icon_smile.gif" alt="Smile" border="0" /> ), add too much magic to the
<br />
> > framework, or even changing it much. It would also work trivially even
<br />
> > when subcomponents are rendered in parallel because this is
<br />
> > effectively a side-effect-free accumulator.
<br />
>
<br />
> That sounds good, and it avoids breaking backwards compatibility as
<br />
> well. I do agree about changes to yaws_arg being a bad idea (although
<br />
> it is currently possible for programs to change it before passing it
<br />
> to children, that would be to be deliberate).
<br />
>
<br />
> The only problem I see is that if my controller function returns:
<br />
>
<br />
> [{add_property,{title,"The Title!"}},
<br />
> {data,"foo"}]
<br />
>
<br />
> Then what does my view function look like? These could both make sense:
<br />
>
<br />
> <%@ fun([_,Data]) %> <!-- pass it through -->
<br />
>
<br />
> <%@ fun([Data]) %> <!-- pretend it didn't exist -->
<br />
>
<br />
> I wouldn't mind passing it through, but that does seem a bit strange
<br />
> for children to be getting data intended for parents. Pretending it
<br />
> didn't exist seems even stranger.
<br />
>
<br />
<br />
I don't think that the view function should receive the meta Vals. The
<br />
purpose of the {meta, Val} feature is to pass values "up" to the
<br />
'phased' Fun. If you need to pass the same value to the view function
<br />
(and I can't really think of a scenario where you would), you can add
<br />
it again as a {data, Data} tuple. Maybe to make things clearer,
<br />
instead of adding {meta, Val} values to the list you return from a
<br />
controller function, you would return a tuple such as
<br />
<br />
show(A) ->
<br />
<br />
...
<br />
{meta, [Val1, Val2], [{data, Data}, {ewc, ..}... ]}.
<br />
<br />
The elements of the second tuple element would be accumulated and
<br />
eventually passed to the 'phased' fun, and the third element would be
<br />
treated as the response value is treated today.
<br />
<br />
What do you think?
<br />
<br />
Yariv
<br />
<br />
<br />
<br />
>
<br />
>
<br />
>
<br />
> >
<br />
> >>
<br />
> >> I really like the component system, so I'd definitely like to get
<br />
> >> your feedback on my ideas since it's already going in a good
<br />
> >> direction.
<br />
> >>
<br />
> >> I wouldn't expect the siblings to be guaranteed to receive it (since
<br />
> >> clearly you can't guarantee that they all do, since some may have
<br />
> >> already been evaluated, or may be being evaluated at the same time),
<br />
> >> but I wouldn't expect them to be guaranteed to *not* receive it.
<br />
> >>
<br />
> >> Since the yaws_arg is being re-vamped anyway, maybe this should be
<br />
> >> carried around on the yaws_arg. A simple plist is probably fine for
<br />
> >> it. Then as the yaws_arg is returned changed it can be passed through
<br />
> >> changed. Then make all subcomponents pass the yaws_arg implicitly: so
<br />
> >> instead of {ewc,controller,func,[A,Foo]} calling func(A,Foo), make
<br />
> >> {ewc,controller,func,[Foo]]} call fun(A,Foo). That way you're not
<br />
> >> passing a stale yaws_arg accidentally. This is of course a backwards-
<br />
> >> breaking change, but not a difficult one to fix, since all of the
<br />
> >> erlyweb code that I've seen and written passes it to the sub-
<br />
> >> components anyway (even if it's not necessarily used).
<br />
> >>
<br />
> >> Otherwise, you end up all of the components doing something like
<br />
> >> this:
<br />
> >>
<br />
> >> show(A,Foo)
<br />
> >> NewA=yaws_arg:add_meta(A,[{title,get_the_title()}]),
<br />
> >>
<br />
> >> {return_with_meta,[{ewc,func,[NewA,Foo]}],
<br />
> >> NewA}.
<br />
> >>
<br />
> >> (once again, with better names than return_with_meta and add_meta)
<br />
> >> The worry here is that the subcomponents have to be called with NewA
<br />
> >> instead of A, which seems ripe for forgetting to me (especially if
<br />
> >> the yaws_arg some some validation before it passes it on; you could
<br />
> >> pass invalid data to sub-components this way).
<br />
> >>
<br />
> >> I haven't looked at the contents of the yaws_arg, but if it's tagged
<br />
> >> with a type, then you could just do this:
<br />
> >>
<br />
> >> show(A,Foo)
<br />
> >> [_New_yaws_arg=yaws_arg:add_property(A,[{title,get_the_title()}]),
<br />
> >> {ewc,func,[Foo]}].
<br />
> >>
<br />
> >> Since erlyweb already knows to check the returned list for {ewc} and
<br />
> >> whatnot, it could just check for a new yaws_arg and start using that
<br />
> >> one. The problem there is that it forces {ewc}s to be processed
<br />
> >> serially (since what do you do when you get two conflicting
<br />
> >> yaws_args?), which my erlyweb does not (and given your blog post on a
<br />
> >> potential {concurrent,[{ewc,...}]}, I suspect this won't be a
<br />
> >> guarantee forever). Another idea is to just add another return value
<br />
> >> from controller functions:
<br />
> >>
<br />
> >> show(A,Foo)
<br />
> >> [{add_property,{title,get_the_title()}},
<br />
> >> {add_property,{time_to_live,two_weeks()}}
<br />
> >> {ewc,controller,func,[Foo]},
<br />
> >> {ewc,controller,fun2,[yaws_arg:get_property(cookies)]].
<br />
> >>
<br />
> >> (this was has my implicit-passing of yaws_args, but it's not
<br />
> >> necessary; not doing so does preclude children retrieving properties
<br />
> >> from parents, but if they need that they should pass it as an
<br />
> >> argument anyway). That doesn't carry the assumption that they are
<br />
> >> processed serially. It prevents parents from getting to children's
<br />
> >> properties without using {phased,Ewcs,...}, but that's probably not a
<br />
> >> problem, and isn't very avoidable. (I think all of these options do,
<br />
> >> if they want to do post-processing of any kind).
<br />
> >>
<br />
> >> Personally, I like the last option, but it looks like it would
<br />
> >> require quite a few changes to the way that the erlyweb:ewc/N
<br />
> >> functions work
<br />
> >>
<br />
> >> Any other ideas? How does that last one look?
<br />
> >
<br />
> >
<br />
> >
<br />
> >
<br />
> >>
<br />
> >>
<br />
> >>
<br />
> >>
<br />
> >>>>> Btw, just curious, what parts of ErlyWeb are you rewriting?
<br />
> >>>> [...]
<br />
> >>>> Mostly large swaths of erlydb and erlydb_mnesia (in ways that
<br />
> >>>> make it
<br />
> >>>> work better with mnesia, but that make it incompatible with other
<br />
> >>>> DBMSs, which of course the current incarnation avoids). I may
<br />
> >>>> end up
<br />
> >>>> having to revert this if mnesia can't handle millions of objects,
<br />
> >>>> with which it seems to be having trouble once they start to become
<br />
> >>>> larger objects than simple tuples. I've hacked in a few return and
<br />
> >>>> 'EXIT' handlers from controller functions for special
<br />
> >>>> circumstances,
<br />
> >>>> like when I want to return a 400- or 500-level HTTP response along
<br />
> >>>> with other information. I might try to hack in some WebDAV handling
<br />
> >>>> stuff, as I'm considering writing a desktop client for my app in
<br />
> >>>> the
<br />
> >>>> future and that seems the easiest way to get the data to and
<br />
> >>>> from the
<br />
> >>>> desktop client. I haven't decided what that's going to look like
<br />
> >>>> yet.
<br />
> >>>> It looks like I may be hacking in a return value to return extended
<br />
> >>>> information to parent controller functions, like <title> tags.
<br />
> >>>> but I
<br />
> >>>> want to decide how it should work, first. It sounds like it's just
<br />
> >>>> not a concern to the two biggest users of erlyweb
<br />
> >>>
<br />
> >>> If you want to contribute this feature (or any other feature that
<br />
> >>> you
<br />
> >>> think will be useful to other ErlyWeb users) I'll be happy to accept
<br />
> >>> your code.
<br />
> >>>
<br />
> >>> Yariv
<br />
> >>>
<br />
> >>>>
<br />
> >>>>
<br />
> >>>>>
<br />
> >>>>> Yariv
<br />
> >>>>>
<br />
> >>>>> On Nov 16, 2007 10:19 AM, David King <dking@ketralnis.com> wrote:
<br />
> >>>>>>
<br />
> >>>>>> erlyweb uses a component system for rendering pages. It makes
<br />
> >>>>>> most of
<br />
> >>>>>> my controller functions return lists like this:
<br />
> >>>>>>
<br />
> >>>>>> [{data,post:title(Post)},
<br />
> >>>>>> {ewc,post,contents,[A,Post]},
<br />
> >>>>>> {ewc,comment,comments,[A,post:comments(Post)]}]
<br />
> >>>>>>
<br />
> >>>>>> The view function then looks like:
<br />
> >>>>>>
<br />
> >>>>>> <%@ show([Title,Contents,Comments]) %>
<br />
> >>>>>> <h1><% Title %></h1>
<br />
> >>>>>> <div class="post_contents"><% Contents %></div>
<br />
> >>>>>> <ul class="comments><% Comments %></ul>
<br />
> >>>>>>
<br />
> >>>>>> I really like this, because it allows me to separate the view-
<br />
> >>>>>> logic
<br />
> >>>>>> for things like contents and comments out from each other, which
<br />
> >>>>>> makes changing the behaviour of these quite simple, localised,
<br />
> >>>>>> and
<br />
> >>>>>> re-
<br />
> >>>>>> useable. (In fact, as I re-write portions of erlyweb for my
<br />
> >>>>>> purposes,
<br />
> >>>>>> the component system is something that I haven't touched at all
<br />
> >>>>>> because it works quite well.) However, it has an inherent
<br />
> >>>>>> limitation:
<br />
> >>>>>> none of those functions can return data to be rendered outside of
<br />
> >>>>>> their components. In my case, I'd like to be able to set <title>
<br />
> >>>>>> tags, which means that the top-level controller function (by top-
<br />
> >>>>>> level, I mean the one referenced in the URL; like in /post/
<br />
> >>>>>> show/12,
<br />
> >>>>>> the top-level controller function would be show/2) needs to
<br />
> >>>>>> somehow
<br />
> >>>>>> return information to be rendered outside its little sandbox.
<br />
> >>>>>>
<br />
> >>>>>> I see that Vimagi doesn't set <title> tags (neither <http://
<br />
> >>>>>> vimagi.com/p/0PXmMRe6hGV> nor <http://vimagi.com/users/
<br />
> >>>>>> feeling3_4>
<br />
> >>>>>> set one, at least, and those are where I'd expect to see
<br />
> >>>>>> them), but
<br />
> >>>>>> BeerRiot does (<http://beerriot.com/beer/view/1751>; BTW I do
<br />
> >>>>>> love
<br />
> >>>>>> the idea of having a controller called "beer_controller").
<br />
> >>>>>>
<br />
> >>>>>> It isn't limited to <title>s (for instance, I may want to
<br />
> >>>>>> alert the
<br />
> >>>>>> browser that an RSS equivalent of this page exists, or what the
<br />
> >>>>>> caching TTL is for this page in the HTTP headers). Conceptually,
<br />
> >>>>>> how
<br />
> >>>>>> would one go about returning this extra information, while still
<br />
> >>>>>> using the component system (I now have a lot of code that uses it
<br />
> >>>>>> that I'd like to not re-write <img src="images/smiles/icon_smile.gif" alt="Smile" border="0" /> )?
<br />
> >>>>>>
<br />
> >>>>>>
<br />
> >>>>>>
<br />
> >>>>>>>
<br />
> >>>>>>
<br />
> >>>>>
<br />
> >>>>>
<br />
> >>>>
<br />
> >>>>>
<br />
> >>>>
<br />
> >>>
<br />
> >>>
<br />
> >>
<br />
> >>>
<br />
> >>
<br />
> >
<br />
> >
<br />
>
<br />
> >
<br />
>
<br />
<br />
--~--~---------~--~----~------------~-------~--~----~
<br />
You received this message because you are subscribed to the Google Groups "erlyweb" group.
<br />
To post to this group, send email to <a href="mailto:erlyweb@googlegroups.com">erlyweb@googlegroups.com</a>
<br />
To unsubscribe from this group, send email to <a href="mailto:erlyweb-unsubscribe@googlegroups.com">erlyweb-unsubscribe@googlegroups.com</a>
<br />
For more options, visit this group at <a href="http://groups.google.com/group/erlyweb?hl=en" target="_blank">http://groups.google.com/group/erlyweb?hl=en</a>
<br />
-~----------~----~----~----~------~----~------~--~---
<br />
<br />
Post recived from mailinglist</td>
</tr>
<tr>
<td class="txtbottom"><span class="edited"></span></td>
</tr>
</table>
</td>
</tr>
<tr>
<td class="row2 five blacklink"><a href="#top">Back to top</a></td>
<td class="row2 six">
</td>
</tr>
<tr>
<td class="row3 one"><a id="34395"></a>ketralnis</td>
<td class="row3 two">
<table cellspacing="0">
<tr>
<td><a href="viewtopic.php?p=34395&sid=6ad65ce0d8e7e5873bcd5525cbbcee49#34395"><img src="templates/TrapExit/images/icon_minipost.gif" style="width: 12px; height: 9px; border: 0;" alt="" /></a>Posted: Sun Nov 18, 2007 2:23 am</td>
<td class="txtright"><a href="posting.php?mode=quote&p=34395&sid=6ad65ce0d8e7e5873bcd5525cbbcee49"><img src="templates/TrapExit/images/lang_english/icon_quote.gif" alt="Reply with quote" title="Reply with quote" border="0" /></a> </td>
</tr>
</table>
</td>
</tr>
<tr>
<td class="row1 three">
<span class="avatar"></span>
<span class="block">User</span>
<span class="block"></span>
<span class="block">Joined: 20 Jul 2007</span>
<span class="block">Posts: 151</span>
<span class="block">Location: San Francisco, CA</span>
</td>
<td class="row1 four">
<table cellspacing="0">
<tr>
<td class="txttop">>> Then what does my view function look like? [...]
<br />
> I don't think that the view function should receive the meta Vals. The
<br />
> purpose of the {meta, Val} feature is to pass values "up" to the
<br />
> 'phased' Fun. If you need to pass the same value to the view function
<br />
> (and I can't really think of a scenario where you would), you can add
<br />
> it again as a {data, Data} tuple. Maybe to make things clearer,
<br />
> instead of adding {meta, Val} values to the list you return from a
<br />
> controller function, you would return a tuple such as
<br />
> show(A) ->
<br />
> ...
<br />
> {meta, [Val1, Val2], [{data, Data}, {ewc, ..}... ]}.
<br />
<br />
I like it. But I'm starting to think that {meta} is a bad word for
<br />
it. It's not very descriptive of what's actually happening. Of
<br />
course, I don't have any better suggestions <img src="images/smiles/icon_smile.gif" alt="Smile" border="0" /> Maybe
<br />
{with_properties} or {set_properties} or something?
<br />
<br />
--~--~---------~--~----~------------~-------~--~----~
<br />
You received this message because you are subscribed to the Google Groups "erlyweb" group.
<br />
To post to this group, send email to <a href="mailto:erlyweb@googlegroups.com">erlyweb@googlegroups.com</a>
<br />
To unsubscribe from this group, send email to <a href="mailto:erlyweb-unsubscribe@googlegroups.com">erlyweb-unsubscribe@googlegroups.com</a>
<br />
For more options, visit this group at <a href="http://groups.google.com/group/erlyweb?hl=en" target="_blank">http://groups.google.com/group/erlyweb?hl=en</a>
<br />
-~----------~----~----~----~------~----~------~--~---
<br />
<br />
Post recived from mailinglist</td>
</tr>
<tr>
<td class="txtbottom"><span class="edited"></span></td>
</tr>
</table>
</td>
</tr>
<tr>
<td class="row1 five blacklink"><a href="#top">Back to top</a></td>
<td class="row1 six">
<a href="profile.php?mode=viewprofile&u=1210&sid=6ad65ce0d8e7e5873bcd5525cbbcee49"><img src="templates/TrapExit/images/lang_english/icon_profile.gif" alt="View user's profile" title="View user's profile" border="0" /></a> <a href="privmsg.php?mode=post&u=1210&sid=6ad65ce0d8e7e5873bcd5525cbbcee49"><img src="templates/TrapExit/images/lang_english/icon_pm.gif" alt="Send private message" title="Send private message" border="0" /></a> <a href="aim:goim?screenname=Ketralnis&message=Hello+Are+you+there?"><img src="templates/TrapExit/images/lang_english/icon_aim.gif" alt="AIM Address" title="AIM Address" border="0" /></a>
</td>
</tr>
<tr>
<td class="row3 one"><a id="34397"></a>Guest</td>
<td class="row3 two">
<table cellspacing="0">
<tr>
<td><a href="viewtopic.php?p=34397&sid=6ad65ce0d8e7e5873bcd5525cbbcee49#34397"><img src="templates/TrapExit/images/icon_minipost.gif" style="width: 12px; height: 9px; border: 0;" alt="" /></a>Posted: Sun Nov 18, 2007 2:30 am</td>
<td class="txtright"><a href="posting.php?mode=quote&p=34397&sid=6ad65ce0d8e7e5873bcd5525cbbcee49"><img src="templates/TrapExit/images/lang_english/icon_quote.gif" alt="Reply with quote" title="Reply with quote" border="0" /></a> </td>
</tr>
</table>
</td>
</tr>
<tr>
<td class="row2 three">
<span class="avatar"></span>
<span class="block">Guest</span>
<span class="block"></span>
<span class="block"></span>
<span class="block"></span>
<span class="block"></span>
</td>
<td class="row2 four">
<table cellspacing="0">
<tr>
<td class="txttop">>
<br />
> I like it. But I'm starting to think that {meta} is a bad word for
<br />
> it. It's not very descriptive of what's actually happening. Of
<br />
> course, I don't have any better suggestions <img src="images/smiles/icon_smile.gif" alt="Smile" border="0" /> Maybe
<br />
> {with_properties} or {set_properties} or something?
<br />
<br />
Yeah, I agree. I think 'with_properties' and 'set_properties' sounds
<br />
too generic, though. Maybe 'with_meta_vals' or 'with_phased_vals'?
<br />
<br />
>
<br />
>
<br />
> >
<br />
>
<br />
<br />
--~--~---------~--~----~------------~-------~--~----~
<br />
You received this message because you are subscribed to the Google Groups "erlyweb" group.
<br />
To post to this group, send email to <a href="mailto:erlyweb@googlegroups.com">erlyweb@googlegroups.com</a>
<br />
To unsubscribe from this group, send email to <a href="mailto:erlyweb-unsubscribe@googlegroups.com">erlyweb-unsubscribe@googlegroups.com</a>
<br />
For more options, visit this group at <a href="http://groups.google.com/group/erlyweb?hl=en" target="_blank">http://groups.google.com/group/erlyweb?hl=en</a>
<br />
-~----------~----~----~----~------~----~------~--~---
<br />
<br />
Post recived from mailinglist</td>
</tr>
<tr>
<td class="txtbottom"><span class="edited"></span></td>
</tr>
</table>
</td>
</tr>
<tr>
<td class="row2 five blacklink"><a href="#top">Back to top</a></td>
<td class="row2 six">
</td>
</tr>
<tr>
<td class="row3 one"><a id="34398"></a>ketralnis</td>
<td class="row3 two">
<table cellspacing="0">
<tr>
<td><a href="viewtopic.php?p=34398&sid=6ad65ce0d8e7e5873bcd5525cbbcee49#34398"><img src="templates/TrapExit/images/icon_minipost.gif" style="width: 12px; height: 9px; border: 0;" alt="" /></a>Posted: Sun Nov 18, 2007 2:36 am</td>
<td class="txtright"><a href="posting.php?mode=quote&p=34398&sid=6ad65ce0d8e7e5873bcd5525cbbcee49"><img src="templates/TrapExit/images/lang_english/icon_quote.gif" alt="Reply with quote" title="Reply with quote" border="0" /></a> </td>
</tr>
</table>
</td>
</tr>
<tr>
<td class="row1 three">
<span class="avatar"></span>
<span class="block">User</span>
<span class="block"></span>
<span class="block">Joined: 20 Jul 2007</span>
<span class="block">Posts: 151</span>
<span class="block">Location: San Francisco, CA</span>
</td>
<td class="row1 four">
<table cellspacing="0">
<tr>
<td class="txttop">> Yeah, I agree. I think 'with_properties' and 'set_properties' sounds
<br />
> too generic, though. Maybe 'with_meta_vals' or 'with_phased_vals'?
<br />
<br />
I like with_phased_vals, that's relatively clear
<br />
<br />
--~--~---------~--~----~------------~-------~--~----~
<br />
You received this message because you are subscribed to the Google Groups "erlyweb" group.
<br />
To post to this group, send email to <a href="mailto:erlyweb@googlegroups.com">erlyweb@googlegroups.com</a>
<br />
To unsubscribe from this group, send email to <a href="mailto:erlyweb-unsubscribe@googlegroups.com">erlyweb-unsubscribe@googlegroups.com</a>
<br />
For more options, visit this group at <a href="http://groups.google.com/group/erlyweb?hl=en" target="_blank">http://groups.google.com/group/erlyweb?hl=en</a>
<br />
-~----------~----~----~----~------~----~------~--~---
<br />
<br />
Post recived from mailinglist</td>
</tr>
<tr>
<td class="txtbottom"><span class="edited"></span></td>
</tr>
</table>
</td>
</tr>
<tr>
<td class="row1 five blacklink"><a href="#top">Back to top</a></td>
<td class="row1 six">
<a href="profile.php?mode=viewprofile&u=1210&sid=6ad65ce0d8e7e5873bcd5525cbbcee49"><img src="templates/TrapExit/images/lang_english/icon_profile.gif" alt="View user's profile" title="View user's profile" border="0" /></a> <a href="privmsg.php?mode=post&u=1210&sid=6ad65ce0d8e7e5873bcd5525cbbcee49"><img src="templates/TrapExit/images/lang_english/icon_pm.gif" alt="Send private message" title="Send private message" border="0" /></a> <a href="aim:goim?screenname=Ketralnis&message=Hello+Are+you+there?"><img src="templates/TrapExit/images/lang_english/icon_aim.gif" alt="AIM Address" title="AIM Address" border="0" /></a>
</td>
</tr>
<tr>
<td class="row3 one"><a id="34409"></a>ketralnis</td>
<td class="row3 two">
<table cellspacing="0">
<tr>
<td><a href="viewtopic.php?p=34409&sid=6ad65ce0d8e7e5873bcd5525cbbcee49#34409"><img src="templates/TrapExit/images/icon_minipost.gif" style="width: 12px; height: 9px; border: 0;" alt="" /></a>Posted: Sun Nov 18, 2007 8:44 am</td>
<td class="txtright"><a href="posting.php?mode=quote&p=34409&sid=6ad65ce0d8e7e5873bcd5525cbbcee49"><img src="templates/TrapExit/images/lang_english/icon_quote.gif" alt="Reply with quote" title="Reply with quote" border="0" /></a> </td>
</tr>
</table>
</td>
</tr>
<tr>
<td class="row2 three">
<span class="avatar"></span>
<span class="block">User</span>
<span class="block"></span>
<span class="block">Joined: 20 Jul 2007</span>
<span class="block">Posts: 151</span>
<span class="block">Location: San Francisco, CA</span>
</td>
<td class="row2 four">
<table cellspacing="0">
<tr>
<td class="txttop">>> {phased, {ewc, A},
<br />
>> fun(ExpandedEwc, MetaVals, Rendered) ->
<br />
>> {ewc, html_container, [A, MetaVals, Rendered]}
<br />
>> end}.
<br />
<br />
Yoi probably want to change the order of those arguments. If you have
<br />
<br />
fun(ExpandedEwc, Rendered)
<br />
<br />
then you should also have:
<br />
<br />
fun(ExpandedEwc, Rendered, MetaVals)
<br />
<br />
That is, keep the first few arguments consistent for the various
<br />
forms, and when adding arguments, add them to the end, not the middle.
<br />
<br />
<br />
>> This would simplify setting the Title, Header, etc from the
<br />
>> controllers without using Bryan's clever ErlTL tricks (which may be
<br />
>> less-than-intuitive for some people <img src="images/smiles/icon_smile.gif" alt="Smile" border="0" /> ), add too much magic to the
<br />
>> framework, or even changing it much. It would also work trivially
<br />
>> even
<br />
>> when subcomponents are rendered in parallel because this is
<br />
>> effectively a side-effect-free accumulator.
<br />
>
<br />
> That sounds good, and it avoids breaking backwards compatibility as
<br />
> well. I do agree about changes to yaws_arg being a bad idea (although
<br />
> it is currently possible for programs to change it before passing it
<br />
> to children, that would be to be deliberate).
<br />
>
<br />
> The only problem I see is that if my controller function returns:
<br />
>
<br />
> [{add_property,{title,"The Title!"}},
<br />
> {data,"foo"}]
<br />
>
<br />
> Then what does my view function look like? These could both make
<br />
> sense:
<br />
>
<br />
> <%@ fun([_,Data]) %> <!-- pass it through -->
<br />
>
<br />
> <%@ fun([Data]) %> <!-- pretend it didn't exist -->
<br />
>
<br />
> I wouldn't mind passing it through, but that does seem a bit strange
<br />
> for children to be getting data intended for parents. Pretending it
<br />
> didn't exist seems even stranger.
<br />
>
<br />
>
<br />
>
<br />
>>
<br />
>>>
<br />
>>> I really like the component system, so I'd definitely like to get
<br />
>>> your feedback on my ideas since it's already going in a good
<br />
>>> direction.
<br />
>>>
<br />
>>> I wouldn't expect the siblings to be guaranteed to receive it (since
<br />
>>> clearly you can't guarantee that they all do, since some may have
<br />
>>> already been evaluated, or may be being evaluated at the same time),
<br />
>>> but I wouldn't expect them to be guaranteed to *not* receive it.
<br />
>>>
<br />
>>> Since the yaws_arg is being re-vamped anyway, maybe this should be
<br />
>>> carried around on the yaws_arg. A simple plist is probably fine for
<br />
>>> it. Then as the yaws_arg is returned changed it can be passed
<br />
>>> through
<br />
>>> changed. Then make all subcomponents pass the yaws_arg
<br />
>>> implicitly: so
<br />
>>> instead of {ewc,controller,func,[A,Foo]} calling func(A,Foo), make
<br />
>>> {ewc,controller,func,[Foo]]} call fun(A,Foo). That way you're not
<br />
>>> passing a stale yaws_arg accidentally. This is of course a
<br />
>>> backwards-
<br />
>>> breaking change, but not a difficult one to fix, since all of the
<br />
>>> erlyweb code that I've seen and written passes it to the sub-
<br />
>>> components anyway (even if it's not necessarily used).
<br />
>>>
<br />
>>> Otherwise, you end up all of the components doing something like
<br />
>>> this:
<br />
>>>
<br />
>>> show(A,Foo)
<br />
>>> NewA=yaws_arg:add_meta(A,[{title,get_the_title()}]),
<br />
>>>
<br />
>>> {return_with_meta,[{ewc,func,[NewA,Foo]}],
<br />
>>> NewA}.
<br />
>>>
<br />
>>> (once again, with better names than return_with_meta and add_meta)
<br />
>>> The worry here is that the subcomponents have to be called with NewA
<br />
>>> instead of A, which seems ripe for forgetting to me (especially if
<br />
>>> the yaws_arg some some validation before it passes it on; you could
<br />
>>> pass invalid data to sub-components this way).
<br />
>>>
<br />
>>> I haven't looked at the contents of the yaws_arg, but if it's tagged
<br />
>>> with a type, then you could just do this:
<br />
>>>
<br />
>>> show(A,Foo)
<br />
>>> [_New_yaws_arg=yaws_arg:add_property(A,[{title,get_the_title
<br />
>>> ()}]),
<br />
>>> {ewc,func,[Foo]}].
<br />
>>>
<br />
>>> Since erlyweb already knows to check the returned list for {ewc} and
<br />
>>> whatnot, it could just check for a new yaws_arg and start using that
<br />
>>> one. The problem there is that it forces {ewc}s to be processed
<br />
>>> serially (since what do you do when you get two conflicting
<br />
>>> yaws_args?), which my erlyweb does not (and given your blog post
<br />
>>> on a
<br />
>>> potential {concurrent,[{ewc,...}]}, I suspect this won't be a
<br />
>>> guarantee forever). Another idea is to just add another return value
<br />
>>> from controller functions:
<br />
>>>
<br />
>>> show(A,Foo)
<br />
>>> [{add_property,{title,get_the_title()}},
<br />
>>> {add_property,{time_to_live,two_weeks()}}
<br />
>>> {ewc,controller,func,[Foo]},
<br />
>>> {ewc,controller,fun2,[yaws_arg:get_property(cookies)]].
<br />
>>>
<br />
>>> (this was has my implicit-passing of yaws_args, but it's not
<br />
>>> necessary; not doing so does preclude children retrieving properties
<br />
>>> from parents, but if they need that they should pass it as an
<br />
>>> argument anyway). That doesn't carry the assumption that they are
<br />
>>> processed serially. It prevents parents from getting to children's
<br />
>>> properties without using {phased,Ewcs,...}, but that's probably
<br />
>>> not a
<br />
>>> problem, and isn't very avoidable. (I think all of these options do,
<br />
>>> if they want to do post-processing of any kind).
<br />
>>>
<br />
>>> Personally, I like the last option, but it looks like it would
<br />
>>> require quite a few changes to the way that the erlyweb:ewc/N
<br />
>>> functions work
<br />
>>>
<br />
>>> Any other ideas? How does that last one look?
<br />
>>
<br />
>>
<br />
>>
<br />
>>
<br />
>>>
<br />
>>>
<br />
>>>
<br />
>>>
<br />
>>>>>> Btw, just curious, what parts of ErlyWeb are you rewriting?
<br />
>>>>> [...]
<br />
>>>>> Mostly large swaths of erlydb and erlydb_mnesia (in ways that
<br />
>>>>> make it
<br />
>>>>> work better with mnesia, but that make it incompatible with other
<br />
>>>>> DBMSs, which of course the current incarnation avoids). I may
<br />
>>>>> end up
<br />
>>>>> having to revert this if mnesia can't handle millions of objects,
<br />
>>>>> with which it seems to be having trouble once they start to become
<br />
>>>>> larger objects than simple tuples. I've hacked in a few return and
<br />
>>>>> 'EXIT' handlers from controller functions for special
<br />
>>>>> circumstances,
<br />
>>>>> like when I want to return a 400- or 500-level HTTP response along
<br />
>>>>> with other information. I might try to hack in some WebDAV
<br />
>>>>> handling
<br />
>>>>> stuff, as I'm considering writing a desktop client for my app in
<br />
>>>>> the
<br />
>>>>> future and that seems the easiest way to get the data to and
<br />
>>>>> from the
<br />
>>>>> desktop client. I haven't decided what that's going to look like
<br />
>>>>> yet.
<br />
>>>>> It looks like I may be hacking in a return value to return
<br />
>>>>> extended
<br />
>>>>> information to parent controller functions, like <title> tags.
<br />
>>>>> but I
<br />
>>>>> want to decide how it should work, first. It sounds like it's just
<br />
>>>>> not a concern to the two biggest users of erlyweb
<br />
>>>>
<br />
>>>> If you want to contribute this feature (or any other feature that
<br />
>>>> you
<br />
>>>> think will be useful to other ErlyWeb users) I'll be happy to
<br />
>>>> accept
<br />
>>>> your code.
<br />
>>>>
<br />
>>>> Yariv
<br />
>>>>
<br />
>>>>>
<br />
>>>>>
<br />
>>>>>>
<br />
>>>>>> Yariv
<br />
>>>>>>
<br />
>>>>>> On Nov 16, 2007 10:19 AM, David King <dking@ketralnis.com> wrote:
<br />
>>>>>>>
<br />
>>>>>>> erlyweb uses a component system for rendering pages. It makes
<br />
>>>>>>> most of
<br />
>>>>>>> my controller functions return lists like this:
<br />
>>>>>>>
<br />
>>>>>>> [{data,post:title(Post)},
<br />
>>>>>>> {ewc,post,contents,[A,Post]},
<br />
>>>>>>> {ewc,comment,comments,[A,post:comments(Post)]}]
<br />
>>>>>>>
<br />
>>>>>>> The view function then looks like:
<br />
>>>>>>>
<br />
>>>>>>> <%@ show([Title,Contents,Comments]) %>
<br />
>>>>>>> <h1><% Title %></h1>
<br />
>>>>>>> <div class="post_contents"><% Contents %></div>
<br />
>>>>>>> <ul class="comments><% Comments %></ul>
<br />
>>>>>>>
<br />
>>>>>>> I really like this, because it allows me to separate the view-
<br />
>>>>>>> logic
<br />
>>>>>>> for things like contents and comments out from each other, which
<br />
>>>>>>> makes changing the behaviour of these quite simple, localised,
<br />
>>>>>>> and
<br />
>>>>>>> re-
<br />
>>>>>>> useable. (In fact, as I re-write portions of erlyweb for my
<br />
>>>>>>> purposes,
<br />
>>>>>>> the component system is something that I haven't touched at all
<br />
>>>>>>> because it works quite well.) However, it has an inherent
<br />
>>>>>>> limitation:
<br />
>>>>>>> none of those functions can return data to be rendered
<br />
>>>>>>> outside of
<br />
>>>>>>> their components. In my case, I'd like to be able to set <title>
<br />
>>>>>>> tags, which means that the top-level controller function (by
<br />
>>>>>>> top-
<br />
>>>>>>> level, I mean the one referenced in the URL; like in /post/
<br />
>>>>>>> show/12,
<br />
>>>>>>> the top-level controller function would be show/2) needs to
<br />
>>>>>>> somehow
<br />
>>>>>>> return information to be rendered outside its little sandbox.
<br />
>>>>>>>
<br />
>>>>>>> I see that Vimagi doesn't set <title> tags (neither <http://
<br />
>>>>>>> vimagi.com/p/0PXmMRe6hGV> nor <http://vimagi.com/users/
<br />
>>>>>>> feeling3_4>
<br />
>>>>>>> set one, at least, and those are where I'd expect to see
<br />
>>>>>>> them), but
<br />
>>>>>>> BeerRiot does (<http://beerriot.com/beer/view/1751>; BTW I do
<br />
>>>>>>> love
<br />
>>>>>>> the idea of having a controller called "beer_controller").
<br />
>>>>>>>
<br />
>>>>>>> It isn't limited to <title>s (for instance, I may want to
<br />
>>>>>>> alert the
<br />
>>>>>>> browser that an RSS equivalent of this page exists, or what the
<br />
>>>>>>> caching TTL is for this page in the HTTP headers). Conceptually,
<br />
>>>>>>> how
<br />
>>>>>>> would one go about returning this extra information, while still
<br />
>>>>>>> using the component system (I now have a lot of code that
<br />
>>>>>>> uses it
<br />
>>>>>>> that I'd like to not re-write <img src="images/smiles/icon_smile.gif" alt="Smile" border="0" /> )?
<br />
>>>>>>>
<br />
>>>>>>>
<br />
>>>>>>>
<br />
>>>>>>>>
<br />
>>>>>>>
<br />
>>>>>>
<br />
>>>>>>
<br />
>>>>>
<br />
>>>>>>
<br />
>>>>>
<br />
>>>>
<br />
>>>>
<br />
>>>
<br />
>>>>
<br />
>>>
<br />
>>
<br />
>>
<br />
>
<br />
>
<br />
<br />
--~--~---------~--~----~------------~-------~--~----~
<br />
You received this message because you are subscribed to the Google Groups "erlyweb" group.
<br />
To post to this group, send email to <a href="mailto:erlyweb@googlegroups.com">erlyweb@googlegroups.com</a>
<br />
To unsubscribe from this group, send email to <a href="mailto:erlyweb-unsubscribe@googlegroups.com">erlyweb-unsubscribe@googlegroups.com</a>
<br />
For more options, visit this group at <a href="http://groups.google.com/group/erlyweb?hl=en" target="_blank">http://groups.google.com/group/erlyweb?hl=en</a>
<br />
-~----------~----~----~----~------~----~------~--~---
<br />
<br />
Post recived from mailinglist</td>
</tr>
<tr>
<td class="txtbottom"><span class="edited"></span></td>
</tr>
</table>
</td>
</tr>
<tr>
<td class="row2 five blacklink"><a href="#top">Back to top</a></td>
<td class="row2 six">
<a href="profile.php?mode=viewprofile&u=1210&sid=6ad65ce0d8e7e5873bcd5525cbbcee49"><img src="templates/TrapExit/images/lang_english/icon_profile.gif" alt="View user's profile" title="View user's profile" border="0" /></a> <a href="privmsg.php?mode=post&u=1210&sid=6ad65ce0d8e7e5873bcd5525cbbcee49"><img src="templates/TrapExit/images/lang_english/icon_pm.gif" alt="Send private message" title="Send private message" border="0" /></a> <a href="aim:goim?screenname=Ketralnis&message=Hello+Are+you+there?"><img src="templates/TrapExit/images/lang_english/icon_aim.gif" alt="AIM Address" title="AIM Address" border="0" /></a>
</td>
</tr>
<tr>
<td class="row3 one"><a id="34413"></a>Guest</td>
<td class="row3 two">
<table cellspacing="0">
<tr>
<td><a href="viewtopic.php?p=34413&sid=6ad65ce0d8e7e5873bcd5525cbbcee49#34413"><img src="templates/TrapExit/images/icon_minipost.gif" style="width: 12px; height: 9px; border: 0;" alt="" /></a>Posted: Sun Nov 18, 2007 10:20 am</td>
<td class="txtright"><a href="posting.php?mode=quote&p=34413&sid=6ad65ce0d8e7e5873bcd5525cbbcee49"><img src="templates/TrapExit/images/lang_english/icon_quote.gif" alt="Reply with quote" title="Reply with quote" border="0" /></a> </td>
</tr>
</table>
</td>
</tr>
<tr>
<td class="row1 three">
<span class="avatar"></span>
<span class="block">Guest</span>
<span class="block"></span>
<span class="block"></span>
<span class="block"></span>
<span class="block"></span>
</td>
<td class="row1 four">
<table cellspacing="0">
<tr>
<td class="txttop">On Nov 16, 6:24 pm, David King <dk...@ketralnis.com> wrote:
<br />
> > - A while ago somebody asked a similar question and Bryan Fink
<br />
> > suggested returning a tuple of the form {title, Title} from the view
<br />
> > function, and then later picking up this tuple in the
<br />
> > html_container_controller and using its value to set the <title> tag.
<br />
>
<br />
> That does only take into account <title>s, and not any other
<br />
> metadata. And doesn't using erltl preclude returning something useful
<br />
> from a view function other than the data itself? And then the
<br />
> component receiving the rendered page would have to walk the
<br />
> resultant IOlist looking for it, rather than being able to pattern-
<br />
> match it. That just seems very brittle.
<br />
<br />
Yeah, it is a bit brittle. But, some tips:
<br />
<br />
1. If you need to return several things for the container to find,
<br />
just use more tuples. I have {title, X}, {head, X}, {onload, X}, etc.
<br />
<br />
2. ErlTl works just fine with this. The code looks like:
<br />
<br />
<%@ index(Beer) %>
<br />
<% {title, ["BeerRiot - ", beer:name(Beer)]} %>
<br />
<% {head, <<"<script>...</script>">>} %>
<br />
<br />
3. My container controller picks each of these piece out using two
<br />
rules:
<br />
a. all such tuples must be at the start of the rendered data
<br />
b. all such tuples must be in a defined order
<br />
<br />
So, the container code looks roughly like:
<br />
<br />
index(Data) ->
<br />
case Data of
<br />
[{title, Title} | TData] -> ok;
<br />
TData -> Title = "BeerRiot"
<br />
end,
<br />
case TData of
<br />
[{head, Head} | HData] -> ok;
<br />
HData -> Head = <<>>
<br />
end
<br />
...
<br />
{data, {Title, Head, OtherData}}.
<br />
<br />
I have to play a few more tricks, though, to account for newlines in
<br />
the rendered Data list. That could be fixed by moving the ErlTl
<br />
statements all to one line, but it didn't seem important enough to
<br />
worry about.
<br />
<br />
So, that restricts using these tuples to the "top level" component
<br />
view, but it has worked pretty well for me so far.
<br />
<br />
The idea of adding a {meta, X} tuple to the list of things a
<br />
controller can return sounds interesting, but since this stuff is more
<br />
on the view side, it also seems a little out of place. Not to say
<br />
that my hack isn't further out of place, of course. <img src="images/smiles/icon_wink.gif" alt="Wink" border="0" />
<br />
<br />
-Bryan
<br />
<br />
P.S. If you think the idea of a beer_controller is great, you'll love
<br />
that I also have a beer_container_controller, but only because I
<br />
couldn't decide among bottle_controller, can_controller, and
<br />
keg_controller. <img src="images/smiles/icon_smile.gif" alt="Smile" border="0" />
<br />
<br />
--~--~---------~--~----~------------~-------~--~----~
<br />
You received this message because you are subscribed to the Google Groups "erlyweb" group.
<br />
To post to this group, send email to <a href="mailto:erlyweb@googlegroups.com">erlyweb@googlegroups.com</a>
<br />
To unsubscribe from this group, send email to <a href="mailto:erlyweb-unsubscribe@googlegroups.com">erlyweb-unsubscribe@googlegroups.com</a>
<br />
For more options, visit this group at <a href="http://groups.google.com/group/erlyweb?hl=en" target="_blank">http://groups.google.com/group/erlyweb?hl=en</a>
<br />
-~----------~----~----~----~------~----~------~--~---
<br />
<br />
Post recived from mailinglist</td>
</tr>
<tr>
<td class="txtbottom"><span class="edited"></span></td>
</tr>
</table>
</td>
</tr>
<tr>
<td class="row1 five blacklink"><a href="#top">Back to top</a></td>
<td class="row1 six">
</td>
</tr>
<tr>
<td class="row3 one"><a id="34440"></a>Guest</td>
<td class="row3 two">
<table cellspacing="0">
<tr>
<td><a href="viewtopic.php?p=34440&sid=6ad65ce0d8e7e5873bcd5525cbbcee49#34440"><img src="templates/TrapExit/images/icon_minipost.gif" style="width: 12px; height: 9px; border: 0;" alt="" /></a>Posted: Sun Nov 18, 2007 10:41 pm</td>
<td class="txtright"><a href="posting.php?mode=quote&p=34440&sid=6ad65ce0d8e7e5873bcd5525cbbcee49"><img src="templates/TrapExit/images/lang_english/icon_quote.gif" alt="Reply with quote" title="Reply with quote" border="0" /></a> </td>
</tr>
</table>
</td>
</tr>
<tr>
<td class="row2 three">
<span class="avatar"></span>
<span class="block">Guest</span>
<span class="block"></span>
<span class="block"></span>
<span class="block"></span>
<span class="block"></span>
</td>
<td class="row2 four">
<table cellspacing="0">
<tr>
<td class="txttop">>
<br />
> Yoi probably want to change the order of those arguments. If you have
<br />
>
<br />
> fun(ExpandedEwc, Rendered)
<br />
>
<br />
> then you should also have:
<br />
>
<br />
> fun(ExpandedEwc, Rendered, MetaVals)
<br />
>
<br />
> That is, keep the first few arguments consistent for the various
<br />
> forms, and when adding arguments, add them to the end, not the middle.
<br />
<br />
Makes sense. Let's add the parameter at the end. I'm not too worried
<br />
about backwards compatibility, btw. Porting existing apps would
<br />
require a 1 line change.
<br />
<br />
Yariv
<br />
<br />
--~--~---------~--~----~------------~-------~--~----~
<br />
You received this message because you are subscribed to the Google Groups "erlyweb" group.
<br />
To post to this group, send email to <a href="mailto:erlyweb@googlegroups.com">erlyweb@googlegroups.com</a>
<br />
To unsubscribe from this group, send email to <a href="mailto:erlyweb-unsubscribe@googlegroups.com">erlyweb-unsubscribe@googlegroups.com</a>
<br />
For more options, visit this group at <a href="http://groups.google.com/group/erlyweb?hl=en" target="_blank">http://groups.google.com/group/erlyweb?hl=en</a>
<br />
-~----------~----~----~----~------~----~------~--~---
<br />
<br />
Post recived from mailinglist</td>
</tr>
<tr>
<td class="txtbottom"><span class="edited"></span></td>
</tr>
</table>
</td>
</tr>
<tr>
<td class="row2 five blacklink"><a href="#top">Back to top</a></td>
<td class="row2 six">
</td>
</tr>
<tr>
<td class="row3 one"><a id="34688"></a>Guest</td>
<td class="row3 two">
<table cellspacing="0">
<tr>
<td><a href="viewtopic.php?p=34688&sid=6ad65ce0d8e7e5873bcd5525cbbcee49#34688"><img src="templates/TrapExit/images/icon_minipost.gif" style="width: 12px; height: 9px; border: 0;" alt="" /></a>Posted: Sat Nov 24, 2007 5:37 am</td>
<td class="txtright"><a href="posting.php?mode=quote&p=34688&sid=6ad65ce0d8e7e5873bcd5525cbbcee49"><img src="templates/TrapExit/images/lang_english/icon_quote.gif" alt="Reply with quote" title="Reply with quote" border="0" /></a> </td>
</tr>
</table>
</td>
</tr>
<tr>
<td class="row1 three">
<span class="avatar"></span>
<span class="block">Guest</span>
<span class="block"></span>
<span class="block"></span>
<span class="block"></span>
<span class="block"></span>
</td>
<td class="row1 four">
<table cellspacing="0">
<tr>
<td class="txttop">Hi,
<br />
<br />
I took a few days off for Thanksgiving and now I'm back to working on ErlyWeb.
<br />
<br />
As I went back to working one the phased_vars feature, it occurred to
<br />
me that it would probably be cleaner to include them as an element of
<br />
the existing 'response' list rather than in a special return value.
<br />
So, instead of returning
<br />
<br />
{with_phased_vars,
<br />
[{title, "foo"},
<br />
{meta, "bar"}],
<br />
{ewc, navbar, [A]}}
<br />
<br />
you would return
<br />
<br />
{response,
<br />
[{phased_vars,
<br />
[{title, "foo"},
<br />
{meta, "bar"}],
<br />
{body, {ewc, navbar, [A]}}]}.
<br />
<br />
The 'response' tuple already lets you return values that aren't passed
<br />
to the view function. I think we should reuse it.
<br />
<br />
What do you think?
<br />
<br />
Yariv
<br />
<br />
<br />
<br />
On Nov 17, 2007 6:35 PM, David King <dking@ketralnis.com> wrote:
<br />
>
<br />
> > Yeah, I agree. I think 'with_properties' and 'set_properties' sounds
<br />
> > too generic, though. Maybe 'with_meta_vals' or 'with_phased_vals'?
<br />
>
<br />
> I like with_phased_vals, that's relatively clear
<br />
>
<br />
>
<br />
> >
<br />
>
<br />
<br />
--~--~---------~--~----~------------~-------~--~----~
<br />
You received this message because you are subscribed to the Google Groups "erlyweb" group.
<br />
To post to this group, send email to <a href="mailto:erlyweb@googlegroups.com">erlyweb@googlegroups.com</a>
<br />
To unsubscribe from this group, send email to <a href="mailto:erlyweb-unsubscribe@googlegroups.com">erlyweb-unsubscribe@googlegroups.com</a>
<br />
For more options, visit this group at <a href="http://groups.google.com/group/erlyweb?hl=en" target="_blank">http://groups.google.com/group/erlyweb?hl=en</a>
<br />
-~----------~----~----~----~------~----~------~--~---
<br />
<br />
Post recived from mailinglist</td>
</tr>
<tr>
<td class="txtbottom"><span class="edited"></span></td>
</tr>
</table>
</td>
</tr>
<tr>
<td class="row1 five blacklink"><a href="#top">Back to top</a></td>
<td class="row1 six">
</td>
</tr>
<tr>
<td class="row3 pad4 txtright" colspan="2">
<form method="post" action="viewtopic.php?t=10610&start=0&sid=6ad65ce0d8e7e5873bcd5525cbbcee49">
<p>Display posts from previous: <select name="postdays"><option value="0" selected="selected">All Posts</option><option value="1">1 Day</option><option value="7">7 Days</option><option value="14">2 Weeks</option><option value="30">1 Month</option><option value="90">3 Months</option><option value="180">6 Months</option><option value="364">1 Year</option></select> <select name="postorder"><option value="asc" selected="selected">Oldest First</option><option value="desc">Newest First</option></select> <input type="submit" value="Go" class="button" name="submit" /></p>
</form>
</td>
</tr>
</table>
<div class="timezone left"></div>
<div class="timezone right">All times are GMT</div>
<div class="spacing"></div>
<table cellspacing="0" style="width: 100%">
<tr class="lines_3">
<th>
<div class="left">
<a href="viewtopic.php?t=10610&view=next&sid=6ad65ce0d8e7e5873bcd5525cbbcee49">View next topic</a><br />
<a href="viewtopic.php?t=10610&view=previous&sid=6ad65ce0d8e7e5873bcd5525cbbcee49">View previous topic</a>
</div>
<div class="right">
Page <b>1</b> of <b>2</b><br />
Goto page <b>1</b>, <a href="viewtopic.php?t=10610&postdays=0&postorder=asc&start=15&sid=6ad65ce0d8e7e5873bcd5525cbbcee49">2</a> <a href="viewtopic.php?t=10610&postdays=0&postorder=asc&start=15&sid=6ad65ce0d8e7e5873bcd5525cbbcee49">Next</a>
</div>
<div class="clear"></div>
<div class="left">
<span class="nav"><a href="index.php?sid=6ad65ce0d8e7e5873bcd5525cbbcee49">Erlang Forum - Trap Exit Forum Index</a> ~ <a href="viewforum.php?f=24&sid=6ad65ce0d8e7e5873bcd5525cbbcee49">Erlyweb mailing list</a></span>
</div>
</th>
</tr>
</table>
<div class="spacing"></div>
<div class="postbuttons"><a href="posting.php?mode=newtopic&f=24&sid=6ad65ce0d8e7e5873bcd5525cbbcee49"><img src="templates/TrapExit/images/lang_english/reply-locked.gif" alt="This forum is locked: you cannot post, reply to, or edit topics." /></a><a href="posting.php?mode=reply&t=10610&sid=6ad65ce0d8e7e5873bcd5525cbbcee49"><img src="templates/TrapExit/images/lang_english/reply-locked.gif" alt="" /></a></div>
<div class="spacing"></div>
<div class="right"><form method="get" id="jumpbox" action="viewforum.php?sid=6ad65ce0d8e7e5873bcd5525cbbcee49" onsubmit="if(document.jumpbox.f.value == -1){return false;}">
<p>Jump to: <select name="f" onchange="if(this.options[this.selectedIndex].value != -1){ forms['jumpbox'].submit() }"><option value="-1">Select a forum</option><option value="-1"> </option><option value="-1">Erlang</option><option value="-1">----------------</option><option value="23">Erlang</option><option value="7">Open Telecom Platform (OTP)</option><option value="14">Advanced Erlang/OTP</option><option value="20">User Contributions</option><option value="28">Open Source Projects</option><option value="-1"> </option><option value="-1">Trap exit</option><option value="-1">----------------</option><option value="5">Trapexit Forums</option><option value="19">Trapexit News</option><option value="-1"> </option><option value="-1">Mailing lists</option><option value="-1">----------------</option><option value="1">Erlang announce mailing list</option><option value="2">Erlang questions mailing list</option><option value="3">Erlang patches mailing list</option><option value="4">Erlang bugs mailing list</option><option value="11">Yaws mailing list</option><option value="27">Erlang Web mailing list</option><option value="12">Ejabberd mailing list</option><option value="24"selected="selected">Erlyweb mailing list</option><option value="25">RabbitMQ mailing list</option><option value="-1"> </option><option value="-1">User Groups</option><option value="-1">----------------</option><option value="26">Erlang-DACH</option><option value="29">Erlang-Paris</option></select><input type="hidden" name="sid" value="6ad65ce0d8e7e5873bcd5525cbbcee49" /> <input type="submit" value="Go" class="button2" /></p>
</form>
</div>
<div class="clear"></div>
<div class="spacing"></div>
<table cellspacing="0" style="float:left">
<tr>
<td class="txttop">
</td>
<td class="txtright">
You <b>cannot</b> post new topics in this forum<br />You <b>cannot</b> reply to topics in this forum<br />You <b>cannot</b> edit your posts in this forum<br />You <b>cannot</b> delete your posts in this forum<br />You <b>cannot</b> vote in polls in this forum<br />You <b>cannot</b> attach files in this forum<br />You <b>cannot</b> download files in this forum<br />
</td>
</tr>
</table>
<div class="spacing"></div>
<div class="spacing"></div>
<div class="spacing"></div>
<div class="copyright">
<!--
We request you retain the full copyright notice below including the link to www.phpbb.com.
This not only gives respect to the large amount of time given freely by the developers
but also helps build interest, traffic and use of phpBB 2.0. If you cannot (for good
reason) retain the full copyright we request you at least leave in place the
Powered by phpBB line, with phpBB linked to www.phpbb.com. If you refuse
to include even this then support on our forums may be affected.
The phpBB Group : 2002
Do not remove the copyright link to www.mikelothar.com below.
Feel free to rename and/or modify it as long as it still points back to www.mikelothar.com.
Feel free to add a 'Modified by [Your Name]' - or similar - link next to it if you have made changes to the layout.
Feel free to get more information or ask me questions on www.mikelothar.com.
Feel free to feel free.
Mike Lothar : 2004 - 2006
// -->
Hosted by <a href="http://www.erlang-solutions.com/" title="Erlang Solutions">Erlang</a> <a href="http://www.erlang-solutions.com/" title="Erlang Solutions">Solutions</a> | Powered by phpBB and NoseBleed 1.14</div>
</td>
</tr>
</table>
</td>
</tr>
</table>
<script src="http://www.google-analytics.com/urchin.js" type="text/javascript">
</script>
<script type="text/javascript">
_uacct = "UA-235575-2";
_udn = "trapexit.org";
urchinTracker();
</script>
</body>
</html>
| | |
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
