Refactored the way Cell.make decides which cell renderer to use for easier enhancement/overriding.
allow self registry of cell renderers
retrofit self registry of cell renderers with factory
searching cells in reverse allows overriding
What is that status of this pull request? I am interested in enhancing table support for cell rotations and merging cells and it would be nice to know if this code is going to be accepted or rejected or if additional work is required for acceptance.
This is a neat idea, but I'm hesitant to try merging a three year old patch thats semi-complex before 1.0, and would prefer if we started fresh with this idea after 1.0.
Very sorry that we never gave a proper response -- the project has been badly understaffed for quite some time now.
@packetmonkey: This looks like the kinds of changes you are interested in seeing in Prawn. If you're interested in picking this pull request back up and giving it a closer review, we can reopen.
I'm not sure I understand a good use case for this, beyond a more OOP design.
Does anyone have a good example for me to wrap my head around?
I had a project that required boolean valued cells to render as a checkbox. Instead of having to create the cell manually I refactored cell creation into a strategy pattern that was a little more extensible.
In hindsight having the cell renderers auto register and the factory being a singleton proved less malleable than I had intended. I no longer maintain the project I did this for but if there is interest I wouldn't mind lending a hand.
@maedhr: Thanks for the explanation. I've re-opened this to remind me to give it a little bit more thought and a closer review when I get time for it, even if it means rethinking the implementation.
@packetmonkey, you're also welcome to chime in w. ideas if you have any.
@maedhr: What do you think of the idea of allowing tables to render arbitrary cell-like objects, as long as they implement a certain protocol?
That would have enabled you to wrap your booleans in something like a CheckboxCell class, and then Prawn's table code would query that for size information and call render() on it, or something like that.
There doesn't appear to be a huge demand to move this forward. Although I think it's a good idea, I'm going to close it out until someone volunteers to push it along. My own backlog is too full right now.