[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