[Nitro] xhtml builder in model?
rainhead at gmail.com
Tue Sep 6 14:00:40 EDT 2005
Thanks a lot for your message. The article looks very interesting,
I'll read it in a minute.
What you and Allen Holub say seems very intuitive to me. In my view,
an object--in Nitro, an entity--ought to know how to express itself.
It's the controller's responsibility to make things express
themselves in a coherent visual and code environment. Templates (are
these really the V in MVC?) are split off more for the benefit of
letting designers not have to wade through program code. Some of them
are for the benefit of models (entities) and some for the benefit of
controllers (e.g. how to build a page).
Or maybe this is simply not an MVC model? I don't know much about the
models one finds in the literature, I just knew how I wanted to
organize my program, and Nitro seemed flexible enough to let me do that.
All that said, it seems clear that by my own logic, the edit_form
ought to be an .xhtml template. Though, since I'm (presently) playing
all roles in my project, it doesn't yet make that much difference.
Relatedly, I'm really looking forward to some good tools for building
forms. George, have you ever seen Zope's Formulator product? It's
pretty impressive, and was the first tool of its kind when it came
out some years ago. Maybe it could give you some inspiration :)
Sorry, couldn't find the old tutorials. For all of Zope's problems,
they had (I think it's appropriate to use the past tense at this
point) there was some cool stuff going on there.
On Sep 6, 2005, at 9:51 AM, James Britt wrote:
> Is this a case, though, of having the model (e.g., that data)
> getting mixed up with the presentation, breaking MVC?
> On the other hand, I'm reminded of Allen Holub's articles on doing
> GUI stuff in Java, where he derided getters and setters, and said
> something along the lines of objects should know how to render
> I'll explain the whys and wherefors in a moment, but here are some
> rules of thumb that you can apply to see if you're really looking
> at an object-oriented system:
> 1. All data is private. Period. (This rule applies to all
> implementation details, not just the data.)
> 2. get and set functions are evil. (They're just elaborate ways
> to make the data public.)
> 3. Never ask an object for the information you need to do
> something; rather, ask the object that has the information to do
> the work for you.
> 4. It must be possible to make any change to the way an object
> is implemented, no matter how significant that change may be, by
> modifying the single class that defines that object.
> 5. All objects must provide their own UI.
> If the system doesn't follow these rules, it isn't object-oriented.
> It's that simple. That's not to say non-object-oriented systems are
> bad; there are many perfectly good procedural systems in the world.
> Nonetheless, not exposing data is a fundamental principle of object-
> oriented systems. If you violate your principles, you're nothing,
> and the same goes for object-oriented systems. If a system violates
> object-oriented principles, it isn't object-oriented; it's some
> sort of weird hybrid that you may or may not ever get to work right.
> So, does this suggest that if I want to render, say, an Account
> object in a Web page, I should do something like this:
> <%= account.render( xhtml_form_builder ) %>
> where xhtml_form_builder is some object that an Account instance
> knows how to manipulate without needing to know the specifics of
> the rendering environment?
> Nitro-general mailing list
> Nitro-general at rubyforge.org
More information about the Nitro-general