Macros are very well. It solved my problem. But I added something to solution: We needed plugin-like system to handle "what will assign" by template, not php. Plugin's html assigns will be sent when if only plugin is used on template. So, finally I use a system like this:

<div metal:use-macro="plugins.xhtml/promoters" tal:define="promoteAssings plugin/get_promoters/page_id/10/orientation/1/loads" />

Here, plugin don't send any html. It sends only assign data to promoteAssigns variable. And we are using promoteAssigns variable in plugins.xhtml template.

This solved my problem. But maybe someone knows better way.

Thank you so much. And sorry my poor English..

Murat Çorlu

Kornel Lesiński yazmış:
On 02-09-2009 at 10:39:11 Murat Çorlu <> wrote:

We have a problem. We have a master page and a plugin simulation that renders some another templates to called from. For example;

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "";>
<div tal:replace="plugin/get_promoters/page_id/10/orientation/1/loads" />

plugin is an object that has a getter magic function. It handles that parameters and execute-return another template like this:

<tal:block tal:condition="php: orientation==2">
    <ul class="thumbView verticalPromoters">

When we ran this, PHPTAL adds a DOCTYPE tag more to infront of second template. I didn't understand the problem. Can you give a suggestion?

DOCTYPE and XML declaration are stored in PHPTAL's execution context (like a global variable that's prepended to all output) to allow subpages without DOCTYPE to call external macro that defines page layout and adds DOCTYPE, and you've caught PHPTAL red-handed by calling execute() on PHPTAL instance that has already seen a DOCTYPE.

I've added workaround for it in SVN. Try it out:
svn co phptal

Consider using more TAL-friendly macros, something like:

<div metal:use-macro="plugins.xhtml/promoters" tal:define="page_id '10'; orientation '1'"/>

PHPTAL mailing list

Reply via email to