[TYPO3-templavoila] FCE and availibility of fields (10.file.width.field = field_width)

[Niels Fröhling]

Dmitry Dulepov wrote:
> Hi!
>
> Niels Fröhling wrote:
>   
>> What would you suggest? I think "tx_templavoila_pi1.parentRec." is not
>> so wrong (semantically).
>>     
>
> Earlier I suggested to use another register.
>
>   
>> How about naming it after the real DB-field
>> "tx_templavoila_pi1.parentRec.tx_templavoila_flex.", which would put it
>> exactly besides the other DB-fields?
>>     
>
> This looks good too. It can be come very complex though:
> tx_templavoila_pi1.parentRec.tx_templavoila_flex.field_container_1.field_container_2.field_regular
> and it will not work with sections unless syntax becomes even more
> complicated.
>   

 It works with sections if you construct as XPath (which is officially 
supported by the FlexForm API, and also supported by TV - including 
page-module, which makes cross-container drag'n'drop possible - after 
the patch 0009530):

field_section/el/5/field_container/el/field_regular

 I though omit that because the idea was to give an actual resolved state of the tree, not the complete existing tree.

 The registered values (in the modification) contain the resolved field values, after language/sheet/value resolution. And that is mostly for performance-reasons, and for convenience. We do have the "tx_templavoila_flex"-field available, we could resolve it via user-functions, but in that hipothetical user-function you would have to re-create all of the functionality of processValues, so it's twice work and it complicates life (for the TS-Implementator) very much.
 It is better to have a location where you may fetch the resolved flex-values easily.


> To me this functionality looks like coming from "we do it because we
> can". I do not see having it as a big advantage. I can be mistaken,
> of course :) I am not God to know all use cases :)
>   

 No it's because:
- "in situations it's impossible to store the field-values into 
registers via TS"
- "even in situation where it's possible to do the LOAD/RESTORE it's 
inconvenient and error-prone to manually register all DS-fields, which 
may be changed and extended, and the TS has to be revisited"
- "manual registering does not allow access to the full value-hierarchy 
like container/el/field"
- "prevent complex re-implementation of existing value-resolution, by 
publishing the resolved state to TS"
- "it stops TV-stdWrap for COs to work" (this is a yet non-reported 
implementation, but available/visible on the development-server)
- "it stops _any_ TV-stdWrap to use other field-values"
- "it stops _any_ TypoScriptObj to use other field-values"

 Actually somebody would have to explain me a negative issue, I don't 
see any. ;-)
 What I could see in addition is to allow the location of the register 
to be flexible, like a property of ROOT, checkbox+input where you type 
where to register the values 
(mylocation.field_container/el/field_title). That allows you to prevent 
that a FCE overlays the parentRec-information of the underlying PAGE like:

tvpage.field_show_details
tvpage.field_origin_pid_selector_to_collect_fces_from
|- tvfce.field_title + 
tvfce.field_details(if.tvpage_field_show_details)/el/field_description
|- tvfce.field_title + 
tvfce.field_details(if.tvpage_field_show_details)/el/field_description
`- tvfce.field_title + 
tvfce.field_details(if.tvpage_field_show_details)/el/field_description

 For me this is a preparation to really make TV as powerfull as static 
templates, the access to information from the flex-field need to be made 
easier, much easier and broader (currently the information is fragmented 
and re-assembling the information (in context) is often not possible). 
If possible in the future there should also be a better integration in 
terms of sorting FCEs, conditionaly (based on flex-values) selecting 
FCEs, ...

>   
>> The __SERIAL approach is IMHO a huge waste of resources in comparison to
>> the otherwise low-complextiy of the pi1. It would also significanty
>> simplify the code of processDataValues, which helps for the
>> implementation of the slide.
>>     
>
> We can neither remove, nor change behaviour of any existing
> registers. This should be remembered. Otherwise we can optimize code
> as necessary :)
>   

 I carefully proposed a change that will not change the behavious of pi1 
to the outside. I'm very clear about that. That two blocks creating 
__SERIAL construction and deconstruction are sub-optimal at best, and an 
obstacle for further development.

from Steffen:

 > i think this "is" too complicate.

 No its not. :)

> For sections we would have an array, for normal fields we would have the 
> reference.

 There is support for XPath, no need "to array":

ROOT/el/    field_selector
ROOT/el/    field_section/el/0/el/field_name
ROOT/el/    field_section/el/0/el/field_description
ROOT/el/    field_section/el/1/el/field_name
ROOT/el/    field_section/el/1/el/field_description
ROOT/el/    field_section/el/2/el/field_name
ROOT/el/    field_section/el/2/el/field_description

 This is exactly why the changes in "class.tx_templavoila_api.php" - to 
make hierarchical COs and cross CO d'n'd - were absolutly minimal and it 
out-of-the-box worked all over the place in mod1, without modification. 
It also works with any extension using the Flexform-API without change.

 But: I though omit that because the idea was to give an _actual_ 
resolved state of the tree (or maybe expressed better: a flex-rootline, 
from the actual flex-container down to ROOT), not the complete existing 
tree.

 Ciao
    Niels