Mailing List Archive

On Monday, December 2, 2002, at 07:03 AM, Sean Courtney wrote:

> I am trying to 'burn' other element templates from the
> autohandler. What are some samples of code that
> 'calls' other elements and their templates from an
> autohandler? I am using mason as the burner. For
> example, I want to call header, footer, and nav
> elements.

If they're elements, you can associate them with the story element as
sub-elements, then add them to the story in the story profile, and then
you'll be able to retrieve and burn them just like any other element.

If they don't need to be elements, because editors don't need to edit
them, then you can just write them into the autohandler itself. If you
check out Bricolage from CVS HEAD, where 1.5 is in development, you can
also use "Utility Templates" to create them. Just create the utility
template with your header code, and then call it like a normal Mason
component:

<& /path/to/header.mc &>

If the header, footer, and nav are managed as stories themselves, you
can either publish them separately and then use a delivery-time
technology such as server-side includes to pull them in:

<!--# include virtual="/path/to/header.inc" -->

Or look them up and pull them into the story you're currently burning
by faking it into thinking it's actually burning the other story:

{
local $story = $header_story;
$burner->display_element($header_story->get_tile);
}

> My templates require the use of 'images' and 'style
> sheets.' In 'preview' my templates look poor because
> they are trying find images and a style sheet, but can
> not. What is the best way to resolve this?

Load them into Bricolage as media objects. For the style sheet, create
a new media type "CSS" or some such, create a media object for that
style sheet and upload the actual CSS document, and then preview it and
publish it. Then just pull it into your story as you normally would
from the location where you've published it to. Similarly for images.
If your images are content-specific, however, you should link images
into the story using "Related Media" elements. Then create the template
for the related media element that knows how to pull in the media
object, grab its URL, and include it in the output of your story. See
Bric::AdvTemplates for more information.

http://bricolage.cc/docs/Bric/AdvTemplates.html

HTH,

David

--
David Wheeler AIM: dwTheory
david@wheeler.net ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: Theory@jabber.org



-------------------------------------------------------
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
_______________________________________________
Bricolage-General mailing list
Bricolage-General@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bricolage-general

Hi Sean,

> I am trying to 'burn' other element templates from the
> autohandler. What are some samples of code that
> 'calls' other elements and their templates from an
> autohandler? I am using mason as the burner. For
> example, I want to call header, footer, and nav
> elements.
>


If you have elements in your autohandler, you should be able to access
them as with any template:
foreach my $e ($element->get_elements) {
if ($e->has_name('header')) {
$burner->display_element($e);
}
}

which supposes you have a header.mc template to call.



> My templates require the use of 'images' and 'style
> sheets.' In 'preview' my templates look poor because
> they are trying find images and a style sheet, but can
> not. What is the best way to resolve this?

(NOTE: I just saw David's reply as I was hitting send. Pre-loading
your assets is certainly a good long-term solution. What I've got
below may be a short-term solution.)

We had the same issue, where none of our images and css were placed in
Bricolage as assets, rather they lived on their own dev and production
servers. They are very stable entities, and numerous, so we weren't
going to add them as bricolage media assets to begin with.

I use PERL_LOADER to create a global hash with a full proto:host/path
to my images and css. then I use them in every template.

This way, I can define once what the full URL will be, and change it
when I need to.

The quickest improvement I'll be making is I'll be using the new 'mode
awareness' to toggle this for preview and publication, so each
production server copy can use a relative path upon publication. ( Of
course, if these were assets, I shouldn't have to. )

Here's how it goes:

I create a quick perl module to hold the data I want available, then
add it to the PERL_LOADER directive in bricolage.conf

bricolage.conf
------------------------------------------------------------------------
--------
PERL_LOADER = use Bric::AngelGlobals;



/usr/local/lib/perl5/site_perl/5.6.1/Bric/AngelGlobals.pm:
------------------------------------------------------------------------
--------
use vars qw($extsrvr);

$extsrvr = {
css => 'http://www.myserver.org',
img => 'http://www.myserver.org',
rsa => 'https:/secure. myserver.org',
srch => 'http://www.myserver.org/cgi-dig/htsearch.cgi',
};

Then in my templates:
------------------------------------------------------------------------
--------
<SCRIPT language="javascript"
src="$extsrvr->{css}/scripts/stylesheets.js"></SCRIPT>


If you change anything in your globals file, you'll need to restart
bric.



-------------------------------------------------------
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
_______________________________________________
Bricolage-General mailing list
Bricolage-General@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bricolage-general

Hi Sean,

> I am trying to 'burn' other element templates from the
> autohandler. What are some samples of code that
> 'calls' other elements and their templates from an
> autohandler? I am using mason as the burner. For
> example, I want to call header, footer, and nav
> elements.
>


If you have elements in your autohandler, you should be able to access
them as with any template:
foreach my $e ($element->get_elements) {
if ($e->has_name('header')) {
$burner->display_element($e);
}
}

which supposes you have a header.mc template to call.



> My templates require the use of 'images' and 'style
> sheets.' In 'preview' my templates look poor because
> they are trying find images and a style sheet, but can
> not. What is the best way to resolve this?

(NOTE: I just saw David's reply as I was hitting send. Pre-loading
your assets is certainly a good long-term solution. What I've got
below may be a short-term solution.)

We had the same issue, where none of our images and css were placed in
Bricolage as assets, rather they lived on their own dev and production
servers. They are very stable entities, and numerous, so we weren't
going to add them as bricolage media assets to begin with.

I use PERL_LOADER to create a global hash with a full proto:host/path
to my images and css. then I use them in every template.

This way, I can define once what the full URL will be, and change it
when I need to.

The quickest improvement I'll be making is I'll be using the new 'mode
awareness' to toggle this for preview and publication, so each
production server copy can use a relative path upon publication. ( Of
course, if these were assets, I shouldn't have to. )

Here's how it goes:

I create a quick perl module to hold the data I want available, then
add it to the PERL_LOADER directive in bricolage.conf

bricolage.conf
------------------------------------------------------------------------
--------
PERL_LOADER = use Bric::AngelGlobals;



/usr/local/lib/perl5/site_perl/5.6.1/Bric/AngelGlobals.pm:
------------------------------------------------------------------------
--------
use vars qw($extsrvr);

$extsrvr = {
css => 'http://www.myserver.org',
img => 'http://www.myserver.org',
rsa => 'https:/secure. myserver.org',
srch => 'http://www.myserver.org/cgi-dig/htsearch.cgi',
};

Then in my templates:
------------------------------------------------------------------------
--------
<SCRIPT language="javascript"
src="$extsrvr->{css}/scripts/stylesheets.js"></SCRIPT>


If you change anything in your globals file, you'll need to restart
bric.



-------------------------------------------------------
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
_______________________________________________
Bricolage-General mailing list
Bricolage-General@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bricolage-general

On Monday, December 2, 2002, at 10:20 AM, Michael Slattery wrote:

> (NOTE: I just saw David's reply as I was hitting send. Pre-loading
> your assets is certainly a good long-term solution. What I've got
> below may be a short-term solution.)

And really, it's the best solution if you want to use Bricolage to
truly maintain every aspect of your web site.

> The quickest improvement I'll be making is I'll be using the new 'mode
> awareness' to toggle this for preview and publication, so each
> production server copy can use a relative path upon publication.

This feature is available now in CVS HEAD, and will be in the 1.6.0
release. No date on that yet -- I want to get Mason 1.1x support in and
well-tested, first.

Best,

David

--
David Wheeler AIM: dwTheory
david@wheeler.net ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: Theory@jabber.org



-------------------------------------------------------
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
_______________________________________________
Bricolage-General mailing list
Bricolage-General@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bricolage-general