This sounds very close to what we tend to do at Unspace these days.
Doing things like, @user.name to return "#{first_name} #{last_name}".
I believe that allowing models to have some formatted output can be
very useful when interacting with that object. Also, it can allow you
to easily make changes site-wide when you need to change one of the
accessors. For instance, if you wanted to add in the middle name or
their login, you can do it with your accessor.
In MVC with applications, (before we started doing it on the web) we'd
often make the model objects return sensible human-readable
information from themselves. The view was never responsible for data-
formatting.
Internally, we refer to these model-methods as "accessors".
I have actually thought about writing a good bit about those best
practices, but I just never seem to get the time to actually write it
all down. Its good to see other people are starting to think down the
same path as me though.
-hampton.
On Feb 2, 12:25 am, "DWF" <[EMAIL PROTECTED]> wrote:
> Hampton made this claim in a thread a couple of weeks ago and I think
> I finally get it.
>
> This is all because I'm still wrestling with my own practice of what
> goes in a model/helper/template. Now that I've done a few projects I
> think I'm using these rules.
>
> Model:
> - methods can:
> - reformat an existing attribute in a way that does include any
> HTML
> - format a combination of two or more attributes in a way that
> does not include any HTML
>
> Helpers
> - methods can:
> - provide format for one or more attributes of one or more objects
> that does not include HTML
> - provide format for any input data that requires HTML
> - determine their output from one or more attributes of one or
> more objects
> - should call render :partial => 'foo' whenever structure is
> required
>
> View Templates (in HAML, duh)
> - everything that involves structure/HTML
>
> I had a discussion with another Rails developer yesterday where he
> said he HATED putting any View-ish methods in the Model. But I have
> plenty of places where the way that the data is stored in the DB just
> isn't useful in any View -- Date & Time especially. In fact, I should
> write a module that has happy date & time humanizer methods and then
> include that in appropriate Models.
>
> Thoughts? Is this close to Best Practices? Or am I on a path to ruin
> in despair with larger projects?
>
> --dwf
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Haml" 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/haml?hl=en
-~----------~----~----~----~------~----~------~--~---
