PrawnCocktail mini-framework for Rails

[Henrik N]

We've evolved a mini-framework on top of Prawn in Rails to get a split into documents, templates and helpers: https://github.com/barsoom/prawn_cocktail

It's certainly not perfect but I find it helps maintainability to have some structure, as opposed to just putting it all in one big file.

The first reason for writing this post is to get it out there. Please try it and contribute bug reports, suggestions, patches or whatever.

The second reason is that I'm curious what strategies others have used to make Prawn documents maintainable as they become more complex. Please share!

[Brad Ediger]

On Sat, Feb 23, 2013 at 4:23 AM, Henrik N <hen...@nyh.se> wrote:
> We've evolved a mini-framework on top of Prawn in Rails to get a split into
> documents, templates and helpers: https://github.com/barsoom/prawn_cocktail
>
> It's certainly not perfect but I find it helps maintainability to have some
> structure, as opposed to just putting it all in one big file.

This is awesome. I do have a lot of Prawn code out there that has
evolved "PHP 4 style", as you say, and this is definitely an
improvement.

My main architectural comment about this project is that it feels like
you have two orthogonal concerns coupled together:

1. A handy DSL for structuring data-driven PDFs;
2. Rails integration to simplify the common cases of web PDF rendering.

I think there are valid use cases for using either of the two
separately. Personally, I have a lot of non-Rails Ruby projects using
Prawn that would benefit by building on top of #1. And #2 would
provide a small stepping stone for eliminating boilerplate from
existing Rails projects without necessarily needing to rebuild views
the "PrawnCocktail way" at first. So I think if they could be
decoupled into two separate projects, it would be a net benefit.

It's always interesting to see what people are doing with Prawn, and
to start to develop some vocabulary and patterns for common Prawn use
cases. Thanks!

-be

[Henrik N]

On Saturday, February 23, 2013 4:35:09 PM UTC+1, Brad Ediger wrote:

On Sat, Feb 23, 2013 at 4:23 AM, Henrik N <hen...@nyh.se> wrote:
I think there are valid use cases for using either of the two 
separately. Personally, I have a lot of non-Rails Ruby projects using
Prawn that would benefit by building on top of #1. And #2 would
provide a small stepping stone for eliminating boilerplate from
existing Rails projects without necessarily needing to rebuild views
the "PrawnCocktail way" at first. So I think if they could be
decoupled into two separate projects, it would be a net benefit.

Thanks for the feedback! And that's a great point. It would be nice for testing purposes, too, to separate it cleanly from Rails. I'll definitely look into that.

[Henrik Nyh]

On Sat, Feb 23, 2013 at 4:53 PM, Henrik N <hen...@nyh.se> wrote:

Thanks for the feedback! And that's a great point. It would be nice for testing purposes, too, to separate it cleanly from Rails. I'll definitely look into that.

Alright, now it's split up:

https://github.com/barsoom/prawn_cocktail

https://github.com/barsoom/prawn_cocktail_rails 

[Brad Ediger]

Looking good. My remaining comment is that it would be nice to remove
the ActiveSupport dependency in prawn_cocktail. AS can be kind of
heavy-handed in non-Rails applications, and I've had more than my
share of problems with conflicts it's caused. But this is a step
forward in any case. Nice work!

Brad

[Henrik Nyh]

On Mon, Feb 25, 2013 at 8:39 PM, Brad Ediger <brad....@madriska.com> wrote:

Looking good. My remaining comment is that it would be nice to remove

the ActiveSupport dependency in prawn_cocktail. AS can be kind of
heavy-handed in non-Rails applications, and I've had more than my
share of problems with conflicts it's caused. But this is a step
forward in any case. Nice work!

Thanks! I only use two methods from it, so it would be a pretty easy thing to bundle with the lib. Probably will at some point.