> 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