Empty table not allowed, but could be useful

[Tonypm]

Hi,

Using Prawn::Table, I have hit a situation where a table can have a
header, but no data. However, this causes the table method to raise
an error. Might it be useful to allow this situation.


Tonypm

[Gregory Brown]

How could it be useful?

-greg

[Jesús García Sáez]

> --
>
> You received this message because you are subscribed to the Google Groups "Prawn" group.
> To post to this group, send email to prawn...@googlegroups.com.
> To unsubscribe from this group, send email to prawn-ruby+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/prawn-ruby?hl=en.
>
>
>

You could always put empty strings.

I'm with Gregory, empty tables don't make much sense, I'd rather
prefer (when there is no data for some reason) to get an exception
than an empty table will be drawn (because probably it'll be an error
in your code)

[Wojciech Piekutowski]

2009/11/26 Jesús García Sáez <bla...@gmail.com>:

Sometimes there's a need to create printing materials, where the table
is empty on purpose. Later somebody will print it out and fill it with
a pen. In such case it feels awkward to have to fill it with empty
strings or whitespaces.

To be strict empty strings as data don't make a table 'not empty' so
the exception should be raised too. ;)

Greetings,
Wojtek

[Gregory Brown]

In this case, I'm not sure I agree that empty strings are that bad
(nil would work, too)

table [[nil]*5]*5, :column_widths => { 0 => 100, 1 => 100, 2 => 150, 3
=> 150, 4 => 75 }

Doesn't look horrible to me. If this were commonplace, I'd allow for:

table(:rows => 5, :columns => 5, ...)

But I don't think it is. This seems like API bloat for something
which could be done in a user created subclass, no?
Of course, I could be convinced if I hear more evidence of people
actually wanting this feature.

At any rate, this is not what the OP was asking for. He was looking
for table([], options) to generate *just* a header column. To me
this is too uncommon to support, and would prevent us from easily
catching bugs related to expecting a 2d array but getting something
1d, or having a mismatch in number of columns.

> To be strict empty strings as data don't make a table 'not empty' so
> the exception should be raised too. ;)

I don't understand what you mean here. are you saying that if
row.all? { |e| e.empty? } we should raise an error? I think that's
crossing a line...

-greg

[Tonypm]

Hi,

thanks for your comments Greg. I actually hit this situation whilst
building a page, since I was laying out my page without initially
worrying about creating data.

However, it seemed that if I create a standard layout for say a
regular report with fixed results areas, and on some occasion one of
my results sets returns no values, then I would still want the table
as a positioned element on the page.

It just seemed a bit odd to me that to do that I would have to
artificially add a blank row to my results set to circumvent an
exception check that may not have been needed in the first place. ie.
would it really cause problems to the code further along if there were
no data to render - just headers? But it's no big deal I guess

Tonypm

[Gregory Brown]

On Fri, Nov 27, 2009 at 2:01 AM, Tonypm <tonyp...@hotmail.com> wrote:
> Hi,
>
> thanks for your comments Greg.  I actually hit this situation whilst
> building a page, since I was laying out my page without initially
> worrying about creating data.
>
> However, it seemed that if I create a standard layout for say a
> regular report with fixed results areas, and on some occasion one of
> my results sets returns no values, then I would still want the table
> as a positioned element on the page.

Really? Probably depends on your requirements. Would it be
unreasonable to say:

begin
table ....,
rescue ...
text "There was no data for this report"
end

> It just seemed a bit odd to me that to do that I would have to
> artificially add a blank row to my results set to circumvent an
> exception check that may not have been needed in the first place.  ie.
> would it really cause problems to the code further along if there were
> no data to render - just headers?  But it's no big deal I guess

I think that in most cases, no data is an error people want to find
out about. I think that what you have is an edge case, and I rather
help the common case in debugging.
If you aren't custom styling your headers, you can definitely do something like:

if data.empty?
table HEADERS, ....
else
table data, :headers => HEADERS
end

If we see a rather large outcry from other users that I'm off base
here, I'll consider changing the behavior. But for right now I don't
feel like there is a reasonable unsurprising way to handle tables with
no data in them.

-greg

[Sylvain Abélard]

Hello all, and thanks for the great job on Prawn !
I agree with the "placeholder" side but I don't think "really empty"
data should throw an exception.


For me, a table with "really" no data is not an error : nothing to
output is no sin.
In most apps, an empty list or empty search result is rarely a
problem.
If your requirements say that shouldn't happen, just do the check in
your code: that's a single line!

Plus, OP's use-case (headers with no data) does seem useful to me, and
not too uncommon: I have this in my lots of my invoices in real life.
Moreover, if you do what OP recommends, you'll still have a way to
throw and Exception, but in the current situation OP cannot workaround
Prawn::Table.
A compromise could be an ":allow_blank" option, but in my mind that
would uselessly clutter the code and documentation.



Placeholder "blank data", ie. cells that will be filled by pen can
sure be useful, but easily done by Greg's single line of code.
But I don't think it's a common need, and since the solution is
trivial, in my mind doesn't deserve a feature.

Just my two cents,

[Gregory Brown]

On Fri, Nov 27, 2009 at 5:18 AM, Sylvain Abélard

> Plus, OP's use-case (headers with no data) does seem useful to me, and
> not too uncommon: I have this in my lots of my invoices in real life.
> Moreover, if you do what OP recommends, you'll still have a way to
> throw and Exception, but in the current situation OP cannot workaround
> Prawn::Table.
> A compromise could be an ":allow_blank" option, but in my mind that
> would uselessly clutter the code and documentation.

It's a valid point, and something I'll consider. But can we nail down
what the behavior should be? Are we talking rendering *just* a
header row? Or do we want to make it visually clear that it is a
table missing data (by including some empty whitespace). Let's try
to identify the behavior people like most and then go with that.

-greg

[Henrik Nyh]

I think only header row would be best, since that also allows you to
get one (or more) empty rows by using arrays of nils/empty strings,
but doing it the other way around means no easy way to get a header
row only.

I imagine that you in some cases may want to have e.g. a header row
followed by no rows but text like "No data."

[Gregory Brown]

Sounds reasonable. Tony, Sylvain is this what you had in mind?
If so, let's get a ticket filed in prawn-layout.

-greg

[Tonypm]

Yup, Just a header row would be exactly what I would prefer.

Thanks
Tonypm