Wow Felix! Didn't think of that one yet. That's actually a very smart
way of achieving exactly the functionality I wanted, with all the
benefits of the design I wanted. Actually, since a model class in
CakePHP will never have more than one instance (at a time) using
static methods is practically identical to using instance methods. If
someone considers this bad practice I'm really curious for his
arguments...
On 25 mei, 10:52, Felix Geisendörfer <[EMAIL PROTECTED]> wrote:
> 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.orghttp://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
-~----------~----~----~----~------~----~------~--~---
