cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject [Fwd: Re: Strict Separation and Attribute Rendering in Cocoon]
Date Sat, 06 Nov 2004 09:59:21 GMT
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
> needs.

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