Ok. I’ve been thinking about the “ObjectParameters” a bit more and have decided this isn’t modeling the situation properly. For example, any parameters needed for View logic shouldn’t really be in a set of “object” parameters, but rather in a “view” parameter set. This would simplify calling the parameters in the view for any necessary formatting purposes.
I am considering using Symfony’s HTTP foundation to create the request object. It sets up ParameterBag objects within the Request object and in this fashion, I am thinking we need to have two additional sets of parameters added to the request object to make my suggested MVC system work properly. A view and an object parameter bag.
However, before we can create these parameter bags, we’d need to send off the request to a system, which would decode the request into the client developer’s intended “conditions”. This would be along the lines to the well known routing logic, but instead of saying “Ok, because the call to the server is this, do controller XYZ”, we simply create the necessary “conditions” for the view and the model and leave out the controller, because we don’t need it. These new parameters are then used to control either formating in the view or to add logic to help formulate or format the model.
Actually, let’s call it just that. FormatConditions.
This is what I am looking at now.
Now to put it into (proper) code.
Scott