On 13-Oct-2006, at 00:58, Serg wrote:
>
> On Oct 13, 12:21 am, "nate" <[EMAIL PROTECTED]> wrote:
>> The short answer is no. Allowing the view to query model objects
>> directly violates the basic tenents of MVC separation, so although
>> Cake
>> 2.0 will support a fully object-based ActiveRecord implementation,
>> this
>> will likely never be supported.
>
> Thanks for the reasonable answer, this makes much sense for shure.
> Maybe I'm really misunderstanding some basics of MVC, so I'd like to
> clear things up.
>
> Model object (that acts more like a DAO in case of Cake) returns raw
> data which is handled by controller to the view. So it's completely
> legal to access the data in this style: $model_object['NAME']. But in
> OO code this would be done by using an accessor like
> $model_object->get_name(). I wonder if it would be legal (if it was
> possible) according to MVC, as the last thing does exactly the same -
> it provides access to data. And even in more structured way,
> because it
> gives only read access to it. And to make things even worse, let us
> assume that view accesses the data by call
> $model->get_attribute('NAME'). Does this violates MVC? I'm sad to
> think
> that answer is yes. Because upfront planning of data a view needs
> leads
> to hard coupling of C-V, breaks model incapsulation and creates
> redundant model data. By hard coupling I mean strictly knowing in
> controller what part of the model and in what perspective the view
> renders, instead of just giving model object to any view that needs it
> never caring of which particular data it would render. The approach to
> solve this problems in rails, as I know, is providing convinient data
> access methods in model that "talk" on problem domain language. That
> keeps logic close with data that it works with, and looks like a good
> incapsulation, I think.
That does not break MVC. The view calling Model::find breaks MVC. The
difference between $foo['bar'] and $foo->read_bar() is merely
syntactic sugar and possible access control, as you said. Access
control is good, however, the value of that access control must be
weighed against the model of operation of a Cake app.
Show-style actions pull data out of the Db, transform it, and send it
to the browser. Even if a view completely replaces the contents of a
received array, there is no data loss, because there is no way for
the altered data to be written back to the Db, the flow of control is
one-directional. (It could cause erroneous data to be sent to the
browser, but behaviour testing would reveal that quickly.)
In addition, it is very useful to be able to alter the data in the
view. For example, if you have a helper that generates formatted
lists of entries, it is very useful to be able to process every
DATETIME field with $time->nice(). Locking the view out of the
retrieved data would require that a complete duplicate of the data be
made and transformed. Which is wasteful of both time and space.
Edit-style actions are largely unaffected by this, as the data is
passed straight from the Controller to the Model, and only after this
has happened is anything sent to the View layer, which operates as
the show-style methods.
Ao far as I can see, all you would be getting is a different syntax
for retrieving attributes.
One of the key tenets of MVC architecture is that Models do nothing
but store and retrieve data in a consistent state, and that Views
display data to the user. The business logic is, by design, packed
into the controller. But, even in a true MVC environment, it is
possible to write Controller code completely agnostic to the data it
handles. But only for operations that are fairly generic:
function index ()
{
if (is_array($this->uses) && count($this->uses) > 0) {
$model = $this->uses[0];
} elseif ($this->uses != null) {
$model = $this->uses;
} else {
$this->render();
return true;
}
$items = $this->{$model}->findAll();
$this->set('items', $items);
$this->render();
return true;
}
But even in this example, the View does nothing but display, and the
Model (if it exists) does nothing but storage.
Unless, of course, I've completely missed you point. (Which is
entirely possible, it is rather early in the morning.)
s.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cake
PHP" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/cake-php
-~----------~----~----~----~------~----~------~--~---
