[reportlab-users] Dynamic cell content in tables?
robin at reportlab.com
Wed Aug 26 05:50:28 EDT 2009
Dinu Gherman wrote:
> Andy Robinson:
>> It's an annoying gap in our table model. You really need some
>> hook so that when doing a footer, it's possible to retrospectively
>> access the cells which were placed on the same page, so that you
>> can do your own totalling. At the present time the programmer would
>> have to break the table into page-sized chunks and work out the totals
>> themselves before going into Platypus.
I'm not exactly sure if a lazy flowable approach might not work. I'm fairly sure
that if the content of a flowable in a repeatable header were dynamic it
would/could draw different content each time it was used.
> That's what I thought. Which is why I solved my issue entirely
> without Platypus. That was possible, because the document was
> mostly only one big table. And, yes, it is a pain...
> That said, (static) table footers would already be helpful. It
> would be nice for the table class to have some propepr hooks
> called when a frame/page split does occur. That would make
> things almost trivial.
The table class does have a split method (and _splitRows), but there is no
method that hooks the internal split creation itself.
Effectively we have two creations
R0 = self.__class__( data[:n], colWidths=self._colWidths,
R1 = self.__class__(data[:repeatRows]+data[n:],colWidths=self._colWidths,
R1 = self.__class__(data[n:], colWidths=self._colWidths,
presumably for R0 and R1 we need to inform at creation time that they are
offspring of an earlier table and which part of the split they are.
Possibly we could add an afterSplit method ie
that should allow table classes to mess around with their data as they see fit.
I suspect that in fact you'll need finer control than just the split ie some
indication that the footers/headers etc are about to be drawn. That might make
the dynamic lazy flowable approach easier. However, since we don't have footers
as yet, we have a problem doing that.
Footers would be a good start. However, I think they complicate things quite a bit.
> Makes me think of an altertables package... ;-)
More information about the reportlab-users