[TYPO3-mvc] Feature: automatic target page determination

Bastian Waidelich bastian at typo3.org
Tue Aug 3 18:12:18 CEST 2010


Hi all,

please take a few minutes for this message and comment (some of) the 
questions at the end - it might affect your (future) extbase plugins ;)

Currently the blog_example runs in one full-fledged plugin ("Pi1"). This 
is kind of convinient as you only need to insert one plugin to get it up 
and running. But sometimes you need to split the functionality over 
several pages (reasons: e.g. a teaser on the homepage, a different page 
layout for the single view, access restricted functions, ...).

So I've used the blog_example and experimented with solutions to split 
an extension into several plugins in a straightforward way.
Fitst, I've added following plugins: BlogList, PostList, PostSingle and 
BlogAdmin [1]

I started by modifying links in the templates like:
<f:link action="show" controller="Post" 
pageUid="{settings.Post.show.pid}">...

But - as discussed before - this is not a good solution, because: 1. 
target pages shouldn't be part of the plugin settings, 2. you normally 
shouldn't have to care about target pages in your templates, 3. it makes 
templates less reusable.

So I reverted this change and instead modified the UriBuilder so that it 
detects the target plugin (by iterating through registered plugins and 
comparing allowed controllers & actions with the specified parameters).
Once the target plugin is known, the UriBuilder tries to detect the 
target page (of course only if pageUid has not been specified). It 
therefore checks the TS configuration 
"plugin.tx_pluginsignature.view.defaultPid". If this is not set (or 
empty) the target page couldn't be detected and the current page is 
assumed. if defaultPid is a number, that will be used as target Pid.

Now the interesting part:
defaultPid defaults to the string "auto". If that is not overridden, the 
UriBuilder detects the page that contains the requested plugin (SELECT 
pid FROM tt_content WHERE list_type=[plugin_signature] AND hidden = 0 
AND deleted = 0).

That might sound quite complex, but actually it is just a few lines of 
code [2] and worked pretty well in my tests:
I did not have to modify templates or configuration of the blog_example. 
By registering the plugins and putting them on the different pages, 
everything worked transparently. See [3] for more infos.

Now some questions to you (please don't hesitate to reply, every 
feedback is welcome):

- Is this too much magic?

- What happens if more than one registered plugin is configured to 
handle the specified Controller & action (suggestion: Exception "more 
than one plugin is configured to handle this request, specify 
'pluginName' argument")

- What happens if the target plugin is not present in the page tree 
(suggestion: Exception "you need to insert the plugin 'PostSingle' in 
order to call the 'show' action of the 'PostController'", or ignore)

- What happens if the target plugin is installed more than once in the 
page tree? (suggestion: Exception "'PostSingle' plugin is used more than 
once, please specify 'pageUid' argument or set 
'tx_blogexample_postsingle.view.defaultPid' to a fixed page id")

- Though I'm quite confident about the general approach, I'm not 
perfectly happy with the implementation yet. Especially the two static 
functions in Tx_Extbase_Utility_Extension and the DB call in 
getTargetPidByPluginSignature(). Do you have some refactoring suggestions?

- Any other comments?


BTW: This solution works for plugins now, but it could easily extended 
to support BE modules too.

Best,
Bastian

[1] http://forge.typo3.org/attachments/3560/9121_tx_blogexample_v1.patch
[2] http://forge.typo3.org/attachments/3559/9121_tx_extbase_v1.patch
[3] http://forge.typo3.org/issues/9121


More information about the TYPO3-project-typo3v4mvc mailing list