Bug #3726

Links with arguments don't work without routes

Added by Irene Höppner over 10 years ago. Updated over 9 years ago.

Status:
Resolved
Priority:
Must have
Category:
MVC
Start date:
2009-06-22
Due date:
% Done:

100%

PHP Version:
Has patch:
Complexity:

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

Revision 45408ced (diff)
Added by Karsten Dambekalns over 10 years ago

[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

Revision f4754854 (diff)
Added by Karsten Dambekalns over 10 years ago

[TAKS] FLOW3 (MVC): Moved mapping of UUIDs to objects from ArgumentsValidator to Argument, refs #3726

History

#1 Updated by Irene Höppner over 10 years ago

revision r2620 works, revision r2621 doesn't.

#2 Updated by Karsten Dambekalns over 10 years ago

  • Category set to MVC
  • Target version set to 1.0 alpha 2

#3 Updated by Karsten Dambekalns over 10 years ago

The change in isPropertyValid() causes this, although "cause" may be the wrong word...

#4 Updated by Karsten Dambekalns over 10 years ago

  • Status changed from New to Accepted
  • Assignee set to Karsten Dambekalns

#5 Updated by Karsten Dambekalns over 10 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 over 10 years ago

  • Status changed from Accepted to Resolved
  • % Done changed from 0 to 100

Applied in changeset r2644.

Also available in: Atom PDF