Bug #3726
Links with arguments don't work without routes
| Status: | Resolved | Start date: | 2009-06-22 | |
|---|---|---|---|---|
| Priority: | Must have | Due date: | ||
| Assigned To: | Karsten Dambekalns | % Done: | 100% |
|
| Category: | MVC | |||
| Target version: | TYPO3 Flow Base Distribution - 1.0 alpha 2 | |||
| PHP Version: | Complexity: | |||
| Has patch: | Affected Flow version: |
Description
If you set an action link with fluid that uses arguments, it generates a URL like this:
http://blog.flow3.local:81/blog/post/index?blog=c31c5c59-d440-49df-a369-6a48ce29d84f
(as long as no routes are defined)
This results in an error:
An error occurred while trying to call F3\Blog\Controller\PostController->indexAction(). Error: Validation errors for argument "blog"
If you add [__identity] to the get-var, everything is fine:
http://blog.flow3.local:81/blog/post/index?blog[__identity]=c31c5c59-d440-49df-a369-6a48ce29d84f
What i found out till now is, that in the validation-objects \F3\FLOW3\MVC\Controller\Argument::getValue() returns the uuid, but not an object....
Associated revisions
[FIX] FLOW3 (MVC): Moved mapping of UUIDs to objects into ArgumentsValidator, fixes #3726
[TASK] FLOW3 (MVC): Removed Argument\setNewFilterChain() and related tests, as Filter\Chain does no longer exist
[TASK] FLOW3: Some cleanup to documentation, added type hint, removed use statement
[TAKS] FLOW3 (MVC): Moved mapping of UUIDs to objects from ArgumentsValidator to Argument, refs #3726
History
#1 Updated by Irene Höppner about 6 years ago
revision r2620 works, revision r2621 doesn't.
#2 Updated by Karsten Dambekalns about 6 years ago
- Category set to MVC
- Target version set to 1.0 alpha 2
#3 Updated by Karsten Dambekalns about 6 years ago
The change in isPropertyValid() causes this, although "cause" may be the wrong word...
#4 Updated by Karsten Dambekalns about 6 years ago
- Status changed from New to Accepted
- Assigned To set to Karsten Dambekalns
#5 Updated by Karsten Dambekalns about 6 years ago
The property mapper adds the returned errors to it's local MappingResults instance only if they are Validation\PropertyError instances. Before the change in r2621 there were the same errors for a "blog being a string", but they were coming along as two Validation\Error instances instead. Thus they were not added and MappingResults would return FALSE for hasErrors().
The current behaviour is thus more correct - the order of things needs to be moved around, it seems - so that validation is done after mapIdentityUUIDsToRealObjects() in MVC\Controller\AbstractController.
#6 Updated by Karsten Dambekalns about 6 years ago
- Status changed from Accepted to Resolved
- % Done changed from 0 to 100
Applied in changeset r2644.