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 [EMAIL PROTECTED], 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:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109965001405546&w=2
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 (http://wiki.apache.org/cocoon/AbbreviationsInMails). Follow up in:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109965975229829&w=2
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109966621512514&w=2
I would also be interested in your comments on:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109960841308357&w=2
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 <[EMAIL PROTECTED]> To: Daniel Fagerstrom <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]>
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:
http://marc.theaimsgroup.com/?t=109941988300003&r=1&w=2
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
> http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf, 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, http://www.antlr.org Cofounder, http://www.jguru.com Cofounder, http://www.knowspam.net enjoy email again!
