> 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

Reply via email to