On 18.02.2009, at 08:36, Michal Charemza wrote:
I'm having trouble getting validation and the Form Population Filter (FPF) to work as I expect, when the action that processes the form is called as a slot within another action. I wonder if just my understanding of what is going on is wrong. I have some general questions:
You shouldn't do that under any circumstance; my other mail explains that.
- What is the data 'flow' of input (say, from the actual $_POST variable), through validation and into an action (where it ends up as the AgaviRequestDataHolder).
Uhm... yes? :p That's how it works. On startup, the framework populates the "global" request data object you don't have access to in actions and views. Every container receives a copy of this.
- What is the data 'flow' of input through validation and into an action called within another action. Is the validation from the *outer* action also applied?
No. Each action (slot or not) must validate separately. Note that containers may be given "arguments" to work with, which are merged into the request data. A container's request data is, after creation, simply a copy if the global request data object. If an action is "simple" (AgaviAction::isSimple()), then there won't be any request data, only explicitly given arguments. Those don't have to be validated (validation is not performed for simple actions, and no filters are run, and no security checks are performed, and the action isn't run - only the view).
- How are these 'flows' different if there is a validation error?
They aren't.
- At which stage does the FPF get its data? At what stage do the validation errors get passed to the FPF?
FPF grabs its validation report data from the container that was used to run the initial request. The data to populate the form with, on the other hand, comes from the global request data object.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ users mailing list [email protected] http://lists.agavi.org/mailman/listinfo/users
