[TYPO3-mvc] Feature: automatic target page determination

[Bastian Waidelich]

Franz Koch wrote:

Hi Franz,
great, that you take the time to get into this!

> I'm fine with splitting extensions into multiple plugins in general, as
> long as using the magic doesn't force you to do.

I fully agree.


>> BTW: I think, it would be good if TYPO3 could group plugins [...]

> That would be of course a nice feature.

I'll come up with a patch for this asap.


> But we might neither have to split extensions into multiple plugins, nor
> have group those if TYPO3 finally would allow user/group restrictions
> also for FLEXFORM fields.

I think tt_news would be much easier to handle, if it wasn't one huge 
thing but rather split up into multiple plugins actually.
Until now a new plugin meant work and lots of additional code. But with 
Extbase a plugin is just a virtual collection of controllers and actions.
So I think, there is nothing to be said against multiple plugins _IF_ 
the handling for dev and admin/editor won't get more complex.

IMO the flexforms should then be used to specify/override settings for 
this very instance mostly and maybe to override the default action (to 
be honest: I regret, that we allowed to specify completely new 
controller/action pairs here - it's kind of irreversible and by-passes 
the API).


>> You're right, you can't auto detect this for _all_ use cases. But you
>> can detect this for the _standard_ use cases.

> But what is the _standard_? For most v4 devs THE standard extension
> still is tt_news, having only one blown up plugin. So you're magic won't
> work for this 'standard'.

It definitely would. Take the modified blog_example. You can use it as 
full blown plugin or "fine-grained".
It only wouldn't work automatically, if you'd use the same plugin on 
multiple pages. Then you have to specify the "default plugin", just like 
you have to do it now.


> That of course would be nice to have, as long as the performance is not
> suffering when you have lot's of links generated by your plugin - so
> there should be something like a cache array inside the uriBuilder.

Yes, there should be a first level cache for the UriBuilder anyways.


> why do you have to update your configuration if a new action is added?
> [...] it'll fall back to the plugins default/current pid

Ok, I'm with you now.


> I'm fine with enabling it by default, as long as it's working, doesn't
> slow down overall performance (using internal caches) and is easy to
> override per instance/action.

Full ack. And it has to be well documented as David mentioned.

Best,
Bastian