[TYPO3-dev] Dynamic type field default value on record creation based on parent record type

[Thomas "Thasmo" Deinhamer]

I won't let this go. :>

Thomas

Am 04.05.2010 00:06, schrieb Thomas "Thasmo" Deinhamer:
> Hello!
>
> Sorry for beeing that impatient, can someone confirm this bug?
>
> Thanks a lot,
> Thomas
>
> Am 30.04.2010 23:37, schrieb Thomas "Thasmo" Deinhamer:
>> Hello folks,
>>
>> I've figured out how to supress the select option text "INVALID VALUE"
>> when filtering the available options with a custom itemsProcFunc which
>> will only return a single chooseable option, to "force" TYPO3 selecting
>> this value, with setting "disableNoMatchingValueElement" in the config
>> array of the select field. (Longest english sentence ever created by me.
>> *hooray*)
>>
>> In other words, when creating a new inline record the type select field
>> is populated with only one choice to force a custom, dynamic 'default'
>> value.
>>
>> The problem now is, that TYPO3 does not(!) take the first value of this
>> item array as default value. If I do not set the config option
>> 'default', it seems that the type is just an empty string. (Or Zero?)
>> (More in detail: If I manually set the 'default' option to an existing
>> type, TYPO3 will render the type select field correctly with the only,
>> filtered option in place, but won't initialize the row/record with the
>> value of this type option.)
>>
>> In the docs I can read: "Default value. If empty, the first element in
>> the items array is selected." If I set the 'default' option to NULL or
>> an empty string ('') or even if I do not set it at all, TYPO3 will not
>> take the first item array value into account, but rather just doesn't
>> set the type. Or is it set to 0 (Zero)? The problem now is, that if you
>> configure the "types" array (which defines the visible fields for each
>> specific type) and change the preconfigured key 0 (Zero) which is set
>> e.g. by the kickstarter, TYPO3 won't render any form/fields at all.
>>
>> So, I had a look at the TCEforms class, but I couldn't figure out where
>> the magic happens - it's kinda huge and unreadable to me.
>>
>> Is there anybody out there who can confirm this or provide a
>> fix/solution for this? I also had a look at the bugtracker but couldn't
>> find a reported bug for this problem.
>>
>> Thanks a lot for your feedback,
>> Thomas
>>
>>
>> Am 28.04.2010 01:31, schrieb Thomas "Thasmo" Deinhamer:
>>> Sorry for the long title, but I refused to md5-revert-camelcase it for
>>> different reasons. ;o)
>>>
>>> What I would like to achieve is this:
>>>
>>> On creation of an IRRE record the type of this IRRE record should NOT be
>>> set to the default value, but rather to a specific type, based on the
>>> already set type value of the parent record.
>>>
>>> This means if the actual record (parent record) is of type 'phoenix',
>>> all newly created IRRE records also should have the initial type value
>>> of 'phoenix' and not '0' (zero) or NULL.
>>>
>>> It seems TYPO3 does NOT set the initial value based on the items array,
>>> but just sets it to NULL or an empty string, if the 'default' key is not
>>> set in the 'config' array. (Besides that, the 'default' value can only
>>> be set to a static string, which doesn't solve the problem.)
>>>
>>> This makes settings the initial value of the type field of the IRRE
>>> record impossible using an itemsProcFunc, which would return ONLY the
>>> desired type (like an array with only 1 item).
>>>
>>> Now I was wondering if there is any solution to this? The only thing
>>> which could work, I can think of, is a hook which would fire before the
>>> form of the IRRE record gets rendered - there it may be possible to
>>> manipulate the 'default' value of the type field.
>>>
>>> Any ideas?
>>>
>>> Thanks a lot for your help,
>>> Thomas