Mailing List Archive

Joao Pedro,

>
> 2) Manage the non-article content as independent server-side includes.
> You can keep them in Bricolage as media assets, and link them in in
> templates using your preferred include syntax. I'm doing this for
> Macworld.com, where all the navigation, advertising, and banner stuff
> is put into each page at delivery time via server-side includes. This
> is very efficient, both because SSIs are fast and because to change
> any element of the nav, you only need to change the SSI media asset
> and republish it, rather than all of the stories that contain it.
>

I'll also add the hint David gave me recently to insure that what you
preview is what you'll publish:
>
>>
>> Why not just turn on mod_include on your preview server and manage
>> the SSIs as media assets? Publish them to both your production and
>> preview servers, and they should just work.
>>



-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing
your web site with SSL, click here to get a FREE TRIAL of a Thawte
Server Certificate: http://www.gothawte.com/rd524.html
_______________________________________________
Bricolage-General mailing list
Bricolage-General@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bricolage-general

On Thursday, November 14, 2002, at 11:58 AM, drowsy@mac.com wrote:

> I'll also add the hint David gave me recently to insure that what you
> preview is what you'll publish:
>
>>>
>>> Why not just turn on mod_include on your preview server and manage
>>> the SSIs as media assets? Publish them to both your production and
>>> preview servers, and they should just work.

Ah, yeah, I guess I shoulda been more explicit about that. Thanks Mike.

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: To learn the basics of securing
your web site with SSL, click here to get a FREE TRIAL of a Thawte
Server Certificate: http://www.gothawte.com/rd524.html
_______________________________________________
Bricolage-General mailing list
Bricolage-General@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bricolage-general

On Thu, 2002-11-14 at 19:47, David Wheeler wrote:
>
> Personally, I think it's a bad idea to include the destination
> directory as part of the component root in the burner. Formatting
> content in templates should be completely independent of displaying
> content via the resulting files.

Yes, this is probably why we're not that sure the suggestion given
is elegant and safe.


> 1) As Michael says, use cascading autohandlers. If you're using the
> 1.5.0 code base from CVS HEAD, these are known as "category templates"
> (and is what HTML::Template calls them, in any event).

I'll check this out. It seems a nice approach.
What do you think of calling $burner->chain_next when
the Story type isn't of the article type, thus allowing
Cover stories to be treated


>
> 2) Manage the non-article content as independent server-side includes.
> You can keep them in Bricolage as media assets, and link them in in
> templates using your preferred include syntax. I'm doing this for
> Macworld.com, where all the navigation, advertising, and banner stuff
> is put into each page at delivery time via server-side includes. This
> is very efficient, both because SSIs are fast and because to change any
> element of the nav, you only need to change the SSI media asset and
> republish it, rather than all of the stories that contain it.

Well, this would break something that we're using as a Bricolage key
feature: To allow non-technical people to decide which elements are
included and where.

We want to be able to have a place in Bricolage where a manager
will define the structure for the navigation and bars of all the
articles in one category.
The autohandler / "category templates" seems a nice way to do
this.

>
> 3) And finally, if you're using the 1.5.0 code from CVS HEAD, you can
> use "utility templates." These are just arbitrary templates that you
> can include in your code at burn time (via $m->comp in Mason templates,
> or <TMPL_INCLUDE> tags in HTML::Template). Put all of your non-article
> stuff in utility templates, and pull them into your article templates
> when articles are burned. You can also do this with the 1.4.x code now,
> but you have to create elements for the utility templates.

Yes, but how can a manager control the structure of the elements,
including one more link in the navigation bar, without changing
the templates?


--
João Pedro Gonçalves
http://www.sapo.pt/ - Portugal Online



-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing
your web site with SSL, click here to get a FREE TRIAL of a Thawte
Server Certificate: http://www.gothawte.com/rd524.html
_______________________________________________
Bricolage-General mailing list
Bricolage-General@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bricolage-general

Joao Pedro,

You might want to take another look at the SSI option. It seems that
you do need some flexibility, and with extra work, you can use stories
and get your elements back.

You do need to use autohandlers, but there are two big reasons for not
relying on them solely:

1. You would have to republish all stories in a category if you change
the autohandler itself for each change to nav.
This makes the media asset / virtual include much better, you only have
to republish one asset to change the whole category in production.

2. The editable content you want cannot be in an autohandler if you do
not like the media asset level of control. They both have the same
level of hands-on editing, they do not have the ability stories have
for client-side element control.

You can use stories as well as media assets, depending on how much
ongoing editing these includes get. Again, the story approach takes
more planning and care, the media asset route is very plug-and-play,
assuming that you edit the asset outside of bric.

Say you have four categories in a website, including root.

/index.html
/cat1/index.html
/cat2/index.html
/cat3/index.html

then you add an includes category to hold and process the SSI material

/includes

you can use autohandlers to provide that outer layer of html, but
instead of defining all the html, you place an include line in there
like

<!--#include virtual="../includes/cat3navblock/index.html" -->

Each of these includes can be maintained as stories in bricolage.
Then, you can allow apache to virtually include that block of html in
the right spot.

This way, you can allow managers to add links or any element to a block
of html, as a story in the includes category.

We do this to allow people to control subcategory nav and to add
elements to a dropdown navigation aid on every page of a site.

So if you had an autohandler in each category

/autohandler
/cat1/autohandler
/cat2/autohandler
/cat3/autohandler
/includes/ <-- no autohandler, or one that only contains
$burner->chain_next;

each autohandler could place an include call, pointing to an asset in
the includes directory. Just remember to be specific about the
index.html at the end if it exists!

Here is an overly simplfied example. This example assumes that you
want to place different navigation blocks in each category, including
the root.

There is a little bit of bother in that if you have a root-level
autohandler:
1. You'll need to ask that it be ignored when you process something in
the includes category.
2. You'll need to isolate the include for the root, and ignore it if
any other category is present.

/autohandler
------------------
<%once>
my $cat = $story->get_primary_category;
my $gory = $cat->{directory};
</%once>

<%perl>

unless ($gory eq 'includes'){
$m->out(qq{
<html>
<head>
<title>T</title>
</head>
<body>
});

if ($gory eq ''){
$m->out(qq{
<!--#include virtual="includes/rootnavblock/index.html" -->
});

$burner->chain_next; #to the category autohandler or root level story

unless ($gory eq 'includes'){
$m->out(qq{
</body>
</html>
});
</%perl>


/cat1/autohandler
------------------------

<table>
<tr>
<td> This is the outermost table <p/>
<table>
<tr>
<td>
<!--#include virtual="../includes/cat1navblock/index.html" -->
</td>
</tr>
</table>
</td>
<td>
$burner->chain_next; #to the main article
</td>
</tr>
</table>

/cat1/article
----------------
<table>
<tr>
<td>
I'm the article!
</td>
</tr>
</table>


Cheers,
Mike

>>
>> 2) Manage the non-article content as independent server-side includes.
>> You can keep them in Bricolage as media assets, and link them in in
>> templates using your preferred include syntax. I'm doing this for
>> Macworld.com, where all the navigation, advertising, and banner stuff
>> is put into each page at delivery time via server-side includes. This
>> is very efficient, both because SSIs are fast and because to change
>> any
>> element of the nav, you only need to change the SSI media asset and
>> republish it, rather than all of the stories that contain it.
>
> Well, this would break something that we're using as a Bricolage key
> feature: To allow non-technical people to decide which elements are
> included and where.
>
> We want to be able to have a place in Bricolage where a manager
> will define the structure for the navigation and bars of all the
> articles in one category.
> The autohandler / "category templates" seems a nice way to do
> this.



-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing
your web site with SSL, click here to get a FREE TRIAL of a Thawte
Server Certificate: http://www.gothawte.com/rd524.html
_______________________________________________
Bricolage-General mailing list
Bricolage-General@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bricolage-general

On Friday, November 15, 2002, at 03:50 AM, Joao Pedro Goncalves wrote:
>> 1) As Michael says, use cascading autohandlers. If you're using the
>> 1.5.0 code base from CVS HEAD, these are known as "category templates"
>> (and is what HTML::Template calls them, in any event).
>
> I'll check this out. It seems a nice approach.
> What do you think of calling $burner->chain_next when
> the Story type isn't of the article type, thus allowing
> Cover stories to be treated

I don't understand the question. What is an "article type"?

> Well, this would break something that we're using as a Bricolage key
> feature: To allow non-technical people to decide which elements are
> included and where.
>
> We want to be able to have a place in Bricolage where a manager
> will define the structure for the navigation and bars of all the
> articles in one category.
> The autohandler / "category templates" seems a nice way to do
> this.

Uh, well, no. You need to create elements for each of the things that
you want editors to add to the covers. Category templates
(autohandlers) are just a templating thing -- they don't give editors
any control.

>> 3) And finally, if you're using the 1.5.0 code from CVS HEAD, you can
>> use "utility templates." These are just arbitrary templates that you
>> can include in your code at burn time (via $m->comp in Mason
>> templates,
>> or <TMPL_INCLUDE> tags in HTML::Template). Put all of your non-article
>> stuff in utility templates, and pull them into your article templates
>> when articles are burned. You can also do this with the 1.4.x code
>> now,
>> but you have to create elements for the utility templates.
>
> Yes, but how can a manager control the structure of the elements,
> including one more link in the navigation bar, without changing
> the templates?

With that approach, you don't. I had been assuming that you *didn't*
want editors to have that control. But if you do, you need to define
all the elements they're likely to need in the Element Manager, and
then let them add them to a cover story.

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: To learn the basics of securing
your web site with SSL, click here to get a FREE TRIAL of a Thawte
Server Certificate: http://www.gothawte.com/rd524.html
_______________________________________________
Bricolage-General mailing list
Bricolage-General@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bricolage-general

On Friday, November 15, 2002, at 09:57 AM, Michael Slattery wrote:

> Here is an overly simplfied example. This example assumes that you
> want to place different navigation blocks in each category, including
> the root.

Nice example, Michael -- thanks! Minor nits about your root-level
autohandler: *Always* use accessor methods; don't treat Bricolage
objects as hashes -- you may very well be burned by a refactoring later
on. And Second, If you just check the directory name, and you happen to
have a category named "/foo/includes", you won't get what you expect.
Here's how I suggest the root-level autohandler (i.e., category
template) be implemented:

<%once>;
my $cat = $story->get_primary_category;
my $cat_uri = $cat->get_uri;
</%once>

<%perl>;
unless ($cat_uri eq '/includes') {
$m->out(qq{
<html>
<head>
<title>T</title>
</head>
<body>
});

if ($cat->get_directory eq '') {
$m->out(qq{
<!--#include virtual="includes/rootnavblock/index.html" -->
});
}
}
$burner->chain_next;
$m->out(qq{</body>\n</html>\n}) unless $cat_uri eq '/includes';
</%perl>

Regards,

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: To learn the basics of securing
your web site with SSL, click here to get a FREE TRIAL of a Thawte
Server Certificate: http://www.gothawte.com/rd524.html
_______________________________________________
Bricolage-General mailing list
Bricolage-General@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bricolage-general

David,

Great stuff. I'll take that advice!

Mike

> *Always* use accessor methods; don't treat Bricolage objects as
> hashes -- you may very well be burned by a refactoring later on. And
> Second, If you just check the directory name, and you happen to have a
> category named "/foo/includes", you won't get what you expect. Here's
> how I suggest the root-level autohandler (i.e., category template) be
> implemented:
>
> <%once>;
> my $cat = $story->get_primary_category;
> my $cat_uri = $cat->get_uri;
> </%once>
>
>



-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing
your web site with SSL, click here to get a FREE TRIAL of a Thawte
Server Certificate: http://www.gothawte.com/rd524.html
_______________________________________________
Bricolage-General mailing list
Bricolage-General@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bricolage-general

On Fri, 2002-11-15 at 11:50, Joao Pedro Goncalves wrote:
> On Thu, 2002-11-14 at 19:47, David Wheeler wrote:
> >
> > Personally, I think it's a bad idea to include the destination
> > directory as part of the component root in the burner. Formatting
> > content in templates should be completely independent of displaying
> > content via the resulting files.
>
> Yes, this is probably why we're not that sure the suggestion given
> is elegant and safe.
>
>
> > 1) As Michael says, use cascading autohandlers. If you're using the
> > 1.5.0 code base from CVS HEAD, these are known as "category templates"
> > (and is what HTML::Template calls them, in any event).
>
> I'll check this out. It seems a nice approach.
> What do you think of calling $burner->chain_next when
> the Story type isn't of the article type, thus allowing
> Cover stories to be treated

This would do the trick, however, this thread should be read in the
context of "How can I manage the common structure of a site in a way
such day doing minor changes is as easy as editing a story in
bricolage?". Of course it's possible to use bricolage to produce sites
with side-navs, ads, menus, etc, however, How can it be done in a way
that allows non-technical people to easily change the content of those
common parts to all stories?

>
>
> >
> > 2) Manage the non-article content as independent server-side includes.
> > You can keep them in Bricolage as media assets, and link them in in
> > templates using your preferred include syntax. I'm doing this for
> > Macworld.com, where all the navigation, advertising, and banner stuff
> > is put into each page at delivery time via server-side includes. This
> > is very efficient, both because SSIs are fast and because to change any
> > element of the nav, you only need to change the SSI media asset and
> > republish it, rather than all of the stories that contain it.

Yep, but can a nontechnical person use bricolage to change the order in which
those includes show up on the page? Or say, I want to change the logo for the sidenav?

If this solution allows this, then I am probably understanding it wrongly.

We can try to achieve this with our without hacks. For obvious reasons we would rather
do it without hacks ;)

Without hacks I can think of (apart from the solutions already mentioned) of at least one way to do it:

Create a new story type (say skeleton_story)

allow it to be related with whatever elements you see fit (sidenav, ads, media, etc...)

write a top autohandler that via the API get's a "skeleton_story". How this is done is a
matter of convention, for instance we could use the most recent story in the category in
use or something like that.
use the "skeleton_story" template to burn the whole thing passing the story to burn as an argument.

This has the advantages of:
Editing the skeleton_story one can change common content to all stories
No need to relate any elements that mainly specify formating when creating a new story
Content is served static with no SSI.

Drawbacks:
The process of choosing which "skeleton_story" to use when burning is conventional and may be
confusing when several stories exist
Not as fast as SSI at burn time


>
> Well, this would break something that we're using as a Bricolage key
> feature: To allow non-technical people to decide which elements are
> included and where.
>
> We want to be able to have a place in Bricolage where a manager
> will define the structure for the navigation and bars of all the
> articles in one category.
> The autohandler / "category templates" seems a nice way to do
> this.
>

But how does specify how the autohandler outputs without changing it's source directly?


> >
> > 3) And finally, if you're using the 1.5.0 code from CVS HEAD, you can
> > use "utility templates." These are just arbitrary templates that you
> > can include in your code at burn time (via $m->comp in Mason templates,
> > or <TMPL_INCLUDE> tags in HTML::Template). Put all of your non-article
> > stuff in utility templates, and pull them into your article templates
> > when articles are burned. You can also do this with the 1.4.x code now,
> > but you have to create elements for the utility templates.

This is better (in my opinion) than autohandler but lacks the editing abilities we have been discussing.

>
> Yes, but how can a manager control the structure of the elements,
> including one more link in the navigation bar, without changing
> the templates?
>
>

Ideas VERY welcome

Cláudio

> --
> João Pedro Gonçalves
> http://www.sapo.pt/ - Portugal Online
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: To learn the basics of securing
> your web site with SSL, click here to get a FREE TRIAL of a Thawte
> Server Certificate: http://www.gothawte.com/rd524.html
> _______________________________________________
> Bricolage-Devel mailing list
> Bricolage-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bricolage-devel
--
We prefer linguistic vigor over mathematical rigor.
Either you will agree or you won't.
(in Programming Perl, 3rd Edition, page 310 footnote)



-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing
your web site with SSL, click here to get a FREE TRIAL of a Thawte
Server Certificate: http://www.gothawte.com/rd524.html
_______________________________________________
Bricolage-General mailing list
Bricolage-General@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bricolage-general

Claudio,

> This would do the trick, however, this thread should be read in the
> context of "How can I manage the common structure of a site in a way
> such day doing minor changes is as easy as editing a story in
> bricolage?". Of course it's possible to use bricolage to produce sites
> with side-navs, ads, menus, etc, however, How can it be done in a way
> that allows non-technical people to easily change the content of those
> common parts to all stories?

I posted an outline after the post your replied to . It involves SSIs
and real stories that can have all of the authoring, reordering
controls you get in a story. It gives you everything related story
objects might, but without the need to republish any stories that need
a sidebar change, for example.

> Yep, but can a nontechnical person use bricolage to change the order
> in which
> those includes show up on the page? Or say, I want to change the logo
> for the sidenav?

That is an issue of careful element handling, but yes! If the SSIs
are based on stories, then you can reorder containers in any way you
see fit. It sounds like your autohandlers will contain little else but
includes to stories. These can be different depending on the category
and/or subcategories present.

You could even skip autohandlers, and either: place includes right into
your story templates, or create elements that are media assets that
have a fixed include tag in them, like (for apache):
<!--#include virtual="../includes/story4including/index.html" -->
then you could leave it up to users to pick which includes they want,
but that might be too much choice, and backfire in terms of
architecture and consistent editing.

I do not think that the SSI is a hack. It does involve the web server
as part of the whole application, so it might take some
experimentation, but not so scary.

Mike



-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing
your web site with SSL, click here to get a FREE TRIAL of a Thawte
Server Certificate: http://www.gothawte.com/rd524.html
_______________________________________________
Bricolage-General mailing list
Bricolage-General@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bricolage-general

On Tuesday, November 19, 2002, at 09:29 AM, Cláudio Valente wrote:

> Yep, but can a nontechnical person use bricolage to change the order
> in which
> those includes show up on the page? Or say, I want to change the logo
> for the sidenav?

No, but there are two solutions to this problem:

1. A Sidenav element can be added to each story by the non-technical
person and just like any other element. This is good if you need
control on a story-by-story basis, not not too efficient if the Sidenav
needs to be the same for, say, all the stories in a given category.

2. You create a Sidenav story type, briefly described in my last mail.
The non-technical person can edit it on a per-category basis. Then, in
the template for each story, you can find it and link it in, either as
a SSI or inline as I demonstrated in my last mail. Here's how to find
it.

my $cat_id = $burner->get_cat->get_id;
my $ssi_story =
(Bric::Biz::Asset::Business::Story->list
({ element__id => $eid,
publish_status => 1,
category_id => $cat_id }))[0];

# SSI.
my $uri = $ssi_story->get_primary_uri;
$m->out(qq{<!--#include virtual="$uri"-->\n});

# Inline
{
local $story = $ssi_story;
$burner->display_element($ssi_story->get_tile);
}

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: To learn the basics of securing
your web site with SSL, click here to get a FREE TRIAL of a Thawte
Server Certificate: http://www.gothawte.com/rd524.html
_______________________________________________
Bricolage-General mailing list
Bricolage-General@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bricolage-general

On Tuesday, November 19, 2002, at 10:19 AM, Michael Slattery wrote:

> I do not think that the SSI is a hack. It does involve the web server
> as part of the whole application, so it might take some
> experimentation, but not so scary.

You can also include other stories at burn time.

# ID 2222 is your include story, in which an editor can
# whatever she likes. Use whatever method you need to to
# construct it.
my $ssi_story = Bric::Biz::Asset::Business::Story->lookup({ id => 2222
});
$burner->display_element($ssi_story->get_tile);

Of course, this doesn't give you access to the SSI story in the
template that formats the story...but you can get that, too (I think):

{
local $story = $ssi_story;
my $ssi_story = Bric::Biz::Asset::Business::Story->lookup({ id =>
2222 });
$burner->display_element($ssi_story->get_tile);
}

But I actually prefer to have the SSI story output a separate document
that can be included via a SSI call, as then you just have to republish
the SSI story to update the entire category.

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: To learn the basics of securing
your web site with SSL, click here to get a FREE TRIAL of a Thawte
Server Certificate: http://www.gothawte.com/rd524.html
_______________________________________________
Bricolage-General mailing list
Bricolage-General@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bricolage-general