k.rudnik at gmail
Oct 27, 2008, 3:59 PM
Post #4 of 8
(1557 views)
Permalink
|
|
Re: LaTeX Story document model and management
[In reply to]
|
|
thanks Terence,
but it is not quite clear to me (I need some reading).
At the end of publish process you call slave story, set up it's resources,
and publish it through is oc.
Slave story knows who initialized it's burning process (notes), gets
master's data
and does the job. correct?
There is something I ma not ready yet (need more reading and practice).
Can not this be done If a story'd have two different output channels assigned?
(probably not I am afraid, which proves I am a real newbie)
I think, I probably need something different.
In my case: story data must go through tex_compilation output channel
before it can be published or previewed correctly.
Compilation is time consuming so the results should be cached for any repreview
or republish.
Krzysztof
On Mon, Oct 27, 2008 at 7:55 PM, bodola, terence
<terence.bodola [at] cbsparamount> wrote:
>
> "So you want to use one output channel for preprocessing and another for
> final processing? Hrm. I don't think that output channels execute in a
> defined order."
>
> We get around this by using publish_another and passing what we need
> from one element/story/template to the other with notes, or stored in a
> separate mysql db sometimes. Then these two different
> elements/stories/templates can have separate output channels and
> destinations. So, for our element for the story that is the
> publish_another story we'll use the slug for the file name and set it in
> the preceding story (shown below as the cleanup block for preceding
> story) and make sure we clear the resource before republish (so that our
> ftp publish, which is set to delete before put, doesn't delete the last
> file first even though they are actually different files. You could be
> even more clever and make sure you know if it matches the name of last
> one published so that if your ftp server really needs delete before put
> it would still work on republish. This didn't seem necessary for us.)
> The second story for us is just a container story to launch execute of
> the template on whatever output channel/destination.
>
> <%cleanup>
> if($burner->get_mode == PUBLISH_MODE) {
> my $bric_id = $story->get_id;
> my $slug = $story->get_slug;
> $burner->clear_notes();
> $burner->notes(bric_id => $bric_id);
> if(my @whateverstory =
> $story->list({uuid=>"06977C68-7452-11DD-8358-255863A74C6D"})) {
> if(my @resource_id = Bric::Dist::Resource->list({story_id =>
> $whateverstory[0]->get_id})) {
> foreach my $resid (@resource_id) {
> $resid->del_story_ids($whateverstory[0]->get_id)->save;
> }}
> $whateverstory[0]->set_slug($bric_id . $slug);
> $whateverstory[0]->save;
> $burner->publish_another($whateverstory[0]);
> }}
> $burner->clear_notes();
> </%cleanup>
>
> then in the publish_another story template
>
> <%perl>
> my ($bric_id,$asset);
> if($bric_id = $burner->notes('bric_id')) {
> $asset = $story->lookup( { id => $bric_id });
> }
>
> ...
>
> </%perl>
>
>
>
> I think in direct mode this would always work, but in queued mode you
> might still get into precedence problems if your first story/template
> takes longer to execute than your second. You might have to further
> ensure in the second template that the first job had gone through
> already somehow. Some sort of http client 200 check and a loop in the
> second template waiting for finished pub on first...or that and a parse
> for a comment that occurs at the end of the live preceding file to be
> sure it is fully there? You could probably also use a Bricolage jobs
> check loop like
>
> $count = 0;
> while((Bric::Util::Job->list({story_id => $bric_id})) and ($count < 10))
> {
> $count++;
> sleep(2);
> }.
>
> or you could maybe be more specific about the actual job instance to
> make sure a republish of the preceding while the publish_another isn't
> done doesn't goof things
>
> Terence
>
> -----Original Message-----
> From: David E. Wheeler [mailto:david [at] kineticode]
> Sent: Monday, October 27, 2008 10:24 AM
> To: users [at] lists
> Subject: Re: LaTeX Story document model and management
>
> On Oct 25, 2008, at 05:07, Krzysztof Rudnik wrote:
>
>> I installed 1.11.1 and for the last 2 weeks I've read everything about
>
>> Bricolage. I have the feeling that Biricolage would be the perfect
>> choice, even if there are opinions that it is almost dead (correct me
>> if I am wrong).
>
> I think that the release of 1.11.1 a few weeks ago proves that it's not
> dead, eh?
>
>> Another feeling is that I can't feel Bric's "way of life" yet, and I
>> am sure that without little help from experienced users I'll make
>> serious strategic mistakes. I really miss for something like
>>
>> make installdemo
>>
>> after which all that nice ideas (i.e how to build site from scratch,
>> manage server side includes, clever media documents management and
>> other "good practice" tips) well hidden in the mailing lists, wiki's
>> etc.could be seen and touched directly.
>
> Yeah, there are some folks who want to do something like this, but tuits
> are in short supply.
>
>> I can imagine the following scenario:
>>
>> 1. define LaTeX_Story document model containing subelements with latex
>> code: tex_paragraph, tex_display_equation, tex_theorem, tex_proof etc.
>
> If it's easy for your editors to write in tex, then that should work
> pretty well.
>
>> 2. define "tex2html_pre" output channel for preprocessing
>> LaTeX_Stories. In this oc one latex file would be constructed and
>> compiled by tex4ht. This file would contain latex code from story's
>> subelement's fields and some extra latex code allowing precise
>> identification of html pieces in the tex4ht final output.
>
> Sounds reasonable.
>
>> Finally, tex_hash of the form (element_id.field_name => generated
>> html) would be build and stored on disk to be used later during all
>> successive publish and preview requests of the same version of the
>> story . All graphics for math presentation with unique (md5) names
>> would be copied to a directory accessible for the local preview
>> server.
>
> So you're talking about caching the results of burns? Sounds
> interesting, though I'm not sure I really follow.
>
>> 3. define tex2html_final in which LaTeX_Story would be prcessed
>> normally but instead of field's values of any tex* element suitable
>> preprocessed tex_hash value would be used.
>>
>> It'd be perfect, if at the beginning of the tex2html_final oc,
>> preprocessing through tex2html_pre could be triggered.
>
> So you want to use one output channel for preprocessing and another for
> final processing? Hrm. I don't think that output channels execute in a
> defined order.
>
>> 4. There is a problem: how to transportat at the right time all
>> graphics files for math presentation that bric does't know about to
>> the external presentation server.
>
> Ideally how would you like it to work?
>
>> If the above scenario is sensible than one could the most from bric
>> (reach media illustrations, bulk edit etc) and from latex (automatic:
>> numbering of items, multipage's cross references, footnotes, tables of
>
>> content etc.)
>>
>> I know that the above LaTeX_Story is too long but hope somebody
>> reached this point.
>> What do you think about it?
>
> I'm not familiar with TeX myself, but it sound pretty reasonable, though
> I didn't really follow every step...anyone else know TeX and have
> suggestions?
>
> Best,
>
> David
>
|
