TYPO3 Mailingliste: nicht fragen - lesen!

Hy;

I need some verifications if I understood correctly:

- TV does not register it's flex-values in TS, thus it's not possible to
do something similar to {$field_when} in a TS-Setup, though referenced
by TypoScriptObject. [TV-List: Getting a field value from the page in an FC]

- TV by default substitutes all fields in local <TypoScript>-Blocks.
[TV-List: hiding complicated settings of frontendextensions by using an FCE]

- TV does not process the <eType>none</eType> itself. [Observation, I
mined the source with print_r and the none-types never appear,
<proc><stdWrap> does not get interpreted, <TypoScript> neither]

- TV has no <eType>ts</eType>, but it's okay to substitue that with
<eType>link</eType>. [TV-List: hiding complicated settings of
frontendextensions by using an FCE - it renders a gallery with the
link-type!?]

- The attribute-element applies itself to the parent element. [Guess, I
didn't find any information]

- Or the attribute-element applies itself to previous sibling element.
[Conclusion, as we can have childs for regular elements]

- The attribute-element can be of none-type, with <TypoScript>, that
get's processed, allowing to map any fields value into an attribute of a
tag. [T3-german: FCE mit TSObject - uid des aktuellen FCE ausgeben für
Javascript]

- A section-element can be of any type, which is ignored anyway, and
even if mapped on OUTER will always render the mapped tag. [Experience,
I don't get the tag away]

It's just very thin information about the most advances features of TV
out there. So I would be really thankfull for some talk about this.
I actualy would like to do exactly the same as the rggallery thing:

<eType>ts</eType>
<TypoScript>
lib.collectedActivities = CONTENT
lib.collectedActivities {
table = tt_content

select {
# "type" is a select which contains the pids of the sys-folders
we extract the entries from, <index="1"> should contain the pid-numbers
pidInList = {$register:field_type[1]}
where = tx_templavoila_to IN(1)
}

renderObj = COA
renderObj {
10 < tt_content

# ...
}

# "when" is a date-picker, <index="2"> should contain the id-fragments
stdWrap.wrap = <div class="popup"
id="cal_{$register:field_when[2]}_{$register:field_type[2]}"> | </div>
}
</TypoScript>

Thanks
Niels


_______________________________________________
TYPO3-project-templavoila mailing list
TYPO3-project-templavoila (AT) lists...netfielders.de
http://lists.netfielders.de/cgi-bin/...ct-templavoila

Niels Fröhling wrote:
> Hy;
>
> I need some verifications if I understood correctly:
>
> - TV does not register it's flex-values in TS, thus it's not possible to
> do something similar to {$field_when} in a TS-Setup, though referenced
> by TypoScriptObject. [TV-List: Getting a field value from the page in an
> FC]

TV does not register anything. Flexform fields are stored in XML, this why you cannot access these fields from TS.

> - TV by default substitutes all fields in local <TypoScript>-Blocks.
> [TV-List: hiding complicated settings of frontendextensions by using an
> FCE]

Sorry, I did not understand.

> - TV does not process the <eType>none</eType> itself. [Observation, I
> mined the source with print_r and the none-types never appear,
> <proc><stdWrap> does not get interpreted, <TypoScript> neither]

Right.

> - TV has no <eType>ts</eType>, but it's okay to substitue that with
> <eType>link</eType>. [TV-List: hiding complicated settings of
> frontendextensions by using an FCE - it renders a gallery with the
> link-type!?]

You can use "none" or TS object path field.

> - The attribute-element applies itself to the parent element. [Guess, I
> didn't find any information]

Element does not apply itself to anything. Its value from template is substituted with another value.

For example, if you had:

<a href="javascript:void(0)">Home</a>

and you map "href", you can do this in DS XML:

<TypoScript>
10 = TEXT
10.typolink {
parameter = 12345
returnLast = url
}
</TypoScript>

> - Or the attribute-element applies itself to previous sibling element.
> [Conclusion, as we can have childs for regular elements]
>
> - The attribute-element can be of none-type, with <TypoScript>, that
> get's processed, allowing to map any fields value into an attribute of a
> tag. [T3-german: FCE mit TSObject - uid des aktuellen FCE ausgeben für
> Javascript]

Yes.

> - A section-element can be of any type, which is ignored anyway, and
> even if mapped on OUTER will always render the mapped tag. [Experience,
> I don't get the tag away]

When you create a section, you cannot choose the type.

> It's just very thin information about the most advances features of TV
> out there. So I would be really thankfull for some talk about this.
> I actualy would like to do exactly the same as the rggallery thing:
>
> <eType>ts</eType>

Use "none" here or TS object path.

> <TypoScript>
> lib.collectedActivities = CONTENT
> lib.collectedActivities {
> table = tt_content
> select {
> # "type" is a select which contains the pids of the sys-folders
> we extract the entries from, <index="1"> should contain the pid-numbers
> pidInList = {$register:field_type[1]}
> where = tx_templavoila_to IN(1)
> }
>
> renderObj = COA
> renderObj {
> 10 < tt_content
>
> # ...
> }
> # "when" is a date-picker, <index="2"> should contain the id-fragments
> stdWrap.wrap = <div class="popup"
> id="cal_{$register:field_when[2]}_{$register:field_type[2]}"> | </div>
> }
> </TypoScript>

--
Dmitry Dulepov
TYPO3 Core team
My TYPO3 book: http://www.packtpub.com/typo3-extens...velopment/book
In the blog: http://typo3bloke.net/pages/book-rev...garr-reynolds/
_______________________________________________
TYPO3-project-templavoila mailing list
TYPO3-project-templavoila (AT) lists...netfielders.de
http://lists.netfielders.de/cgi-bin/...ct-templavoila

Hy Dimitry;
>> - TV by default substitutes all fields in local <TypoScript>-Blocks.
>> [TV-List: hiding complicated settings of frontendextensions by using an
>> FCE]
>>
>
> Sorry, I did not understand.
>
A lot of examples of FCE-setups use the Flex-fields like "field_hidden".
Your example would (according to my observation) take the
parameter-value out of the Flex-field "field_parameter":

<TypoScript>
10 = TEXT
10.typolink {
parameter = field_parameter
returnLast = url
}
</TypoScript>

Is that correct?

Ciao
Niels

_______________________________________________
TYPO3-project-templavoila mailing list
TYPO3-project-templavoila (AT) lists...netfielders.de
http://lists.netfielders.de/cgi-bin/...ct-templavoila

Hi!

Niels Fröhling wrote:
> A lot of examples of FCE-setups use the Flex-fields like "field_hidden".
> Your example would (according to my observation) take the
> parameter-value out of the Flex-field "field_parameter":
>
> <TypoScript>
> 10 = TEXT
> 10.typolink {
> parameter = field_parameter
> returnLast = url
> }
> </TypoScript>
>
> Is that correct?

Yes.

--
Dmitry Dulepov
TYPO3 Core team
My TYPO3 book: http://www.packtpub.com/typo3-extens...velopment/book
In the blog: http://typo3bloke.net/pages/book-rev...garr-reynolds/
_______________________________________________
TYPO3-project-templavoila mailing list
TYPO3-project-templavoila (AT) lists...netfielders.de
http://lists.netfielders.de/cgi-bin/...ct-templavoila

Hy Dmitry;
>> Your example would (according to my observation) take the
>> parameter-value out of the Flex-field "field_parameter":
>>
>> <TypoScript>
>> 10 = TEXT
>> 10.typolink {
>> parameter = field_parameter
>> returnLast = url
>> }
>> </TypoScript>
>>
>> Is that correct?
>>
>
> Yes.
>
Thank you for the answers! Would you mind if I write an alternative
extended Flex-XML edit-form for TV, for you to revisit and maybe
incorporate? I can't promise it for tomorrow, but I think I will try
through the next week to get a grip on it. At some point I hope I may
ask you for verifying options/restriction and flexibility.

Ciao
Niels

_______________________________________________
TYPO3-project-templavoila mailing list
TYPO3-project-templavoila (AT) lists...netfielders.de
http://lists.netfielders.de/cgi-bin/...ct-templavoila

Hi!

Niels Fröhling wrote:
> Thank you for the answers! Would you mind if I write an alternative
> extended Flex-XML edit-form for TV, for you to revisit and maybe
> incorporate? I can't promise it for tomorrow, but I think I will try
> through the next week to get a grip on it. At some point I hope I may
> ask you for verifying options/restriction and flexibility.

I am not sure what you mean by "extended Flex-XML edit-form for TV".

In any case if you write any code, you can post it to bug tracker. Make sure that code follows TYPO3 coding guidelines.

--
Dmitry Dulepov
TYPO3 Core team
My TYPO3 book: http://www.packtpub.com/typo3-extens...velopment/book
In the blog: http://typo3bloke.net/pages/book-rev...garr-reynolds/
_______________________________________________
TYPO3-project-templavoila mailing list
TYPO3-project-templavoila (AT) lists...netfielders.de
http://lists.netfielders.de/cgi-bin/...ct-templavoila

Hy Dmitry;
>> Thank you for the answers! Would you mind if I write an alternative
>> extended Flex-XML edit-form for TV, for you to revisit and maybe
>> incorporate? I can't promise it for tomorrow, but I think I will try
>> through the next week to get a grip on it. At some point I hope I may
>> ask you for verifying options/restriction and flexibility.
>>
>
> I am not sure what you mean by "extended Flex-XML edit-form for TV".
>
A "editor" that gives you all options (Typoscript-constants, stdWrap,
etc.) for the fields where they are possible, with help-text (for
example explaining the scope of the specific TS-fragment put), and
omiting those option they don't have (possibly explaining "why not?" in
a help-text). I haven't seen any help-text in the whole TVsystem at all
yet (maybe I'm missing the important complete locallang.xml?).

So when I have to search for the information necesary to solve the
situation I have, I would like to collect and publish that information
for others to take advantage of. I hope this can be for example in the
form of a more elaborate DS-editor reflecting all possible options
interpreted by the TV-renderer.
> In any case if you write any code, you can post it to bug tracker. Make sure that code follows TYPO3 coding guidelines.
>
Ciao
Niels

_______________________________________________
TYPO3-project-templavoila mailing list
TYPO3-project-templavoila (AT) lists...netfielders.de
http://lists.netfielders.de/cgi-bin/...ct-templavoila

Hi!

Niels Fröhling wrote:
> A "editor" that gives you all options (Typoscript-constants, stdWrap,
> etc.) for the fields where they are possible, with help-text (for
> example explaining the scope of the specific TS-fragment put), and
> omiting those option they don't have (possibly explaining "why not?" in
> a help-text). I haven't seen any help-text in the whole TVsystem at all
> yet (maybe I'm missing the important complete locallang.xml?).
>
> So when I have to search for the information necesary to solve the
> situation I have, I would like to collect and publish that information
> for others to take advantage of. I hope this can be for example in the
> form of a more elaborate DS-editor reflecting all possible options
> interpreted by the TV-renderer.

The thing is: TV does not render these form, TYPO3 does. So you will have to provide a custom field type for it. This is possible and would be nice. But the XML can be complex (sections, containers, different field types, etc). In any case this feature looks good!

--
Dmitry Dulepov
TYPO3 Core team
My TYPO3 book: http://www.packtpub.com/typo3-extens...velopment/book
In the blog: http://typo3bloke.net/pages/book-rev...garr-reynolds/
_______________________________________________
TYPO3-project-templavoila mailing list
TYPO3-project-templavoila (AT) lists...netfielders.de
http://lists.netfielders.de/cgi-bin/...ct-templavoila

Dmitry Dulepov [typo3] wrote:
> The thing is: TV does not render these form, TYPO3 does. So you will have to provide a custom field type for it. This is possible and would be nice. But the XML can be complex (sections, containers, different field types, etc). In any case this feature looks good!
>
Yes, I think my main complain of the DS-editor is, that once you modify
your XML, you can't use the (quote: "fun") DS-editor anymore. By
creating an editor that not only preserves custom or what-not elements,
but for example also gives some control over the TCE-form definition,
that would be a matter of the past then.

I just uploaded the first patch for the "more elaborate"-series (to
bugs.typo3), it fixes the awesome ugly (and even uninformative)
DS-details and gave me the oportunity to really think all over again
about the XML.

One of my question I think got messed up slightly. I asked if
/
parameter = field_parameter/

would be substituted and you answered yes. But in this discussion
http://lists.netfielders.de/pipermai...er/001303.html
it is stated it works only in stdWrap.field, and you resist enabling
/
parameter = {$field_parameter}/

So now I ask myself, how exactly is the feature now implemented? I fail
to see any code related to field->TS transfer in
class.tx_templavoila_pi1, there is only constant->TS transfer. Do we
actually always have to do:
/
<TypoScript>
transfer = LOAD_REGISTER
//transfer.//field_parameter.//field = //field_parameter

....//

blaobj.thisisnostdwrap.butmaybeaselect.parameter = {$field_parameter}
</TypoScript>/

Or is even that not possible? How is the stdWrap-substitution realized
anyway? Is it possible to substitute fields that are logically ordered
_after_ the field for that I defined the TypoScript?

I ask so much because, if there is a chance to automate the
${}-substitution through standard TS, I would try to make it as a
checkbox available (something like 'publish fields to TS [yes/no]').

Ciao
Niels

_______________________________________________
TYPO3-project-templavoila mailing list
TYPO3-project-templavoila (AT) lists...netfielders.de
http://lists.netfielders.de/cgi-bin/...ct-templavoila