Re: [Fwd: Re: Strict Separation and Attribute Rendering in Cocoon]
Terence Parr wrote:
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.
sorry for such delay. A simple example:
public class Contractor {
private String name;
private String description;
private Setprojects; //objects of type Project
// constructor, getters, setters ommited
}
public class Project {
private String name;
private String description;
private Contractor contractor;
private Settasks; //objects of type Task
}
public class Task {
private Calendar start;
private Calendar finish;
private String todo;
}
With any mature O/R tool you can do something like:
Contractor c = ormSession.load( Contractor.class, new Long( 1 ) );
passing only this object into view allows the view to access any descendant:
var model = { contractor: c }
cocoon.sendPage( contractorsProjects, model );
same for:
cocoon.sendPage( contractorsProjectsWithTasks, model );
The model is lazy loaded meaning tasks will never load if you do not
reference them in your view. Without any change to your controller you
can change your view from displaying project list to project - task list.
Now imagine you want :
* some properties pretty printed (project's description could be
pretty printed). Moreover: the user in his/hers preferences chooses
if he/she wants to pretty print projects' descriptions.
* in some views (only a part of them) some dates rendered red if date
is in past.
1. I do not feel like introducing these kinds of methods:
Project: public Node getPrettyPrintedDescription();
Task:
public boolean hasStartDateExpired();
public Node getStartDateRed();
public boolean hasFinishDateExpired();
public Node getFinishDateRed();
public Node getPrettyPrintedTodo();
2. I also do not feel like implementing some DTOs. DTOs is created with
some specific dataset in mind. So in this case DTOs with contractor data
and projects data or another DTO with contractor, projects and tasks.
Few more classes to implement and hell with view changes.
If you are able to plug rendering logic into the view itself you call
your rendering tag/function on the property that you specify. The model
is not having this knowledge and that is the cause of the problem.
Is my use case any clearer now?
my regards
--
Leszek Gawron [EMAIL PROTECTED]
Project ManagerMobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: [Fwd: Re: Strict Separation and Attribute Rendering in Cocoon]
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. Ter 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 [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-devm=109965001405546w=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-devm=109965975229829w=2 http://marc.theaimsgroup.com/?l=xml-cocoon-devm=109966621512514w=2 I would also be interested in your comments on: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=109960841308357w=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=10994198833r=1w=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
[Fwd: Re: Strict Separation and Attribute Rendering in Cocoon]
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-devm=109965001405546w=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-devm=109965975229829w=2 http://marc.theaimsgroup.com/?l=xml-cocoon-devm=109966621512514w=2 I would also be interested in your comments on: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=109960841308357w=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=10994198833r=1w=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!
[Fwd: Re: Strict Separation and Attribute Rendering in Cocoon]
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 [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-devm=109965001405546w=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-devm=109965975229829w=2 http://marc.theaimsgroup.com/?l=xml-cocoon-devm=109966621512514w=2 I would also be interested in your comments on: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=109960841308357w=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=10994198833r=1w=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!
