nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Child TPL to Parent TPL communication

Aryan

Hello All,

Is it possible to pass variables/entities from a child TPL to a parent tpl?

I have used iw_include tag to include a child TPL in a parent TPL.

What I want to acheve is this:

I need to set an extended attribute on the generated HTML. The value for the extended attribute is a comma seperated list of values which come from various child TPLs. I need to Get these values in the parent TPL and set it on the generated HTML.

I want to set the value only once and I dont want to call iwextattr again and again in each child TPL.

Thanks,

Aryan.

Find more posts tagged with

Comments

garima

Hi ,

Just wanted to know if iwextattr can be directly called from the tpl file or it needs to be in a perl file which wud be called by the TPL

Aryan

you can run any command ion the TPL by putting the same between two "back quotes" - ``

margin_test.rptdesign

margin_test.pdf

margin_test.doc

Adam Stoller

you can run any command ion the TPL by putting the same between two "back quotes" - ``

FWIW: It's clearer for code-reading to use

qx(...);

rather than

`...`;

This doesn't answer the original question though - which is passing information back from a child PT to a parent PT. I'm not sure that such a mechanism exists per-se - you might be able to hack a solution using that concept, but another possibility is to code your PTs in Perl and replace your "child PTs" with Perl modules instead - that way it would be more like calling a library function from within your "parent" PT and you can pass information back and forth as you please.

Aryan

Is have tried that. It works. Thanks a lot.

Aryan

Can I use iwpt_dcr_value() method inside a PT?? I think not.

How do I get the DCR values in the PM then?

Please advice.

Nicholas

You can use iwpt_dcr_value() method in PT and once you fetch the values you send them as parameter.

Hope this help

Aryan

I thought as much. I have something very similar to that.Thanks a lot.

But Ghoti says this:

replace your "child PTs" with Perl modules instead

If I am going to get all the values in the PT itself, Iam not "replacing" my child PTs.

Ghoti must have meant SOMETHING when he used the word "replace".

Nicholas

I am not sure about this. He would number the advantages.

Thanks Nicholas

Aryan

[I thought as much. I have something very similar to that.Thanks a lot.

But Ghoti says this:

Quote:
replace your "child PTs" with Perl modules instead

If I am going to get all the values in the PT itself, Iam not "replacing" my child PTs.

Ghoti must have meant SOMETHING when he used the word "replace"./QUOTE]

[QUOTE]I am not sure about this. He would number the advantages.

Thanks Nicholas

Could you please elobortate your reply???

Nicholas

As you said - Ghoti must have meant SOMETHING when he used the word "replace".

So I meant, he could list the advantages.

Thanks Nicholas

Adam Stoller

As you said - Ghoti must have meant SOMETHING when he used the word "replace".

So I meant, he could list the advantages.

Thanks Nicholas

I thought I was being clear, but I guess I wasn't.

Right now you have an architecture of:

parent-PT does some processing and output and then includes a child-PT which does some more processing and output, when the child is done you want its results to be available for the parent where it picks up after the child has ended.

Perhaps it works just that way and you have nothing special to do for passing values back from child-to-parent. But from the original description it didn't sound like that had worked.

So - I suggest changing the relationship of parent-child to one more of core_code-library_code where the processing you used to do in your child PT is now done in a library module. In general, the code in the module should process, and perhaps format, but never output. Instead it should return the processed and/or formatted data to the core code which can also process and format, but further can combine and ultimately output.

If you write your PTs in Perl and create Perl Modules for doing the repetitive and/or highly-specialized functions you need - you can pass information back-and-forth between the code code and the module functions - because it's Perl.

If you write your PTs in XML you're (IMO) limiting your flexibility by using a preprocessor approach where you have some code in the parent PT that sets some context surrounding an inclusion of a child PT but for which there is, apparently, no clear mechanism for returning context / resulting data from the included child PT back to the parent.

As it is, I've never written a PT using an include directive - so I might be missing some of its finer points. I've always written my PTs in Perl and either write the subrountines I want directly in the PT or reference ones that I've built up into modules for reuse.

jkm

somewat on similar lines .. we can pass parameters using iw_include tag but if I want to pass the iteration handle then how do we pass to child tpl?

example code is
[HTML]

[/HTML]

abc.tpl
I want to get the 'body' handle here and process some part of dcr.

Please dont go by the syntax of this example here as I just put these lines to communicate the idea.

Tim__D

Confirming what Ghoti is saying I have run into this sort of thing before also. To get code and formatting reuse within a tpl the logical two items to use are a .pm or a component pt. Its been my experience that .pm come in handy for commonly used or complex sub routines that may need to exist in parent and child tpl files.

That being said I use iw_include a heck of a lot as well. When using these its a one way street $iw_param{this} = "that"; Parent --> Child not the other way around. My suggestion for most things call .pm files to do the heavy lifting in the parent pt and either iw_param the result to the child pt or call the .pm directly from the child. If you set it up right there is nothing preventing you from calling the .pm from both child and parent pts.

Hope this helps.