Mailing List Archive: Bricolage: users

strategy question

Index | Next | Previous | View Threaded

k.rudnik at gmail

Jun 23, 2010, 2:36 AM

Post #1 of 6 (573 views)
Permalink

strategy question

I use various category subtrees to classify my stories (have 5
independent classification orders)
I added some buttons to the Story Edit Category page to filter
suitable subtrees - this makes classification process almost
painless.
Almost every node in the Category tree will have a multipaged Cover
story that will present list of stories
(I need uri, title, author, date, categories, keywords and deck /if
any/ for each story ).
There will be quite a large number of categories and stories in the
near future.
Every story may have up to 5 categories assigned.
After some reading on the list I realized that because of the site
structure republishing of all Covers may be horrible.
So I think of defining Web Meta OC that for every story will burn
small php file (index_meta.inc).
It will containing story's meta information to be included on Cover
pages on server side
Now burning of Covers costs nothing - all I have to do is
@list= ::Story->list();

map{
$m->print(
qq[.
<?php show_story_meta($_); ?> // include index_meta.inc and
render meta box on the fly on server side
]
);
} map{$_->get_uri . "index_meta.inc"} @list;

Do you think it is a good idea?

The only thing that stops me now is that possible mess on my preview server.
(it is easy to forgot to preview a story in the second (meta) output channel).
Is there any way to trigger a preview burn in Web Meta OC while
previewing in Web OC?

thanks in advance

Krzysztof

david at kineticode

Jun 23, 2010, 8:31 AM

Post #2 of 6 (541 views)
Permalink

Re: strategy question [In reply to]

On Jun 23, 2010, at 2:36 AM, Krzysztof Rudnik wrote:

> @list= ::Story->list();
> map{
> $m->print(
> qq[.
> <?php show_story_meta($_); ?> // include index_meta.inc and
> render meta box on the fly on server side
> ]
> );
> } map{$_->get_uri . "index_meta.inc"} @list;
>
> Do you think it is a good idea?

Yes, it's a good idea. I've seen this sort of thing done with a database back end, but using the file system is an even better idea, as it should be much better-performing.

OTOH, if you're still publishing these covers every time a story is published, how much faster is it than including the metadata just once publish time? How does that compare to the time spent by the server pulling in those includes for every single request?

That is to say, how much more work does the front-end have to do to pull this off? And how does that affect your load? It's generally better to use that expense once on the back-end, unless it's not significant on the front-end.

> The only thing that stops me now is that possible mess on my preview server.
> (it is easy to forgot to preview a story in the second (meta) output channel).
> Is there any way to trigger a preview burn in Web Meta OC while
> previewing in Web OC?

You could call $burner->preview_another() in the story template in the Web OC.

Best,

David

bret at pectopah

Jun 23, 2010, 8:56 AM

Post #3 of 6 (554 views)
Permalink

Re: strategy question [In reply to]

> OTOH, if you're still publishing these covers every time a story is published, how much faster is it than including the metadata just once publish time? How does that compare to the time spent by the server pulling in those includes for every single request?
>
> That is to say, how much more work does the front-end have to do to pull this off? And how does that affect your load? It's generally better to use that expense once on the back-end, unless it's not significant on the front-end.

I was wondering the same thing. If the cover itself is the result of a
$story->list(), Doesn't Bricolage still have to do the hard work of
loading all the metadata into memory?

If you needed to extract a bunch of data from subelements I would see
the advantage of this approach. But I'm curious whether it makes much
difference in this case.

Cheers,

Bret

--
Bret Dawson
Producer
Pectopah Productions Inc.
(416) 895-7635
bret [at] pectopah
www.pectopah.com

david at kineticode

Jun 23, 2010, 9:50 AM

Post #4 of 6 (545 views)
Permalink

Re: strategy question [In reply to]

On Jun 23, 2010, at 8:56 AM, Bret Dawson wrote:

> I was wondering the same thing. If the cover itself is the result of a
> $story->list(), Doesn't Bricolage still have to do the hard work of
> loading all the metadata into memory?

It depends on what that metadata is. If it's just the URL, title, and description, yes. But as soon as you start asking it for its elements, it shoots off more queries. If you spelunk into a deep subelement, that could be a lot of queries. No, this is not ideal.

> If you needed to extract a bunch of data from subelements I would see
> the advantage of this approach. But I'm curious whether it makes much
> difference in this case.

Right.

Best,

David

k.rudnik at gmail

Jun 23, 2010, 11:40 AM

Post #5 of 6 (549 views)
Permalink

Re: strategy question [In reply to]

On Wed, Jun 23, 2010 at 6:50 PM, David E. Wheeler <david [at] kineticode> wrote:
> On Jun 23, 2010, at 8:56 AM, Bret Dawson wrote:
>
>> I was wondering the same thing. If the cover itself is the result of a
>> $story->list(), Doesn't Bricolage still have to do the hard work of
>> loading all the metadata into memory?
>
> It depends on what that metadata is. If it's just the URL, title, and description, yes. But as soon as you start asking it for its elements, it shoots off more queries. If you spelunk into a deep subelement, that could be a lot of queries. No, this is not ideal.
>
>> If you needed to extract a bunch of data from subelements I would see
>> the advantage of this approach. But I'm curious whether it makes much
>> difference in this case.

As I said I need uri, title, author, caver_date, categories, keywords
and description for each story.
( just decided to use description instead of deck field to save some resources)

In my case the situation is much more complicated.
I have TeX Action which does quite a heavy and tricky job after burning
(tex compilation, picture generation for math formulas, caching results etc.)
If there are 100 stories in a category then after adding the next one
(story101):
1. in standard approach TeX Action for a Cover would generate pictures
for all (also unchanged) 101 stories - horrible overhead.
2. in the new approach no TeX Action is required because all texing
for story101 has been done during its last preview burning [.there is
nothing to tex in the Cover body at all]

Coming back to the mess in the preview server.
All I want is to trigger preview burning in all other OC's associated
with the story.

form the docs:
$burner->preview_another
....
"Like publish_another(), it will not bother to preview the document
if it's the same story as the currently burning story."

So it will probably not the right way.

Krzysztof

k.rudnik at gmail

Jun 23, 2010, 11:54 AM

Post #6 of 6 (545 views)
Permalink

Re: strategy question [In reply to]

On Wed, Jun 23, 2010 at 8:40 PM, Krzysztof Rudnik <k.rudnik [at] gmail> wrote:
> On Wed, Jun 23, 2010 at 6:50 PM, David E. Wheeler <david [at] kineticode> wrote:
>> On Jun 23, 2010, at 8:56 AM, Bret Dawson wrote:
>>
>>> I was wondering the same thing. If the cover itself is the result of a
>>> $story->list(), Doesn't Bricolage still have to do the hard work of
>>> loading all the metadata into memory?
>>
>> It depends on what that metadata is. If it's just the URL, title, and description, yes. But as soon as you start asking it for its elements, it shoots off more queries. If you spelunk into a deep subelement, that could be a lot of queries. No, this is not ideal.
>>
>>> If you needed to extract a bunch of data from subelements I would see
>>> the advantage of this approach. But I'm curious whether it makes much
>>> difference in this case.
>
> As I said I need uri, title, author, caver_date, categories, keywords
> and description �for each story.
> ( just decided to use description instead of deck field to save some resources)
>
> In my case the situation is much more complicated.
> I have TeX Action which does quite a heavy and tricky job after burning
> (tex compilation, picture generation �for math formulas, caching results etc.)
> If there are 100 stories in a category then after adding the next one
> (story101):
> 1. in standard approach TeX Action for a Cover would generate pictures
> for all (also �unchanged) �101 stories - horrible overhead.
> 2. in the new approach no TeX Action is required because �all texing
> for story101 �has been done during its last preview �burning [.there is
> nothing to tex in the Cover body at all]
>
> Coming back to the mess in the preview server.
> All I want is to trigger preview burning in all other OC's associated
> with the story.
>
> form �the docs:
> $burner->preview_another
> ....
> �"Like publish_another(), it will not bother to preview the document
> if it's the same story as the currently burning story."
>
> So it will probably not the right way.
>
> Krzysztof

May be
$burner->burn_one($story,$story->get_primary_category,
$Web_Meta_OC_obj) if $burner->previewing
would do the job?

k

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads