> From: Rob Nagler [mailto:[EMAIL PROTECTED]] > Sent: 31 May 2002 23:48
> Models can only express meta info about the data, not the context > in which the data is rendered. Some info, like placement, is > conditional on the grouping which is chosen by the view. A layout > manager abstracts placement using meta data supplied by the model > and context supplied by the view. This is an interesting comment. We have so far tried [successfully] to keep our document object models completely independent of the rendering component, which means the same DOM can be passed to an Excel/PDF/etc component for rendering. The challenge of course is that it is much easy to render complex things in HTML than for example Excel which imposes a global tablular view where a column can only have one width for a page. Excel does however support multiple pages, but HTML doesn't [frames?]. Whilst one can rely on scroll-bars for HTML, PDF rendering requires the component to decide on wrapping or truncating to fit page widths. We relied heavily on the layout analysis that the W3 did for CSS and HTML when desiging our DOM class, and so HTML rendering is easy. As Rob mentions in one of his emails, the HTML rendering component does not actually have to calculate final layout, as this is done by the browser. Final layouts do have to be managed by some of our other rendering components - the PDF rendering component has to understand all flow, wrap, alignment, trunctation etc layout info. Your comment seems to hint that maybe the DOM should take into account the target rendering flavour eg craft a complex DOM for HTML but a simple DOM for Excel. We chose to make our rendering components all accept complex DOMs and then make their own decisions on to best render them taking into account limitations of the target format. I don't know if this was the right decision, but it has met our requirements for fast reporting development times for over a year now, and I am hoping to take it into the HTML world. I somehow feel that the MVC and MVC+template patterns described so far in the discussions go a long way towards, but do not quite reach our desired level of reusable infra. Templating is an interesting variant, but actually solves a different problem. Perhaps we are wanting too much! I can certainly see that the MVC+ template approach is simpler, and this is the strongest point in its favour. Regards Jeff