out of memory on calling render() - infinite loop?

[Sebastian]

Go @all,

I have discovered an issue while trying out limonade. Calling render()
with only one parameter causes a memory exhaustion error. When calling
with second parameter "null", then it works. What am I doinrong? Or is
this behavior intended? Btw: I assigned a layout using layout().

Thanks a lot in advance for your hints and help.

Greetings

Sebastian

[Fabrice Luraine]

hello,

can you show us your code ?

2010/6/26 Sebastian <sebasti...@googlemail.com>

--
You received this message because you are subscribed to the Google Groups "Limonade" group.
To post to this group, send email to limo...@googlegroups.com.
To unsubscribe from this group, send email to limonade+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/limonade?hl=en.

--
Fabrice Luraine
----------------------
06 62 26 79 71
02 23 42 15 61
http://pok.tumblr.com

[Sebastian]

> can you show us your code ?

Now I can. When I told you of the problem, I was at the beach ;) .

In the index.php essentially is:

function configure() {
option('base_uri', '/');
}

function before() {
layout('layouts/default.html.php');
}

In layouts/default.html.php:

<?php echo(render('shared/_navigation.html.php', null)); ?>
<?php echo($content); ?>

Pretty simple, I guess.

[Baglan]

That explains the out-of-memory situation. If you omit the second parameter, render() uses the default layout and endless cycle is created:

When you call render(), default layout is being used, which calls render() which uses default layout and so on.

null as a second parameter tells framework not to use a layout.

-Baglan

[Sebastian]

> When you call render(), default layout is being used, which calls render() which uses default layout and so on.
> null as a second parameter tells framework not to use a layout.

Ok, I got it. But wouldn't you normally call render() (and html())
without wanting them to render a layout? Isn't this layout rendering
call more an exception than a normal use case?

Thanks for your help so far =) !

Greetings

Sebastian

[Baglan]

I'm not much of an expert, I just had a quick look at the code but I think render() is called internally functions so the actual "normal" case is to use layout. I guess it mirrors the Rails/Sinatra behavior.

In Rails there's also a concept of "partial" for which you explicitly don't want layout to be applied. Passing "null" as a second argument to render() does the same in Limonade - I think it could be a useful shortcut. Something like this:

function partial($content_or_func, $locals)
{
return render($content_or_func, null, $locals);
}

-Baglan

[Sebastian]

Thanks for your reply, Baglan.

> In Rails there's also a concept of "partial" for which you explicitly don't want layout to be applied. Passing "null" as a second argument to render() does the same in Limonade - I think it could be a useful shortcut. Something like this:
>
> function partial($content_or_func, $locals)
> {
>         return render($content_or_func, null, $locals);
>
> }

I'm coming from Rails. I'm having a look at Limonade just because a
friend want's to do a project using PHP (he's hopeless ;) ). And to be
honest: I should have had a look at the code by myself, I guess =| .

Funny thing: I have done pretty much exactly what you suggested: I
wrote a partial() helper function.


Sunny greetings

Sebastian

[Sebastian]

LOL. I just wanted to run the particular code and hey "cannot
redeclare partial" it says. Know what? There is! a partial function in
Limonade do exactly what I want. Cheers!

[Baglan]

Oh, indeed:

/**
* Returns a string to output
*
* Shortcut to render with no layout.
*
* @param string $content_or_func
* @param string $locals
* @return string
*/
function partial($content_or_func, $locals = array())
{
return render($content_or_func, null, $locals);
}

I guess API docs need a bit of brushing up :)

[Fabrice Luraine]

Hello,

I forgot to notice on the website that API covers the 0.4 stable
version, not the edge one.
I will fix that as soon as possible ;-)

++ Fabrice