[TYPO3-mvc] Feature: automatic target page determination

[Franz Koch]

Hey Bastian,

>>> - 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?

Sorry for the unclear explanation. I was referring to extensions only 
having 1 extKey but that need to switch the viewPid per 
controller/action, which (from what I had seen at a first glance) is not 
possible yet in your modified blog_example. But we treated that topic 
later on anyway.


>> 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.

I'm fine with splitting extensions into multiple plugins in general, as 
long as using the magic doesn't force you to do. So if the magic also 
supports viewPids based on controller/action to work with complex 
extensions like tt_news or cal (I wouldn't like to have 10-20 cal 
plugins to choose from for every possible view in cal) I'm fine with it.

> 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.

That would be of course a nice feature. Although a admin is able to 
group content elements/plugins in tabs now, it's not very convenient to 
handle this for multiple extensions by hand.
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. IIRC there is a extension in TER that allows 
doing so, which I adopted to my needs once - but I can't remember it's 
name though.


>> 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.

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'. I also don't know many extensions I ever used, 
that splitted their views into separate plugins - so again I don't 
consider it as 'standard'.

...
> 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.

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.


>> 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 ;)

I like UUIDs - they are so easy to remember ;)

>> 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..

why do you have to update your configuration if a new action is added? 
Or what do you mean with it? Of course you have to add a TS 
configuration for the additional action if you want it to be displayed 
on a certain page, but if you don't it'll fall back to the plugins 
default/current pid or maybe even a controller specific pid (do we need 
controller specific pids?). So the configuration could look like this:

plugin.tx_yourext {
	view {
		targetPages {
			default = current
			# this controller has a default targetPage, thus all not defined 
actions will link to this default page
			controllerA {
				default = 123
				actions {
					list = 23
					detail = 14
				}
			}
			# this controller doesn't have a default pid, thus all not delcared 
actions will fall back to the default targetPage for this plugin
			controllerB {
				actions {
					search = 21
				}
			}
		}
	}
}


> 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)..

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.

-- 
kind regards,
Franz Koch