> From: Perrin Harkins [mailto:[EMAIL PROTECTED]] > Sent: 31 May 2002 16:27
Perrin, fab feedback as ever, I think I am almost at the 1,000 thanks for Perrin level 8-) - oh, and 1,000 apologies too, for all the questions you've answered before! I hope you don't mind me pestering you with yet more MVC questions! > For more background on templating tools, see my article here: > http://perl.apache.org/features/tmpl-cmp.html Very interesting, and obviously more to look into... describes the Pipeline model as more MVC. > Ideally you should have no style information at all in the model. Ok - but based on my experience with our reporting system which currently renders in PDF, Excel, Text and HP-PCL, the rendering engine aka View needs to know a little more... For example to render a date in Excel some jiggery pokey is required, and I would also expect a HTML V to print pretty dates rather than 20020531172534 (or something other than the raw stringification) We also deal with lots of numerics - some are quantities, and others are values or interest rates - they need zero, 2 or 4dps when being presented. And don't forget the 1,000's separator - I want real Excel numbers, that users can SUM() but which are presented as commified, whereas the HTML V will have to commify the numerics itself. >> How does the view layer know for example to render an Error cell >> as RED in HTML but blue in Excel due to Excel palette limitations? > >You have different views for different targets. Make an HTML view and >an Excel view and have the controller know which one to use. This was more a question about how a View would decide to render a style like OVERDRAWN / ERROR rather than which view to use - ie the same as the issue above about working with more than strings. > the model provides the list of errors, and the view knows how to > display them. Apologies, my use of the word ERROR has confused folks. I was not talking about errors that occurred in the model processing, but rather about more advanced STYLES that might be applied to an element (eg a cell in a table) for some business reason. So for example if your savings balance has gone negative, the value should be rendered as an error balance rather than a normal balance. In HTML you might choose to display the cell with a RED background, but this does not work in Excel, where a RED background prints as black, so you can't just tell the view RED - you need to tell it the reason and let Excel choose one of its limited bg colours. > The model might be made up of dozens of different classes Ok - so results from a collection of models are assembled and passed to the view. >> What controls the overall layout? > The view. > >> e.g. what is the equivalent of the >> 'Grid Bag' layout manager - is this done in the Controller? and then >> passed to the View with all the data from a set of Models? Or do you >> make the Controller minimalist and have a meta-Model that assembles >> all the sub-Models into a layout. mmmm - not sure if I like this. I thought the whole point of the View was to contain all the logic about things like HTML tags or Excel binary representation etc, and as little as possible about other things. Layout man agent is a problem that has been isolated in other langs - the Grid Bag layout manager is an [old!] Java class that manages the interaction of collection[s] of widgets and sub-forms on a screen and is esp. useful when screens can be dynamically resized, and controls, text etc will flow / realign / resize and generally shuffle about. In HTML things like the WIDTH=100% attribute of a table or TD are directives to the HTML layout manager implemented in browsers. The layout manager is usually concerned with several elements of the interaction of a collection of things - alignment, flow and sizing. Exactly where in the MVC world, would I decide that column 3 which contains a description should expand to fill 70% of the available space and that column 5 which contains a possibly long name should use the remaining available space, whilst column 1 which contains a name should not be wrapped? I think of a layout manager as a collection of hints to the V on how all the bits should be fitted together in relation to each other. I want my various Vs to be supplied data from the same set of Models - but don't forget that the PDF V will not support scroll-bars! Poor ol PDF-V will have to intelligently render data that does not fit within the width of the users selected physical page width! I guess I have talked myself round to thinking that the Controller is actually the layout manager, in that it marshals results from a set of models, decides how this collection should interact, and then asks an appropriate View to render the result in a specific interface flavour. Have I talked myself out of HTML:Template route? Not sure, I guess it depends on whether HTML::Template can be smartened up to understand that I want Dates rendered in a pretty format, quantities should be commified, cash values must have commas and 2dps, interest rates should have 4dps and cells with an error attribute should have a red background. mmm - I will also think more about the layout manager - methinks I need to mull over other possible implementation arrangements... > I wrote about this in my article on the eToys system: > http://www.perl.com/pub/a/2001/10/17/etoys.html I remember reading this at the time - and will re-read it with a fresh perspective. Thanks again for all the info and experience. Regards Jeff
