[Nitro] xhtml builder in model?

TRANS transfire at gmail.com
Wed Sep 7 00:23:57 EDT 2005


On 9/6/05, James Britt <james_b at neurogami.com> wrote:
> TRANS wrote:
> ..
> 
> >
> >
> > Crap. Don't listen to that drival. While the idea has merit up to a
> > limited scale it quickly turns into hell fire. And poos on SOC. Are
> > you really going to teach each object how to display itself in PDF,
> > XML, RDF, ASCII-Art, as infinitum. I don't think so.
> 
> No, I thin the idea is to be able to do something like this:
> 
> my_model.render( pdf_writer )
>   or
> my_model.render( wml_writer )
> 
> where all *_writer objects expose a known API; my_model need only know
> about that single API, passing data to the writer object.  The writer
> need not know the data details of my_model.

But what does that amount to? Both writer's have to have the same API.
That can be difficult, commonly resulting in an LCD effect. Even so,
you've reduced the problem to a single interface writer->model, but
it's a  one-to-one mapping so you can turn it orthogonally and do
model -> writer. It amounts to the same thing.

  class Writer
    def render( model )
      do_this(model.x)
      do_that(model.y)

  class Model
     def render( writer )
         writer.do_this(self.x)
         writer.do_that(self.y)

> > Your going to
> > convert it to ONE common format, say some nice YAML, and then write
> > Renders for that --is dumping YAML considered accessing public data?
> > Now for a _main_ intereface, say a GUI, sure that's reasonable, but if
> > you really want to get high class you'd use AOP to "weave" the
> > Rendering into the object, thus maintining SOC at the same time.
> 
> Except I think that leads to coupling between the model's YAML and the
> rendering code.

A coupling is inevitable. In fact that's exactly what you are after.
The choice that really matters is to make it generic or specific, not
whater the model does it to the controller or vice versa --that's
mostly just a matter of perspective.

> >
> > As usual balance is key. I'd be wary of anyone who makes ultimatiums
> > like: "If the system doesn't follow these rules, it isn't
> > object-oriented. It's that simple."
> 
> Well, such statements may be designed more to provoke discussion than to
> actually assert something as fact.  "Hype is the new black", and all
> that.    But I believe he is essentially correct.

Correct as in a fact? This is subject and is all about where you
stand, and what works. Taken as fact, this purity of reason could have
one expecting a baseball to know how to be hit by a bat.

> >>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?
> >
> >
> > Feasible. Is it really much different then an elaborate:
> >
> >   out = my_form_str % account.data_for_my_form_str
> >
> 
> Depends.  Who is asking whom for what?  In which direction do (most of)
> the dependencies go?

That is a good question, b/c that will generally determine LOC.

T.




More information about the Nitro-general mailing list