[TYPO3-50-general] Discussion of MVC with validation error messages

[Christopher Hlubek]

Hi Sebastian,

> First: Inside the ActionController, there is a method called
> "initializeActionMethodArguments", which parses the @param annotations
> and collects the method parameters. If no method parameter has been
> set (i.e. there is no @param annotation, and it is not of an object
> type), then "Text" is being used. I think this is dangerous: The user
> gets "Text" although he might have wanted something different, and the
> error might only be seen in rare cases.
> What do you think of throwing an exception in case no type has been
> specified? I think this would be only consistent, and give the user an
> error right away.

I think it should be possible to have e.g. a string argument without
configuring a validate annotation. This is convention over
configuration. And your test-case should cover the correct validation
(with some test helpers of course!) for special cases anyway.

> Second: Concerning Validation and the default errorAction: If I got it
> correctly, the __referrer is evaluated for referring back to the
> originating page where the error occured. Additionally, the _current_
> arguments are being passed onto the _last_ action. I think quite
> strange things can happen then, f.e. you can have mandatory parameters
> which are not passed to the previous action :-( Do I have some
> thinking error or is this the case? I think this whole issue can lead
> to very strange behavior...
> Maybe this can be solved by adding all current request parameters to
> __referrer, and just using them again?

No thinking error here. We have to deside what to do. As far as I
figured out, there is no general solution for that. You want to keep
submitted values, so it doesn't make sense to post the old values
back.

I think we need something like a "@onerror" annotation in a controller
action method that allows for different strategies when an error
occurs. The default strategy could be "redirect:referrer". Or a single
error method per action that you can implement to do something special
in case the action could not be called. It really depends on the
controller and actions what is suitable, but I think the CRUD cases
should work without configuration.

> Another thing which we really need to talk about: How will all these
> conventions get documented? I think documentation writing should be a
> really important task in the next weeks, as there is _a lot_ of stuff
> undocumented. I know that things have been moving really fast
> recently, but they should slowly settle down, and thus there should be
> some docs available soon.
> As soon as the documentation structure for the MVC part is clear, I'd
> as well like to help out documenting some parts as I feel that it is
> really important!

I think I can help here too.


Greetings,

Christopher