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

[ries van Twisk]

a) is bad...

b) I like this method best, less typing and quicker development.
The live time of an average PHP application is short anyways.
So far I never had to modify anything as you describe,
but I never had complex forms (what are complex forms??).
About the disadvantages.
1) I never had teh problems with complex forms, not sure what they are..
2) These MVC objects work closely related anyways and the parameters
will be more or less the same. I don't see how a news controller
would start interacting with a calendar controller anyways...

c) I don't like to do that in a MVC model, only for libraries it's  
use full.

B) it is for me....

Ries




On Oct 2, 2007, at 2:04 AM, Elmar Hinz wrote:

> 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
>
> Elmar
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> TYPO3-team-extension-coordination mailing list
> TYPO3-team-extension-coordination at lists.netfielders.de
> http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team- 
> extension-coordination

--
Ries van Twisk
Freelance TYPO3 Developer
email: ries at vantwisk.nl
web:   http://www.rvantwisk.nl/
skype: callto://r.vantwisk
Phone: + 1 810-476-4193