[TYPO3-mvc] Feature: automatic target page determination

[Bastian Waidelich]

Franz Koch wrote:

Hi Franz and thanks for your feedback,

>> - Is this too much magic?
>
> [...] it won't work with extensions having only 1 extKey
> but different views.

Why shouldn't that work? The modified blog_example is a demonstration of 
this case or did I get you wrong?


> Also I'm not a fan of flooding the "create new content" wizard
> with tons of plugins only there to display a certain
> view of the very same extension/task.

I agree, sometimes you simply want to insert one fully fledged plugin. 
But sometimes you do need separate plugins (e.g. if you want to allow 
your editor to edit the subcontent on the plugins detail page).
Anyways, this suggested solution does not force you to spread your 
extensions into many plugins at all. It just tries to support you _if_ 
you have multiple plugins.

BTW: I think, it would be good if TYPO3 could group plugins by the 
extension so that you would choose to insert the Blog extension and in 
the next step select one of the available Blog plugins (if there are 
more than one) instead of having to provide a "view selector" like tt_news.


> This is all related to the db magic which I dislike due to those
> problems. You can't autodetect this in a easy way for all usecases [...]

You're right, you can't auto detect this for _all_ use cases. But you 
can detect this for the _standard_ use cases. So IMO this is a 
realization of the "convention over configuration" paradigm we're trying 
to follow with Extbase & Fluid.
Take this example:
You install some news extension, insert the list plugin on one page, 
insert the detail plugin on another page - and it works, without further 
configuration.
Now you want to add another details view (e.g. for a specially branded 
part of your site). Now it should be clear that you have to somehow 
define what details page to be used (either in the template or by 
overriding the defaultPid in your TS). Deciding that automatically would 
definitely be too much magic.

All the mentioned Exceptions might seem like there are a lot of issues. 
But actually they just tell you, that you didn't configure your 
extension correctly in case you use them in a special way (just like if 
you'd omit the details view of tt_news).


> all the db detection magic won't work with referenced
> content of TemplaVoila or TS instances of plugins.

It will work as it always defaults to the current page (just like it's 
now). If you want to change this behavior, you'll be able to override 
the defaultPid of this specific instance - and you won't have to touch 
the template.

> I'm fine with moving the view Pid configuration stuff from "settings"
> (where most people store it currently) to the "view" namespace, but
> those configuration options should then also be accessible form inside
> the view/template

Another reason why we want to banish page ids from templates as much as 
possible is migration:
In TYPO3 v5 we won't have page ids, and I'm sure no one wants to work 
with UUIDs in their templates - and you shouldn't ;)


> Another thing that should be considered are different PIDs per
> controller/action of the same plugin

Yes, I thought about that too and we might combine both possibilities 
(define a default for the plugin, override it for specific 
controllers/actions).
The problem with specifying a target page on the action level is that 
you'll have to update your configuration if a new action is added - and 
you only realize this, when actually calling the action..


What do you think of setting the default value of "defaultPid" to an 
empty string instead of "auto". Then you have to explicitly enable the 
automatic target page determination if you want to (even though it's not 
convention over configuration anymore then)..

Best,
Bastian