CiviCRM Community Forums (archive)

Hi,

It seems that we would benefit of being able to override the values of in an option group for a specific context. Too abstract?

Two related needs:

1) For the PDF letter format Marty idea:
http://forum.civicrm.org/index.php/topic,15419.0.html

I'm not a big fan of putting serialised/json on a text field in a db, that's getting the worse of both sql & nosql IMO.

I think that's better to store them as separate civicrm_option_values (margin-top, margin-width, page_format, whatever we need to param) from a option_group 'pdf_format'

Your read all the options of that group normally and use them as configuration values for the pdf renderer (ie. that's the same suggestions as lobo, but instead of storing them as json, you store them as separate rows).

When you want a specific format (eg for a specific layout), instead of reading them from the option_group "pdf_format", you'd read from the option_group "pdf_format_{my specific format}".

2) For civipetition, we have specific options (eg. can you sign the petition twice, can you sign as anonymous...) that are right now hardcoded. It might be nice to be able to store them in an option_group, and being able to override them for a specific petition, where you'd want to be able to sign the petition several time...

I don't think that has any impact on the schema, just a convention of how to use option_group and option_value. We might need some new methods to automatically copy all the default rows from the group pdf_format to the group pdf_format_myformat but other than that, no impact.

What do you think ?


X+

1) was meant as an example on a better solution than serializing and storing the values as a json.

How many or what are the parameters is not what I wanted to point to.

X+

hi,

my point was that there will be multiple PDF formats an org will use (each format will have the same setting but different values). not sure how you can use option group/values in a clean way in this case

Let's restart:
my initial suggestion was to solve that. the idea is to 'link' groups. took too many shortcuts, let's detail:
you store the various params (for the default format, the only one mandatory):

option_group pdf_format_default
option_value
margin:20
paper_format:letter
class PDF_generator
...whatever params needed

then the list of the various formats (user can extend)

option_group: pdf_format
option_values
big margin letter with logo :bm
letter normal:default
A4: A4

The value being the suffix to add to pdf_format_ to find the group where to fetch the params for that format, so

option_group pdf_format_bm
option_value
margin:50
paper_format:letter
class PDF_generator_logo

option_group pdf_format_A4
option value
margin:20
paper_format:A4
class PDF_generator

Am I clearer monday morning than in the week-end ?

Actually my initial though was to use directly the group id as a prefix of the custom format, but it's probably not saving any request and is less clear.

X+