Bug #4003
Configure own Controller
| Status: | Closed | Start date: | 2009-07-27 | |
|---|---|---|---|---|
| Priority: | Should have | Due date: | ||
| Assignee: | - | % Done: | 100% |
|
| Category: | - | |||
| Target version: | Stable v1.0 | |||
| Votes: | 0 |
Description
Since the Controller field in Flexform ("Type") is required there is no way to choose an other Controller than Default/MultiStep. The order of choosing Controller currently is:
use Flexform; if NO use TypoScript; if no use Default controller.
What was the concept for choosing the controller? Should this be restricted to the FF values?
Otherwise the solutions are:
Use Flexform; if SET use TypoScript; if no use Default controller
or
provide an additional FF value like "use TS Setting" with no value
and overwrite tt_content.list.20.mailformplusplus_pi1.controller = F3_MailformPlusPlus_Controller_Default
Associated revisions
- Added section 'How to user your own controller' to manual to close issue #4003,
- Updated ext_emconf with new version number.
- Added section 'How to user your own controller' to manual to close issue #4003,
- Updated ext_emconf with new version number.
[Bug 4003] Add a getter for the default organizer, r=niels
History
Updated by Fabien Udriot almost 4 years ago
- File 2009-04-14_1343.png added
Updated by Fabien Udriot almost 4 years ago
2009-04-14 02:10 - Joh. Feustel¶
Additional Information:
1)
I need this to overwrite processFiles() because special chars in filenames broke graphicsmagick on my system (Couldn't discover the reason yet since the filename should be quoted by TYPO3). So I added a small workaround/feature which removes them in "uploaded_name".
Just thinking if this could be helpful in mailfomplusplus in general since the filenames are shown in frontend inside the AjaxFileRemoval link not being covered by any XSS Interceptor. I already tested a filename which broke the link and the thumbnail. What do you think?
2)
If the order is changed to
Use Flexform; if SET use TypoScript; if no use Default controller
tt_content.list.20.mailformplusplus_pi1.controller = F3_MailformPlusPlus_Controller_Default must be removed in Configurartion/Settings/setup.txt
(Could be removed in all cases because its redundant with the "use Default controller" code in the dispatcher).
2009-04-14 11:24 - Fabien Udriot¶
If the order is changed to Use Flexform; if SET use TypoScript; if no use Default controller
What is the default behavior in TYPO3? and in mailformplusplus? We should keep the same manners to avoid confusion.
As far as I have understood we have:
1. Take the default value
2. overriden by TypoScript
3. overriden by Flexform values
Use Flexform; if SET use TypoScript; if no use Default controller tt_content.list.20.mailformplusplus_pi1.controller = F3_MailformPlusPlus_Controller_Default must be removed in Configurartion/Settings/setup.txt
I have nothing against that since this information is present in the documentation.
Done and committed!
(Could be removed in all cases because its redundant with the "use Default controller" code in the dispatcher).
TODO and TOTEST
2009-04-14 12:30 - Joh. Feustel¶
1. Take the default value 2. overriden by TypoScript 3. overriden by Flexform values
This is the usual way. But using a select field in FF avoids using a custom value. Therefore I prefer to add an additional FF field like "Defined by TypoScript" with no value. I made research and found exactly this behavior in tt_news FF field "useSubCategories".
2009-04-14 15:02 - Fabien Udriot¶
File 2009-04-14_1343.png added
Could you have a look at field "predefined form"? I think it has similar requisite. Dropdown values are generated dynamically according to the typoscript configuration.
Can you imagine having the same mechanism for field "type"? (Have a look at the screenshot)
I am wondering whether we could rename the field "type" by something more evident (at least for me) like "layout" or "display mode" or "display type".
What do you think?
2009-04-14 18:35 - Joh. Feustel¶
Can you imagine having the same mechanism for field "type"? (Have a look at the screenshot)
Would be great!
Where should the TS option be located? I think tt_content.list.20.mailformplusplus_pi1 is not the best place. But it could not be inside the predefs, this would brake the logic of the FF fields.
Maybe:
plugin.F3_MailformPlusPlus.settings.controller = Controller_MyOwnController
or:
plugin.F3_MailformPlusPlus.settings.additionalControllers.1 = Controller_MyOwnController
plugin.F3_MailformPlusPlus.settings.additionalControllers.2 = Controller_MyOwnControllerMutistep
So the flexform could provide:
1. default
2. Multistep
3. "Defined by Typoscript: Controller_MyOwnController"
I am wondering whether we could rename the field "type" by something more evident (at least for me) like "layout" or "display mode" or "display type".
I think layout/display would be assumed as something concerning the view. From my view I would suggest using "Controller" or "Controller Type" ;-)
2009-04-14 23:10 - Fabien Udriot¶
Have a look into the file EXT:mailformplusplus/Resources/PHP/class.tx_dynaflex.php around line 117.
There is a loop around TS configurations array. In your case you are looking for the key controller, of course.
foreach($ts['plugin.']['F3_MailformPlusPlus.']['settings.']['predef.'] as $key=>$view) {
...
}
I think layout/display would be assumed as something concerning the view. From my view I would suggest using "Controller" or "Controller Type" ;-)
"Controller" makes sense.
2009-04-16 14:11 - Joh. Feustel¶
Added feature which search for Controller in plugin.F3_MailformPlusPlus.settings and plugin.F3_MailformPlusPlus.settings.predef.blah. Do you agree? The default Controllers are always present.
2009-04-16 15:23 - Reinhard Führicht¶
I was pretty busy lately and did not have much time to focus on MailformPlusPlus. I can't follow all your suggestions and changes here, but here's what I understood:
A user should have the possibility to write an own controller and select it in Flexform. Therefore such controllers are set using plugin.F3_MailformPlusPlus.settings or plugin.F3_MailformPlusPlus.settings.predef.[x].
Did I understand correctly? If so, +1.
A notice for you: I am writing a controller to handle both single step and multistep forms (Task #2961). This controller is called Controller_Form and should make Controller_Default and Controller_Multistep obsolete. Furthermore this Controller will use View_Form, which will make View_Default and View_Multistep useless.
So maybe the dropdown for "Controller Type" or however it may be called should only be filled with user written controllers, since "Default" will be Controller_Form for single step and multistep forms.
2009-04-17 00:18 - Joh. Feustel¶
Did I understand correctly? If so, +1.
Yes :-)
I will wait for your changes and adopt the FF.
But I'm not really happy with putting plugin.F3_MailformPlusPlus.settings.predef.[x].controller to the dropdown because the user would estimate that all settings of his predef will automatically be used if selected in the predef dropdown.
Maybe the default value should be like "Default or from predef". Or better: should we drop this field from FF at all, since with new Controller this setting should not be needed so often. If needed, advanced users can set the Controller via TS for predef or in general. What do you think?
2009-04-17 18:49 - Reinhard Führicht¶
I agree to remove the field in flexform. The TypoScript setting will be enough.
2009-04-23 01:56 - Joh. Feustel¶
Thanks to Reinhards work on #2961 the controller dropdown is gone.
Currently the manual says that controller can be switched using plugin.F3_MailformPlusPlus.settings.controller which doesn't work ATM since the dispatcher gets only TS from tt_content.list.20.mailformplusplus_pi1. .
Should we now
1) only update the manual and drop feature of using different controllers via predef
2) load TS settings (general and predef) within the dispatcher, which is rather part of the controller itself and would be done twice?
What do you think?
Updated by Reinhard Führicht almost 4 years ago
After reading this discussion again, regarding all the changes done in between, I would suggest the following:
Add a note in the manual:
You can set your own controller using: tt_content.list.20.formhandler_pi1.controller = Tx_MyExt_MyController
Because this setting is currently read in the dispatcher:
$controller = 'Tx_Formhandler_Controller_Form';
if($setup['controller']) {
$controller = $setup['controller'];
}
This enables users to use their own controller and doesn't irritate newbie users.
Any opinions?
Updated by Reinhard Führicht almost 4 years ago
- Status changed from New to Closed
- % Done changed from 0 to 100
Added section to manual