[TYPO3-mvc] Tx_Extbase_MVC_Controller_Argument StoragePage

[Lienhart Woitok]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Sebastian,

why not use a combination of the two? For example, if a repository exists, use it. At least I expected that to happen in the first place. If no repository exists approach 2) could be used.
Another proposition I would like to make is to give the repositories a preconfigured QuerySettings object (so a repository could just change the QuerySettings in a central place) that is also used for objects inside the aggregate root when the DataMapper fetches those objects. Maybe this could even be overridden again by your approach 2)?

What do you think?

Kind regards,



Lienhart Woitok
Web-Entwickler

Telefon: +49 (911) 539909 - 0
E-Mail: Lienhart.Woitok at netlogix.de
Internet: http://media.netlogix.de

- --
netlogix GmbH & Co. KG
IT-Services | IT-Training | Media
Andernacher Straße 53 | 90411 Nürnberg
Telefon: +49 (911) 539909 - 0 | Fax: +49 (911) 539909 - 99
E-Mail: mailto:info at netlogix.de | Internet: http://www.netlogix.de/

netlogix GmbH & Co. KG ist eingetragen am Amtsgericht Nürnberg (HRA 13338)
Persönlich haftende Gesellschafterin: netlogix Verwaltungs GmbH (HRB 20634)
Umsatzsteuer-Identifikationsnummer: DE 233472254
Geschäftsführer: Stefan Buchta, Matthias Schmidt

- -----Ursprüngliche Nachricht-----


Von: typo3-project-typo3v4mvc-bounces at lists.typo3.org [mailto:typo3-project-typo3v4mvc-bounces at lists.typo3.org] Im Auftrag von Sebastian Kurf?rst
Gesendet: Dienstag, 22. Juni 2010 08:30
An: typo3-project-typo3v4mvc at lists.typo3.org
Betreff: Re: [TYPO3-mvc] Tx_Extbase_MVC_Controller_Argument StoragePage

Hey,

I think as well that this issue needs to be solved.
There might be two ways to solve this issue I see right now:

1) Using the repository findByUid method, as suggested.
I think technically, it would work quite easily. However, semantically,
by creating a repository for an object, you declare it as so-called
"Aggregate Root" [1], so it has a semantic meaning that a repository
exists for a given object.
In Domain-Driven-Design, if an object is an aggregate root, if it is
deleted, it deletes all non-aggregate root children as well. However,
in Extbase this is not automatically done by default, as we always have
the TYPO3 backend where you can access all objects, not just the
Aggregate Root objects.
So, declaring an object as aggregate root (in Extbase) has no (semantic)
consequences right now, that's why this solution might be possible.

2) Overriding the query settings with
$this->arguments[....]->querySettings->...
I could imagine that we can put the query settings used to fetch an
argument inside the Argument object. One could then do the following:

public function initializeFooAction() {
$this->arguments['bar']->getQuerySettings()->setRespectStoragePage(FALSE);
}

/**
 * @param .... $bar
 */
public function fooAction(Tx_X_Domain_Model_Bar $bar) {
}

This seems cleaner to me from a theoretical standpoint, as we do not
have to define objects as aggregate roots if they should not be
aggregate root objects. However, the first variant is more
understandable (and as some of you suggested it, also more intuitive),
and also more powerful as somebody could use custom fetch code.

If we change it in way 1), we should check with the v5 guys as well, as
this part of Extbase / FLOW3 should stay in sync.

I'm not yet sure which way to go, but just wanted to throw in my opinion
on this -- what do you all think about these two variants?

Greets,
Sebastian
PS: I'll see if some people from v5 could join this discussion as well :)

[1]
http://richarddingwall.name/2009/10/13/life-inside-an-aggregate-root-part-1/
_______________________________________________
TYPO3-project-typo3v4mvc mailing list
TYPO3-project-typo3v4mvc at lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-project-typo3v4mvc


-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 3.0.0 (Build 2881)
Charset: Windows-1252

wpUDBQFMIH8CWevMF2ftbKMBCHrhA/46IlPBY0L6eorPdC0PTAAef54NO2xwJ3Mb
Ri/ksDg2W+mQXf6qiSsuelX1f7pf0+GWozM0P7pPWlTNLUshXp4JcZl2EgA28Hot
w/KTBPwaVlUZF1S22W0B45Fw/DEIfkK+kfu74YuTJFIL2ZssQ/ZTRF6slDyOcPQw
eiO3PbafLA==
=vM3h
-----END PGP SIGNATURE-----