cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [Fwd: Re: Strict Separation and Attribute Rendering in Cocoon]
Date Sat, 06 Nov 2004 10:11:09 GMT
Sorry if you get this twice, my mail connection missbehaves.

Hi Terence (and list)!

Thanks for joining the discussion. I send this to cocoon-dev. You can't 
post from the mail archive, but you can write directly to, the first message might take some hours to get 
thru as all mails from new adresses are checked to avoid spamming.

> Is there another bit where I should jump in?  I didn't have time to 
check each thread item.

It would be interesting to hear your view on:
which was the main reason for me to ask you to join the discussion. The 
acronym SoC in that mail means separation of concern and is a reccuring 
mantra in the Cocoon community
( Follow up in:

I would also be interested in your comments on:
where I discuss how MVCR could be used for input handling in form 


-------- Original Message --------
Subject: Re: Strict Separation and Attribute Rendering in Cocoon
Date: Fri, 5 Nov 2004 17:54:25 -0800
From: Terence Parr <>
To: Daniel Fagerstrom <>
References: <>

On Nov 5, 2004, at 5:27 AM, Daniel Fagerstrom wrote:
> Hi Terence!
> I have read your article: "Enforcing Strict Model View Separation in 
Template Engines" with great interest and spent some time thinking 
about how to apply your ideas in Cocoon. Especially I thought about 
applying your MVCR model in form handling, where one need the
> "inverse" of the rendering step to go from form input to model data. We
currently has a discussion about rendering in template engines and  in
our form framework at cocoon-dev:
> Parts of the discussion is of course about Cocoon specific details,  but
most of it is of more general nature. It would be very nice if you 
would like to join our discussion.

Ok, I can jump in  a bit, but I can't post I guess easily from the web
archive.  Sylvain quotes somebody else:

> > In the (often cited on this list) article: Enforcing Strict Model
> View
> > Separation in Template Engines, by Terence Parr
> >, a number of
rules for strict separation between model and view are given. One of
them is that the view shouldn't make any assumptions about data types
of the model data. The view should only get displayable strings.

and then says:

> I don't agree with this rule as, in order to avoid the view to know
about the model, it requires the model to know about the view.

Terence: I'm not sure why the model must know about the view.  Oh, you
mean because it must provide attributes that cover all possible formats
needed by the view?  Yeah, that violates separate to pass formatted data
so that is why I decided on the renderer component.  In this way, it's the
controller that is deciding how, for example, dates and money should look
(I view the controller as the collection of pages + web server etc...). 
Anyway, it's the controller not the model that has info about where a user
is coming from--not the view and not the model.
  The controller should pull from the model and shove into the view,
optionally wrapping in "paint" necessary to make it appear locally
palatable. :)

>  IMO, the
> view should be given the necessary pointers to access the model data it

Terence: The problem with the pull method is the order dependency as I
outline in the paper; to be safe all values must be computed a priori lest
the graphics designer move an attribute reference and get a null ptr or
bad data.  Further, the view is part of the program if it is deciding what
data to pull out and display.  Yes, a good programmer would limit it to ok
stuff like formatting, but at 3am when you're in a hurry for a deadline,
you'll use the arbitrary code as an expedient to get your job done.  In my
(slightly warped) view of reality, I'll
enforce any day over encourage if it's sufficiently powerful.

Is there another bit where I should jump in?  I didn't have time to check
each thread item.

Thanks for bringing this to my attention!

CS Professor & Grad Director, University of San Francisco
Creator, ANTLR Parser Generator,
Cofounder, enjoy email again!

View raw message