Here is one of my favorite approaches to this is do use static function
calls on Models:
---------------------------------------------------------------------------------------------------------
class User extends AppModel
{
function name($user)
{
if (isset($user['User']) {
$user = $user['User'];
}
return $user['first_name'].' '.$user['last_name'];
}
}
---------------------------------------------------------------------------------------------------------
Then in your view you simply do:
---------------------------------------------------------------------------------------------------------
Hello <?php echo User::name($user); ?>, this is your profile:
---------------------------------------------------------------------------------------------------------
And voilá got your business logic back in the view where it belongs to
and a nice looking way to access it.
(Warning: Not sure if other bakers consider this a good practice, but I
like it)
HTH, Felix
--------------------------
http://www.thinkingphp.org
http://www.fg-webdesign.de
tawm wrote:
> Cool, the concept of a value object makes sense to me. Too bad it's
> only planned for the 2.0 milestone ;).
>
>
> On 25 mei, 02:16, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
>
>> I would agree with you, the Model seems like the best place for this
>> logic. But accepting cake's implementation of MVC, the next best place
>> is a helper. In this case UserHelper.
>> echo $user->getFullName($data['User']);
>>
>> In the future, I believe we will have the choice of using VO (value
>> objects) instead of data arrays.
>> 2.0 milestone: "Change Models to return object instances instead of
>> arrays"
>> In which case, (IMHO) the VO would become the best place for a
>> getFullName method.
>>
>> cook
>>
>> On May 24, 6:06 pm, tawm <[EMAIL PROTECTED]> wrote:
>>
>>
>>> Hey all,
>>>
>>> I'm dealing with this design issue and I'm really curious what you
>>> guys think of it. I keep thinking I must be overlooking something,
>>> because it's such a basic thing.
>>>
>>> Ok, I've got a concept in the MVC approach, so let's say it's a user.
>>> So I've got a 'User' model, a 'UsersController' and (let's say) a
>>> 'profile' view. The 'profile' view shows the basic information of the
>>> user, such as name, age etc.. It gets this information from the
>>> UsersController in the form of a data array, which in turn is returned
>>> by a findAll() request to the model. In the model we've got a field
>>> for first name and a field for last name, since that's how it's stored
>>> in the database. But, in the view I want to print the full name. Now,
>>> the question is, where do you put the method that does the conversion
>>> from first and last name to full name?
>>>
>>> * My first thought was; in the model. This method is about nothing but
>>> a different representation of the same data, so it's clearly model
>>> material. So that would mean just add a getFullName() method to the
>>> User model and done. But this approach is problematic, since in the
>>> view all we've got is a data array (with first and last name). At the
>>> moment we want to actually get the full name for displaying it (in the
>>> view) we cannot reach the model anymore and therefore cannot call the
>>> getFullName() method.
>>> Ok, so we could call the method in the controller and pass the result
>>> to the view as a separate variable. Yeah sure, that's possible, but
>>> that's really not a very attractive solution. It would mean you would
>>> manually have to pass an extra variable to every view that wants to
>>> use the result of a partical model method call. That gets out of hand
>>> very quickly.
>>>
>>> * So we need another location for our method. What about a helper?
>>> Helpers exist to encapsulate common view processing, so that sounds
>>> like an appropriate location. But, it doesn't feel good though. If we
>>> would be discussing f.e. a date formatting method (getFullDate()) then
>>> a helper would be the perfect spot, since date formatting applies to
>>> many different model throughout one application. This is not the case
>>> with the name of a user though. Our getFullName() method applies very
>>> specifically to a user alone, so we don't want to put it in a general
>>> purpose, open scope, helper file.
>>>
>>> * Hmm, so now what? What are the alternatives? Well, we could add some
>>> postprocessing to the model's afterFind() method, in which we add an
>>> extra 'fullName' field to the data array. Ok, that's possible, and at
>>> least it enables us to keep the 'conversion-to-full-name-logic' in the
>>> model. But still, my sense of aestetics is not satisfied. All a model
>>> does in this approach is fetching and preparing a data array and pass
>>> it on to the controller. The model should stuff every possible
>>> representation of the raw data that might be needed by the view into
>>> this data array beforehand, since the model is out of reach as soon as
>>> the data ends up in the view. This feels like rape.
>>>
>>> So, what's your view on this issue? I hope I'm missing something very
>>> obvious here, or my view on software design is flawed, because it
>>> annoys me that I cannot find a pleasing solution to an issue this
>>> basic.
>>>
>>> Tim Molendijk
>>>
>
>
> >
>
>
--~--~---------~--~----~------------~-------~--~----~
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?hl=en
-~----------~----~----~----~------~----~------~--~---
