[TYPO3-mvc] URLs for Several Content Elements of the same Extension with Extbase on one Page

[David Bruchmann]

----- Ursprüngliche Nachricht -----
Von: Bastian Waidelich <bastian at typo3.org>
Gesendet: Freitag, 30. Juli 2010 12:21:30
An:
CC:
Betreff: Re: [TYPO3-mvc] URLs for Several Content Elements of the same 
Extension with Extbase on one Page
> David Bruchmann wrote:
>
>> I wanna being able to show several ContentElements on one page, that are
>> generated by the same extension.
>> Showing up isn't problem but having forms it's not possible to
>> distinguish between the CEs, right?
>
> It depends:
> If you have a "edit article" (form) and a "latest articles" plugin on
> one page, the "latest article" plugin shouldn't be affected if it is not
> configured to display the "updateAction()".
> (It would display the default action of the first configured controller
> instead)
>
> But that's not reliable and does not work in all cases (e.g. multiple
> forms). We need to be able to override the plugin's URI prefix (see
> http://forge.typo3.org/issues/8365)
>
> Best,
> Bastian


Hey Bastian,

thanks for the hint!
its nice that I'm not the only one for this request and I read the page 
you have linked.
Personally I don't like the syntax "controller_uid[param]" but more 
"controller[uid][param]" but this is perhaps just a matter of taste and 
doesn't concern functionality even an array-key is a bit easier to 
handle perhaps.

I propose to just include an additional method in the uri-builder (and 
the class where the uris are interpreted), something like cObjLink().
Furthermore a fluid-ViewHelper is needed, that creates those links and 
uses the new method.

A Szenario where two of the same controllers are needed:
you have two different address-lists on the same page (i.e. 
family/friends, different companys, ...).
But this is a challenge for the extension-developers and doesn't concern 
the extbase-developers ;)

I don't know about amount or kind of requests concerning extbase/fluid 
but concerning URIs it's perhaps enough to include the new possibility 
instead of enabling dynamic creation through user-functions - even the 
latter sounds better ;)


Best Regards,
David