By Date: <-- -->
By Thread: <-- -->

using xar:set to include a file



Ryan Walker wrote:
> Hi all,
> To get an include in my page, I'm doing this...
> 
> <xar:set name="sidebar">require('/path/to/sidebar.inc');</xar:set>
> 
> ...and it has the desired effect.  But if I do this...
> 
> <xar:set name="sidebar">require('/path/to/sidebar.inc');</xar:set>
> #$sidebar#
As in Brians msg, $sidebar is the return value of the require() (true 
in your case) You can use this fact too:

<xar:if condition="include_once('/path/to/fancy.inc')">
   <!-- we got our fancy stuff -->
<xar:else/>
   <!-- hmm, we didnt -->
</xar:if>

include(_once) is preferred over require imo, so you get a chance to 
react on failure. If i remember correctly, require just issues a fatal 
error and bombs out.

> 
> ...the include works, but there's also a number "1" in the output.  The 
> latter seems more correct to me, whereas I don't understand why the 
> former would have the desired effect... so I'm wondering, is it safe to 
> do the former?  I mean, it's not causing me any problems, but I just 
> wonder if there's any reason not to depend on that approach.
> 

The starting point is that we would like to have a separation of 
'template space' and 'php code space'. Most, if not all, code has been 
  cleared from direct html usage and everything rendered comes from a 
template.

Similarly, we would like to keep php code out of the template space as 
much as possible. As templating is the 'customisation end point' this 
is much harder to do. It's always tempting to 'just do this with a 
xar:set and some php' and be done with it.

The construct to use php in xar:set and in expressions in xar:if, 
xar:while etc. is likely to stay, as we all depend on it now. Over 
time constructs may indeed be added to make the Blocklayout template 
language more rich, so it's less frequently needed to revert to direct 
php, or when it is needed there will be more 'intuitive' ways than 
just xar:set. (like handling <?php ...?> directly in a safe and 
controllable way )

marcel
_______________________________________________
Xaraya_devel mailing list
Xaraya_devel (at) xaraya.com
http://xaraya.com/mailman/listinfo/xaraya_devel