[TYPO3-ect] Best way to access request parameters from model?

[Johannes Künsebeck]

A little late, but...

I like the both B's, but my favorite is "B) Taking parameters from a given request object:".

A)+D) are bad, because I don't want to strip the "designator" / "prefixId" myself and I think it's 
cleaner to get the parameters concerning your extension passed automatically and to be "forced" to 
ignore the rest. But maybe we need a way to overide the "designator" / "prefixId" schema for stuff 
like 2 independent (but of the same type) extensions on the same page (perhaps set the designator by 
TS?)

C) is clean but complicated: e.g.: I would have to override my models for each type of the model 
(type like types in the BE)

B SPL-Style) is smart, but pollutes the $model where I would want to store model metadata



Elmar Hinz schrieb:
> Hello,
> 
> after a lot of experience with lib/div and different ways tested, I am still
> not sure what the best way to access parameter data from the model is.
> 
> A) Accessing the paramaters directly:
> =====================================
> 
> $uid = $_POST[...][...];
> $title = $_POST[...][...];
> 
> This is definitly the wrong way.
> 
> 
> B) Taking parameters from a given request object:
> =================================================
> 
> $uid = $this->parameters->get('uid');
> $title = $this->parameters->get('title');
> 
> In the controller you just need to do:
> 
> $model->parameters = $this->parameters; 
> 
> Or similar like lib/div currently does
> $model->controller = $this->controller; 
> 
> and in the model
> $pars = $this->controller->parameters;
> $uid = $pars['uid'];
> $title = $pars['title'];
> 
> Advantages: 
> 
>  * There is often no typing in the controller.
>  * There is few typing in the model.
>  * Unit testing can be done by defining a parameters mock object.
> 
> Disadvantages: 
> 
>  * In complex forms you sometimes have to alter the parameters object
>    several time. That works but somehow feels wrong.
>  * The model depends on a lib/div like parameters object. It can't be 
>    exported to a different environment directly. (It can be preparing 
>    a paramtersobject there, which is not that difficult.)
> 
> 
> B) SPL Style:
> =============
> 
> In the controller something like this:
> 
> $model->exchangeArray($validator); // Validated parameters in there.
> 
> In the model:
> 
> $uid = $this['uid'];
> $title = $this['title'];
> 
> Advantages:
> 
>  * Looks smart and is few to type.
>  * Unit testing is can be done be feeding a test array or mock object.
> 
> Disadvantages:
> 
>  * Quickly comes to limits  for more complex objects like those having  a
>    a list as result of the query.
> 
> 
> C) Let's call it traditional:
> =============================
> 
> For example with dedicated setter methods:
> 
> $model->setUid(...);
> $model->setTitle(...);
> ....
> 
> Advantages:
> 
>  * The objects interface is obvious and self explaining.
>  * A high level of security can be reached to check for valid data only.
>  * Unit tests are easy to write and to read.
> 
> Disadvantages:
> 
>  * A lot to type. 
>  * Difficult for autogenration or copy and paste programming.
> 
> 
> 
> 
> Please give feedback?
> =====================
> 
> There are a lot of different alternatives to do it. 
> 
> Which one do you personally think the best one? 
> What can we learn from other MVC environments here?
> What it the road to take for the beta branch?
> 
> 
> Regards
> I dont '
> Elmar
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  
> 
> 
> 
> 
> 
> 
> 
> 
>