I agree that an object should *know what it is*, which includes knowing
how its surface reflects light. But the drawback is that if you build
the rendering code into each object, then a change in the look and feel
of an application can mean going from class to class and re-writing the
rendering methods. Much easier to put all the rendering code in one
place, thus the attraction to MVC and MVC2.
That said, I think the benefits of objects that know what they are and
how to render themselves can outweigh the negatives if you do it right.
In my ideal system, the objects have a "render" method that renders each
object into semantic xml (or equivalent) and includes such things as
datatype, validation rules, relationships to other data, etc. Code that
returns multiple objects, such as a list, would group this semantic XML
-- in a sorted list, or some type of tree, or a set, for example -- and
return it.
Then my "view" layer would simply be an XSLT transform (or equivalent)
that mapped the returned objects to the HTML/PDF/whatever I wanted.
Naturally, there could be many different maps.
Now my objects can render themselves into some semantic format (XML or
maybe something more JSON-like), and my view layer is a set of maps from
that semantic data to some sort of view. I have separation of concerns,
but intelligent objects as well. And I can re-use mappings across
multiple objects, so it promotes code re-use.
And there's more. Let's say that I'm creating a table of information
based on a Person class. The semantic information contained in the
"render" XML could tell me that the username is text, so make it left
flush, but the number of logins is an integer, so make it right flush,
and the current amount owed by this person is currency, so align it by
the decimal point. It might also indicate that the user's password is
secret, so replace it with a row of asterisks (or hide that column).
When the front end understands the semantic meaning of the data coming
out of the back end, it's so much more useful. I can build behavior into
the front end based on semantic information rather than having to
individually code each piece, again promoting code re-use. And if later
I decide that phone numbers should be right-flush instead of left flush,
or that they should be xxx.xxx.xxxx rather than (xxx) xxx-xxxx, it is a
simple change in one spot to fix it.
It also means that I can easily tag data in my HTML semantically, e.g.
<span class="bookTitle">Moby Dick</span>
<tr class="int"><th>Count</th><td>666</td></tr>
.bookTitle { font-style: italic; }
.int { text-align: right; }
And the ability of system objects to render themselves semantically in
XML means that I can expose the data as a web service without any extra
work at all.
I'd really like to build something like this on top of Berkeley DB XML
because it is mapped onto Berkeley DB which means that it provides the
benefits of both an XML DB and an RDBMS (indexing, etc.).
I've wanted to build such a system for about a decade now, but making a
living (and waiting for the technology to improve) has always taken
precedence. But I continue to think about such a system, so who knows?
Chas.
Viktor Klang wrote:
> Exactly, an object should know how it's surface reflects light, not some
> view-crap on the side of it.
>
> Honestly I think people advocating MVC (or MVC2, or any of the inbred
> MVC siblings) have never tried anything else.
>
> It's like those who refrain from using inheritance in their JPA models.
> Why use OO at all if everything you use are structs on steroids?
>
> Just my 2 cents!
> :)
>
> Kram!
>
> On Sun, Jan 4, 2009 at 5:58 PM, Michael <mike.sr
> <http://mike.sr>@gmail.com <http://gmail.com>> wrote:
>
>
> > Also I was looking at the sample model source code (User, ProtoUser)
> > and saw presentation logic mixed in it. Shouldn't the business and
> > model logic be kept separated from the presentation logic or is there
> > a Lift strategy it?
>
> Hmm, a model that can render itself ... That sounds like this crazy
> paradigm called object-oriented programming. Some radicals say it has
> some advantages over the more procedural style of MVC.
>
> -- Michael
>
>
>
>
>
> --
> Viktor Klang
> Senior Systems Analyst
>
> >
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---
