[TYPO3-mvc] Tx_Extbase_MVC_Controller_Argument StoragePage

Michael Feinbier mf at hdnet.de
Tue Jun 22 16:04:29 CEST 2010


Hey,
Am 22.06.10 15:01, schrieb Karsten Dambekalns:
>
> Generally, using a storage pid seems like a bad idea, as it leads to
> such problems. Anyway, I remember suggesting the use of the GRSP for
> Extbase - it could be used in addition to a specific storage page for
> "shared objects". Similarly records on pid 0 could included automatically.

This is the old more general discussion of the need of the storagePid 
itself.
There exist many Tasks for that eg.
http://forge.typo3.org/issues/5631

(the problem with Tx_Extbase_MVC_Controller_Argument is already 
mentioned here by the way)

For me (personally) the handling of the pid-storage is one of the 
largest show-stopper in extbase at the moment :(

Maybe we can find some time on T3DD10 to talk about that in general?

>
> But, again: IMHO an object tree is an object tree and objects should be
> retrieveable by their identity/identifier in any case, regardless of the
> storage page.

This is exactly what I think. An identifier is an identifier is an 
identifier. If I call findOneByUid I want the Record with that uid (if 
it exists) regardless of whether it's in my storagePid or not.

At the Argument the storagePid check is particularly very annoying 
because it simply breakes the very nice feature to pass a Model/Object 
directly to a Controller/Action via the LinkHelper if the recieving 
Controller has another storagePid.

Greetings

Micha
>
> Regards,
> Karsten



More information about the TYPO3-project-typo3v4mvc mailing list