[TYPO3-mvc] Feature: automatic target page determination

[Franz Koch]

Hey Bastian,

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

you don't have to thank me over and over again. Once is fine for me ;)
On the contrary, I have to thank you for your work on this.

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

You must have to much sparetime ;) Nice would be some slide mechanism, 
so that all plugin types unfold on clicking the group label - but I 
think that's what you already had in mind.

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

One (big) issue could be that you have different namespaces for your 
get/post vars for every plugin instance. So there should be a way for 
plugins to share certain parameters, or to at least define which 
namespace should be used. Just take cal as example, where all the 
different views (if you tend to split each view with it's complex 
settings into different plugins) at least have to share the same 
parameters for the date (year,month,day,week). That's also vital for 
clean URLs and easy maintenance of realUrl configs etc.

> IMO the flexforms should then be used to specify/override settings for
> this very instance mostly and maybe to override the default action

right - but there still might be the need now and then to hide certain 
flexform fields from editors (like template fields or maybe a 
storagePid, when editors are not supposed to change those).


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

maybe I need to have a closer look then - didn't see it at first glance.

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

Typolinks themselfs already have a cache IIRC - if you meant that by 
first level cache - so it only might be really needed for v5 atm - but 
it wouldn't harm in v4 too.

-- 
kind regards,
Franz Koch