Hi David,

You can currently do what you wanted to do without changing ErlyWeb.
To make your examples work, I would do the following:

[{data, "SomeString"},
 {ewc,...},
 {data, [<<"Some">,["IO","List"]]}]

or even better:

[{data, {"SomeString", [<<"Some">,["IO","List"]]}},
 {ewc,...}]

(The second option shows how to combine multiple data elements under a
single 'data' tuple.)

The rule of thumb is that you can return either a single tuple or a
list of tuples. If the tuple is {data, Data}, the view function gets
only Data in place of the tuple. If the tuple is {ewc,...}, the view
function gets the rendered component in its place. For (nested) lists
of tuples, the transformation applies to each element in the list.

Yariv


On Nov 8, 2007 11:21 PM, David King <[EMAIL PROTECTED]> wrote:
>
> > To further refine my question: is there any way to pass in a mix of
> > IOlists and rendered {ewc} tuples to a view function? Can we turn
> > {data} into this?
>
> Sorry about all of the list traffic. I did figure out how to do this,
> sort of. I added this ewc clause to erlyweb.erl (I'm running 0.6.2,
> but I'm sure this hasn't changed substantially):
>
> ewc({edata, EwcsAndLists}, AppData) when is_list(EwcsAndLists) ->
>    Rendered=lists:map(fun(EwcOrData) ->
>                           case EwcOrData of
>                             Ewc when is_tuple(Ewc) and (element
> (1,Ewc) =:= ewc) ->
>                               render_subcomponent(Ewc,AppData);
>                             Data ->
>                               Data
>                           end
>                       end, EwcsAndLists),
>    {response,[{rendered,Rendered}]};
>
> It effectively adds a new response from controller functions, called
> 'edata', that can be used like this:
>
> {edata, [ "Title",
>            {ewc, post, post_list, [A, Posts ]}]}.
>
> That is, such that {ewc}s and iolists can be mixed. It doesn't
> traverse deep lists though, I suppose that could be added but it
> might be hard to tell an IO-list from a list of {ewc}s without
> actually traversing it. (Deep lists would be useful for my app, but
> that's an exercise for another day)
>
> Is there any chance that we can get this in the main distribution?
> It's pretty simple and shouldn't break anyone's existing apps. I'd
> like to avoid having to maintain my own version :)
>
>
>
> >
> > On 08 Nov 2007, at 20:22, David King wrote:
> >
> >>
> >> What is the difference between returning this:
> >>
> >> ["SomeString",
> >>   {ewc,...},
> >>   [<<"Some">,["IO","List"]]]
> >>
> >> And this:
> >>
> >> {data,["SomeString",
> >>         {ewc,...},
> >>         [<<"Some">,["IO","List"]]]}
> >>
> >> (Other than that the latter doesn't work.) In either case, a view
> >> function like this should work:
> >>
> >> <%@ view([FirstString,RenderedComponent,SomeOtherString]) %>
> >> ...
> >>
> >> The problem is that I can't always just return a {data} tuple or a
> >> [{ewc}] list, I have to differentiate between one that includes
> >> rendered components and one that doesn't, and I worry that the
> >> "detection" between the two may fail when I mix them (for instance,
> >> maybe I want to render a page with a title and a list of items; the
> >> title is a literal string, but the items are rendered {ewc}s). Am I
> >> missing an overarching design that requires a difference between
> >> passing a view function a list of rendered components and a list of
> >> iolists? Is there any way that we can get {data} to look at its
> >> arguments and see if they are {ewc}s, and render them just like it
> >> would if I returned a [{ewc}], so that I can always return a {data}?
> >>
> >>
> >
> >
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"erlyweb" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/erlyweb?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to