[reportlab-users] Dynamic cell content in tables?

[Robin Becker]

Dinu Gherman wrote:

> Andy Robinson:

> 

>> No.

>>

>> 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,
                      rowHeights=self._argH[:n],
                      repeatRows=repeatRows, repeatCols=repeatCols,
                      splitByRow=splitByRow)

and later
if repeatRows:
     R1 = self.__class__(data[:repeatRows]+data[n:],colWidths=self._colWidths,	 
                         rowHeights=self._argH[:repeatRows]+self._argH[n:],
                         repeatRows=repeatRows, repeatCols=repeatCols,
                         splitByRow=splitByRow)

or
     R1 = self.__class__(data[n:], colWidths=self._colWidths,
                         rowHeights=self._argH[n:],
                         repeatRows=repeatRows, repeatCols=repeatCols,
                         splitByRow=splitByRow)

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

def afterSplit(self,parent,splitPart,splitByRow=True):
      .......

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... ;-)

> 

> Dinu

..........
-- 
Robin Becker