Product-component structure

Product-component structure

[Aditya Mahajan]

Hi,

This is based on a question on tex.sx:
http://tex.stackexchange.com/q/316504/323

In file-job.lua, we have:

local processors = utilities.storage.allocate {
     ...
     [v_product] = {
         [v_text]        = { "many", processfilemany },
         [v_project]     = { "once", processfileonce },
         [v_environment] = { "once", processfileonce },
         [v_product]     = { "many", processfilemany },
         [v_component]   = { "many", processfilemany },
     },
     [v_component] = {
         [v_text]        = { "many", processfilemany },
         [v_project]     = { "once", processfileonce },
         [v_environment] = { "once", processfileonce },
         [v_product]     = { "none", processfilenone },
         [v_component]   = { "many", processfilemany },
     }
}

Then, why is the product file processed multiple times?

Aditya
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: Product-component structure

[Hans Hagen]

On 6/24/2016 9:19 PM, Aditya Mahajan wrote:
> Hi,
>
> This is based on a question on tex.sx:
> http://tex.stackexchange.com/q/316504/323
>
> In file-job.lua, we have:
>
> local processors = utilities.storage.allocate {
>     ...
>     [v_product] = {
>         [v_text]        = { "many", processfilemany },
>         [v_project]     = { "once", processfileonce },
>         [v_environment] = { "once", processfileonce },
>         [v_product]     = { "many", processfilemany },
>         [v_component]   = { "many", processfilemany },
>     },
>     [v_component] = {
>         [v_text]        = { "many", processfilemany },
>         [v_project]     = { "once", processfileonce },
>         [v_environment] = { "once", processfileonce },
>         [v_product]     = { "none", processfilenone },
>         [v_component]   = { "many", processfilemany },
>     }
> }
>
> Then, why is the product file processed multiple times?

because one might want to combine products (controlled by modes giving 
different results) .. mostly downward compatible

-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
       tel: 038 477 53 69 | www.pragma-ade.com | www.pragma-pod.nl
-----------------------------------------------------------------
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: Product-component structure

[Wolfgang Schuster]

[-- Attachment #1.1: Type: text/plain, Size: 1381 bytes --]

> Aditya Mahajan <mailto:adityam@umich.edu>
> 24. Juni 2016 um 21:19
> Hi,
>
> This is based on a question on tex.sx:
> http://tex.stackexchange.com/q/316504/323
>
> In file-job.lua, we have:
>
> local processors = utilities.storage.allocate {
>     ...
>     [v_product] = {
>         [v_text]        = { "many", processfilemany },
>         [v_project]     = { "once", processfileonce },
>         [v_environment] = { "once", processfileonce },
>         [v_product]     = { "many", processfilemany },
>         [v_component]   = { "many", processfilemany },
>     },
>     [v_component] = {
>         [v_text]        = { "many", processfilemany },
>         [v_project]     = { "once", processfileonce },
>         [v_environment] = { "once", processfileonce },
>         [v_product]     = { "none", processfilenone },
>         [v_component]   = { "many", processfilemany },
>     }
> }
>
> Then, why is the product file processed multiple times?
The rules for a component files are applied *after* \startcomponent
which isn’t the case for the example where in the first iteration
the "text" rules are applied and in the following iteration the rules
for a product file.

Moving \product … after \startcomponent prevents the loop but
the environment won’t be loaded anymore because the product
file isn’t loaded anymore.

Wolfgang

[-- Attachment #1.2: Type: text/html, Size: 2660 bytes --]

[-- Attachment #2: Type: text/plain, Size: 485 bytes --]

___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: Product-component structure

[Aditya Mahajan]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1647 bytes --]

On Sat, 25 Jun 2016, Wolfgang Schuster wrote:

>> Aditya Mahajan <mailto:adityam@umich.edu>
>> 24. Juni 2016 um 21:19
>> Hi,
>> 
>> This is based on a question on tex.sx:
>> http://tex.stackexchange.com/q/316504/323
>> 
>> In file-job.lua, we have:
>> 
>> local processors = utilities.storage.allocate {
>>     ...
>>     [v_product] = {
>>         [v_text]        = { "many", processfilemany },
>>         [v_project]     = { "once", processfileonce },
>>         [v_environment] = { "once", processfileonce },
>>         [v_product]     = { "many", processfilemany },
>>         [v_component]   = { "many", processfilemany },
>>     },
>>     [v_component] = {
>>         [v_text]        = { "many", processfilemany },
>>         [v_project]     = { "once", processfileonce },
>>         [v_environment] = { "once", processfileonce },
>>         [v_product]     = { "none", processfilenone },
>>         [v_component]   = { "many", processfilemany },
>>     }
>> }
>> 
>> Then, why is the product file processed multiple times?
> The rules for a component files are applied *after* \startcomponent
> which isn’t the case for the example where in the first iteration
> the "text" rules are applied and in the following iteration the rules
> for a product file.
>
> Moving \product … after \startcomponent prevents the loop but
> the environment won’t be loaded anymore because the product
> file isn’t loaded anymore.

So, what's the recommended alternative? One could move the \environment to 
the components, but that can lead to a lot of repetitions (if there are 
many environments).

Aditya

[-- Attachment #2: Type: text/plain, Size: 485 bytes --]

___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: Product-component structure

[Hans Hagen]

On 6/25/2016 10:42 AM, Aditya Mahajan wrote:
> On Sat, 25 Jun 2016, Wolfgang Schuster wrote:
>
>>> Aditya Mahajan <mailto:adityam@umich.edu>
>>> 24. Juni 2016 um 21:19
>>> Hi,
>>>
>>> This is based on a question on tex.sx:
>>> http://tex.stackexchange.com/q/316504/323
>>>
>>> In file-job.lua, we have:
>>>
>>> local processors = utilities.storage.allocate {
>>>     ...
>>>     [v_product] = {
>>>         [v_text]        = { "many", processfilemany },
>>>         [v_project]     = { "once", processfileonce },
>>>         [v_environment] = { "once", processfileonce },
>>>         [v_product]     = { "many", processfilemany },
>>>         [v_component]   = { "many", processfilemany },
>>>     },
>>>     [v_component] = {
>>>         [v_text]        = { "many", processfilemany },
>>>         [v_project]     = { "once", processfileonce },
>>>         [v_environment] = { "once", processfileonce },
>>>         [v_product]     = { "none", processfilenone },
>>>         [v_component]   = { "many", processfilemany },
>>>     }
>>> }
>>>
>>> Then, why is the product file processed multiple times?
>> The rules for a component files are applied *after* \startcomponent
>> which isn’t the case for the example where in the first iteration
>> the "text" rules are applied and in the following iteration the rules
>> for a product file.
>>
>> Moving \product … after \startcomponent prevents the loop but
>> the environment won’t be loaded anymore because the product
>> file isn’t loaded anymore.
>
> So, what's the recommended alternative? One could move the \environment
> to the components, but that can lead to a lot of repetitions (if there
> are many environments).

i always use one main environment (that can include others) and putting 
an \environment on top of a component is then not much overhead 
(compared to getting the content done)

Hans


-- 

-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
       tel: 038 477 53 69 | www.pragma-ade.com | www.pragma-pod.nl
-----------------------------------------------------------------
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: Product-component structure

[Aditya Mahajan]

On Sat, 25 Jun 2016, Hans Hagen wrote:

>> So, what's the recommended alternative? One could move the \environment
>> to the components, but that can lead to a lot of repetitions (if there
>> are many environments).
>
> i always use one main environment (that can include others) and putting 
> an \environment on top of a component is then not much overhead 
> (compared to getting the content done)

So, to a newcomer, one can suggest to simply use components and 
environments. What is the advatange of the extra structure provided by 
product/project?

Aditya
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: Product-component structure

[Wolfgang Schuster]

[-- Attachment #1.1: Type: text/plain, Size: 392 bytes --]

> Aditya Mahajan <mailto:adityam@umich.edu>
> 25. Juni 2016 um 18:37
> On Sat, 25 Jun 2016, Hans Hagen wrote:
>
>
> So, to a newcomer, one can suggest to simply use components and 
> environments. What is the advatange of the extra structure provided by 
> product/project?
A product is the book itself while components are only chapters, 
sections etc. (components can be nested).

Wolfgang

[-- Attachment #1.2: Type: text/html, Size: 1371 bytes --]

[-- Attachment #2: Type: text/plain, Size: 485 bytes --]

___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: Product-component structure

[Wolfgang Schuster]

[-- Attachment #1.1: Type: text/plain, Size: 433 bytes --]

> Hans Hagen <mailto:pragma@wxs.nl>
> 25. Juni 2016 um 11:56
>
>
> i always use one main environment (that can include others) and 
> putting an \environment on top of a component is then not much 
> overhead (compared to getting the content done)
The problem with puttins \environment before \startcomponents is
that you can’t check for the *component mode which is enabled
after the environment was loaded.

Wolfgang

[-- Attachment #1.2: Type: text/html, Size: 1431 bytes --]

[-- Attachment #2: Type: text/plain, Size: 485 bytes --]

___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: Product-component structure

[Aditya Mahajan]

On Sat, 25 Jun 2016, Wolfgang Schuster wrote:

>> Aditya Mahajan <mailto:adityam@umich.edu>
>> 25. Juni 2016 um 18:37
>> On Sat, 25 Jun 2016, Hans Hagen wrote:
>> 
>> 
>> So, to a newcomer, one can suggest to simply use components and 
>> environments. What is the advatange of the extra structure provided by 
>> product/project?
> A product is the book itself while components are only chapters, sections 
> etc. (components can be nested).

Does that mean products cannot be nested?

Even if a component is part of a product, the component must explicitly 
include all the environments needed for compilation (rather than simply 
refering to a product, as in the original question). So, I don't 
structurally see an advantage of the product-component distinction.

Since this is an old mechanism and widely used (though I have never used 
it), I am missing something. The wiki page is woefully out of date with 
the current behavior.

Aditya


___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: Product-component structure

[Aditya Mahajan]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 613 bytes --]

On Sat, 25 Jun 2016, Wolfgang Schuster wrote:

>> Hans Hagen <mailto:pragma@wxs.nl>
>> 25. Juni 2016 um 11:56
>> 
>> 
>> i always use one main environment (that can include others) and putting 
>> an \environment on top of a component is then not much overhead (compared 
>> to getting the content done)
> The problem with puttins \environment before \startcomponents is
> that you can’t check for the *component mode which is enabled
> after the environment was loaded.

So, one should use:

\startcomponent *
\environment env
...
\stopcomponent

for both components and products?

Aditya

[-- Attachment #2: Type: text/plain, Size: 485 bytes --]

___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: Product-component structure

[Hans Hagen]

On 6/25/2016 7:13 PM, Wolfgang Schuster wrote:
>> Hans Hagen <mailto:pragma@wxs.nl>
>> 25. Juni 2016 um 11:56
>>
>>
>> i always use one main environment (that can include others) and
>> putting an \environment on top of a component is then not much
>> overhead (compared to getting the content done)
> The problem with puttins \environment before \startcomponents is
> that you can’t check for the *component mode which is enabled
> after the environment was loaded.

indeed, but i can't remember having done such tests

Hans


-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
       tel: 038 477 53 69 | www.pragma-ade.com | www.pragma-pod.nl
-----------------------------------------------------------------
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: Product-component structure

[Procházka Lukáš Ing.]

Hello,

my "how-I-do-it" used for typesetting a large book was:

---- styles.sty
% Styles, settings etc.; never compiled individually, thus ".sty"; the file also doesn't use '\startenvironment' ... '\stopenvironment' commands (I even don't know whether such commands exist; anyway, I didn't need them)

\mainlanguage[cz]
...
----

---- book.tex
% Main file to build the whole book

\environment styles.sty
\startproduct *
   \startfrontmatter
     ...
   \stopfrontmatter

   \startbodymatter
     \component comp01
     ...
   \stopbodymatter
\stopproduct

---- comp01.tex
% One of components; can be compiled individually, but sections are not numbered from the point of view of the final document (= book.tex) ("globally") but "locally" from the point of view of just comp01.tex

\environment styles.sty
\startcomponent *
   ...
\stopcomponent

Resume:

- Environment file 'styles.sty' is included in the product file and ALSO in all component files.
- Environment file is included AHEAD OF any \start{product|component}.
- Product file can be successfully compiled.
- Single components can be compiled successfully, too; sections here are NOT NUMBERED as in the final document.
- There no need to use "project" ability.

That's how I used and I understood component/product/project/environment structure in my project (book).

But a better way may exist (or might be intended).

Best regards,

Lukas


On Sat, 25 Jun 2016 19:25:32 +0200, Aditya Mahajan <adityam@umich.edu> wrote:

> On Sat, 25 Jun 2016, Wolfgang Schuster wrote:
>
>>> Hans Hagen <mailto:pragma@wxs.nl>
>>> 25. Juni 2016 um 11:56
>>>
>>>
>>> i always use one main environment (that can include others) and putting
>>> an \environment on top of a component is then not much overhead (compared
>>> to getting the content done)
>> The problem with puttins \environment before \startcomponents is
>> that you can’t check for the *component mode which is enabled
>> after the environment was loaded.
>
> So, one should use:
>
> \startcomponent *
> \environment env
> ...
> \stopcomponent
>
> for both components and products?
>
> Aditya


-- 
Ing. Lukáš Procházka | mailto:LPr@pontex.cz
Pontex s. r. o.      | mailto:pontex@pontex.cz | http://www.pontex.cz
Bezová 1658
147 14 Praha 4

Tel: +420 241 096 751
Fax: +420 244 461 038

___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: Product-component structure

[Alan BRASLAU]

On Mon, 11 Jul 2016 13:01:58 +0200
Procházka Lukáš Ing. <LPr@pontex.cz> wrote:

> - Single components can be compiled successfully, too; sections here
> are NOT NUMBERED as in the final document.

A nagging question that I have always had about structure is that it
would be rather nice if compiling a component that is part of a product
could use the .tuc information from an earlier compiling of the entire
product (if present) for numbering. Of course, modifying a component
(such as a chapter) might or would have an effect on all other
components of the product, but such is life.

In a large book product, working on a single chapter would be useful,
and getting the numbering at least close to correct is desirable.

Alan
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________