Jeff AA wrote:
> 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)
Yes. That's why you need to use a good templating system. There is a
plugin for date formatting in Template Toolkit and HTML::Template can do
it by using the HTML::Template::Expr module. Maybe some AxKit expert
could explain how to handle it there.
> 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.
Same deal: TT has a formatting plugin, and HTML::Template::Expr gives
you access to sprintf or an arbitrary formatting function of your own.
> 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.
A simple approach for this would be to have a data model that includes a
boolean flag for whether or not this balance is overdrawn. For example:
my $balance = {
value => -7,
overdrawn => 1
};
Note that the model object is making the decision about whether the
balance is overdrawn and no logic about that is going into the template.
Then in your template you say something like this:
[% IF balance.overdrawn %]
bgcolor="red"
[% END %]
Or whatever makes sense for your target output.
> Ok - so results from a collection of models are assembled and
> passed to the view.
One model, made up of many data objects.
> 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.
That's right.
> 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?
In the view. I'm not sure where your confusion lies here.
> 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.
That's exactly what I'm saying, except that I don't see what your
"layout manager" is for. You should just pass some data to a template
(or maybe to something fancier for certain types of output like Excel)
and then the template makes all the decisions about how to show that data.
> 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.
No problem, as I explained above.
- Perrin
