TYPO3.Flow

Implementation idea: only ReflectionService needs to know about this, could even offer a way to get rid of specialized handling for things like scope in Objects.yaml.

I already mentioned such an idea; so an additional suggestion for this: This feature, imo, must come with a Shell command that shows current annotations and their origin, because "annotations" now/than can have various origins.

Patch set 3 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/13549

Patch set 4 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/13549

Patch set 5 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/13549

Patch set 6 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/13549

Patch set 7 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/13549

Patch set 8 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/13549

Patch set 9 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/13549

Patch set 10 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/13549

Can we also set the arguments of the annotations? Just adding an annotation might not be enough for most cases (e.g. validation). Maybe I missed that in the change or in the test.

The main question for me is, if we want to complicate the whole proxy building even more. Also debugging and traceability is problematic with overriding the annotations in the PHP class. So maybe we should mark the overridden annotations with a comment

What about using the approach of solving the problem at the consumer side? So instead of just asking the ReflectionService about the information, we could introduce another source (e.g. ConfigurationManager) which overrides the data from annotations. The problem for me is that we add almost 1000 lines of code for this change in an area which is really complicated (we had / have a lot of bugs and strange effects in there).

Hmm, that kind of sounds like what i had before ^^

I think for quite complex things like expose it makes sense to have a more high-level api layer above the annotations to use for configurations, but i some cases we might really need a way to change those low-level annotations.

I agree, that debugging gets kind of blurred by this different annotation "sources" and i like the idea to put those information into the proxy through comments. Here's an example i could imagine:

    /**
     * @param string
     * @Flow\Identity
     * @ORM\Column(name="baz")
     *
     * Overridden Annotations:
     * @Flow\Validate(type="Email")
     * @Flow\Validate(type="NotEmpty")
     *
     * Removed Annotations:
     * Flow\Introduce
     */
    protected $mail;

Patch set 11 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/13549

I've just pushed a new patch which renders the annotations in the proxies like this:

https://gist.github.com/3931158

:)

Patch set 12 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/13549