2.1BETA1, Excel App, <e:column> facet "footer" wanted

[vladimir.kovalyuk]

Excel export is excellent, except some missed features, one of them is footer facet in column.

Export of h:dataTable does not support similar feature as well.

The second expected feature is possibility to repeat output within a cell. IFAIK corresponding JIRA issue already exists.

[nickarls]

Vladimir Kovalyuk wrote on Aug 27, 2008 20:25:

Excel export is excellent, except some missed features, one of them is footer facet in column.

You could file a JIRA for a footer facet if you are interested.

One workaround would be to place the footer there yourself with

<e:workbook>
  <e:worksheet name="foo">
    the data block
  </e:worksheet>
  <e:worksheet name="foo">
    <e:cell row="..." column="..." value="footer1">
  </e:worksheet>
</e:workbook>

i.e. have several worksheets named the same way and keep track on the number of rows and insert the footers at the last row + 1
you could also try the merge command for a common footer (never tried it but could do the job)

Vladimir Kovalyuk wrote on Aug 27, 2008 20:25:

Export of h:dataTable does not support similar feature as well.

I don't recall datatables having column footers(?) Or did you mean table level? File a JIRA for the table level headers/footers.

The second expected feature is possibility to repeat output within a cell. IFAIK corresponding JIRA issue already exists.

It's in the trunk so you could try it out if Daniels theory on ui:repeat works now (the wrap=true and \n for line breaks still apply)

[vladimir.kovalyuk]

Filled JIRA issue https://jira.jboss.org/jira/browse/JBSEAM-3341

[nickarls]

Committed support for

1. column footers (through the facet footer in column)


2. worksheet header (through the facet header in worksheet)


3. worksheet footer (through the facet footer in worksheet)

[vladimir.kovalyuk]

Nicklas, thanks a lot! I will try nightly build.

How seam-excel could help to avoid calculations of start row in the following example:

<ui:repeat var="item" value="#{items}">
  <e:worksheet name="const" startRow="#{function(item)}" var="row" value="#{item.rows}">
    <e:column />
    ...
    <e:column />
  </e:worksheet>
</ui:repeat>

Appreciate your help!

[nickarls]

Well, if you use multiple worksheets with the same name you currently need to know where to
put them in order to keep them from overwriting each other.

Of course, one think I could do is change the code so that is doesn't reset the internal
position counters when combining worksheets. Then it should continue where the last block ended.

[vladimir.kovalyuk]

Of course, one think I could do is change the code so that is doesn't reset the internal position counters when combining worksheets. Then it should continue where the last block ended.

It seems it will help. Just one question - is it possible to automaticaly arrange worksheets as follows?

<e:worksheet startRow="1" startColumn="1">
  ... spans 5 columns and 10 rows ...
</e:worksheet>
<e:worksheet>
  ... begins with column 6 and row 1 ...
  ... spans 7 columns and 12 rows
</e:worksheet>
<e:worksheet startColumn="15">
  ... begins with column 15 and row 1 ...
  ... spans 5 columns and 10 rows
</e:worksheet>
<e:worksheet startColumn="1">
  ... begins with column 1 and row 13 (due to second worksheet)
</e:worksheet>

It would be possible to insert spaces between worksheets in relative manner by placing fake worksheets in place of space.

In order to allow merging and grouping cells, placing images I would recommend to threat column and row attributes in <e:mergeCells> as relative to statColumn and startRow of worksheet. At the moment of writing they are rendered in absolute manner.

[nickarls]

Ummm, I think you are better off keeping track of the startColumn and startRow for each worksheet, it's much
more easily handled in application code than in the template or excel generator.

I'll have a look at the relative placement of the mergeCells...

[vladimir.kovalyuk]

You're right, it is not so difficult to calculate absolute rows and columns positions. For now seam-excel allows me to implement fairly complex report and it's great! For now of course ...

But I'm concerned about difficult maintenance of such sort of markup. I'm afraid if I employ seam-excel and design such a markup which contains difficult calculations in startRow attribute I will struggle with them in the future when requirements will change (and requirements for reports used to change very often).

Personally I don't like to spread concrete logic among different subsystems and languages. I like it to be incapsulated. Seam-excel does half of work to calculate cells locations within <e:worksheet>, I'd like to see it does another half to calculate <e:worksheet> locations within Excel's worksheet. It doesn't matter how it would do. I expect it just would be easy to maintain markup and make minor changes in it.
And I believe model-view-controller^opt are concerns separated from each other for no doubt certain reason.

[nickarls]

If you can come up with a solution that works for everybody then please let me know ;-)

[vladimir.kovalyuk]

It seemed to me that I suggested some extensions without huge work on your side. You already keep track of column and row positions of worksheet and it seemed that it would be not so difficult to remember them somewhere and use as the base for the further worksheet with the same name. Of course only you can estimate the effort.

Hmm, what I would do is to move table semantic away from <e:worksheet> to extra tag <e:table>. It would reflect the semantic of both tags. Then probably <e:worksheet> would introduce page-scoped variable which would tell some information about actual worksheet sizes.

I no way insist on my lamer suggestions. Just tell me your concerns about them. Probably then I could come up with something better ;) And I need extra time to have a look at sources if you expect that.

[nickarls]

Well, if you formulate the problem as how to place n blocks of data together, you need some way of telling where to place the next worksheet in relation to the previous one. Below? To the left? Somewhere else?

One option would be to define slots and a direction. Say you want to place four blocks next to each other, then you define a slot of 2x2 and a direction of vertical. Then the incoming worksheets would be placed at (col,row): (0,0) (1,0) (1,0) (1,1)

[vladimir.kovalyuk]

Yes, that's I'm looking for. Slots with directions would help.
It's even ok if I have to tell layout information for blocks within a slot.
But if that information could be calculated automatically it would be great :-)

[nickarls]

File a feature request for the Excel module in JIRA oterwise this will get lost in the forums...

[vladimir.kovalyuk]

Done,https://jira.jboss.org/jira/browse/JBSEAM-3371 and https://jira.jboss.org/jira/browse/JBSEAM-3372