cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Terence Parr <>
Subject Re: [Fwd: Re: Strict Separation and Attribute Rendering in Cocoon]
Date Tue, 09 Nov 2004 19:17:26 GMT
Hi Daniel and cocoon folks :)

Leszek Gawron wrote:

> - break whole entity tree

How does wrapping data with a renderer touch the model?  What entity 
tree do you mean, actually?

> - forget about lazy-loading

If you're pulling from the db each query you have a problem no matter 
what.  God invented RAM for a reason ;)

> - fetch data on each level separately

Not sure what you mean?  I have a simple recursive walk of a 
hierarchical menu in my paper that works great.

> - prepare some kind of DTOs that would apply "view needs" to data 
> stored in
> database

Not sure what you mean.  The controller knows the locale and "paints" 
objects before they are sent to the view.

> - build another object graph only for the sake of one view
> and above all:

Well, you need to store raw data somewhere and then change per locale.  
There is no way around this.  Either you have IFs or you wrap data in a 
formatter, right?

> - change my model every time I change view template

How so?  Wrapping a model object does not affect the model.

Perhaps I specific examples perhaps to see your point.


On Nov 6, 2004, at 1:59 AM, Daniel Fagerstrom wrote:

> 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 
> processing.
> /Daniel
> -------- 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!
> Terence
> --
> CS Professor & Grad Director, University of San Francisco
> Creator, ANTLR Parser Generator,
> Cofounder,
> Cofounder, enjoy email again!
CS Professor & Grad Director, University of San Francisco
Creator, ANTLR Parser Generator,
Cofounder, enjoy email again!

View raw message