ChiliProject is not maintained anymore. Please be advised that there will be no more updates.

We do not recommend that you setup new ChiliProject instances and we urge all existing users to migrate their data to a maintained system, e.g. Redmine. We will provide a migration script later. In the meantime, you can use the instructions by Christian Daehn.

[Proposal] Custom Fields rework

Added by Felix Schäfer at 2011-07-05 09:20 am

As noted in #498, the currrent custom field implementation is showing some limitations.

I propose subclassing CustomField to type-specific classes (CustomField::String, CustomField::Text, CustomField::Integer and so on) similar to what is done for Repository. I hope we can then also define subclass-specific relations to specific custom values (CustomValueNumeric, join table with some core models…) and thus have better DB queries and more flexibility regarding new custom fields.

I'll try some things out and probably add a branch to the core repo at some point.

Thoughts?


Replies (3)

RE: [Proposal] Custom Fields rework - Added by Eric Davis at 2011-07-06 11:31 pm

One problem I see is that CustomFields are already using STI and the type field for the owning object (e.g. IssueCustomField). I don't know how that would work with modules (e.g. IssueCustomField::String, FooCustomField::String). I was doing some work on the formats (Redmine::CustomFieldFormat), maybe we could subclass that class and delegate custom fields methods to the format? (e.g. CustomField.format => CustomFieldFormat::String)

I'm open to ideas. I wanted to finish refactoring custom fields and extend them later this year to support more data types but I'm happy to pass the code onto someone else if they want ;)

Eric Davis

RE: [Proposal] Custom Fields rework - Added by Felix Schäfer at 2011-07-08 08:05 pm

Eric Davis wrote:

One problem I see is that CustomFields are already using STI and the type field for the owning object (e.g. IssueCustomField). I don't know how that would work with modules (e.g. IssueCustomField::String, FooCustomField::String). I was doing some work on the formats (Redmine::CustomFieldFormat), maybe we could subclass that class and delegate custom fields methods to the format? (e.g. CustomField.format => CustomFieldFormat::String)

That's exactly the point I'm stuck at, would be so much easier if doubly polymorphic associations were possible/easy ;-) Well, one way that might work if in each FooCustomField we defined the FooCustomField::Bar class for each Bar, but that's a potentially too rapidly growing number of classes I guess.

Another Idea I wanted to explore was to see if a module could be included into AR objects depending on a custom_field_type column, so that something like CustomFieldFormat::Bar could be included dynamically. What would definitely be great would be if we could define CustomValue associations from the module so that each custom field type can be associated to the best fitting custom value.

I guess the delegate would work in any case, I'd have to read up on that pattern to give a definitive answer though.

I'm open to ideas. I wanted to finish refactoring custom fields and extend them later this year to support more data types but I'm happy to pass the code onto someone else if they want ;)

I'd be happy to have a look at the code. As I said, I'm looking for solutions to the "double polymorphism" thing, I think once that's out of the way the rest won't be too hard.

RE: [Proposal] Custom Fields rework - Added by Eric Davis at 2011-07-08 09:12 pm

Felix Schäfer wrote:

Eric Davis wrote:

One problem I see is that CustomFields are already using STI and the type field for the owning object (e.g. IssueCustomField). I don't know how that would work with modules (e.g. IssueCustomField::String, FooCustomField::String). I was doing some work on the formats (Redmine::CustomFieldFormat), maybe we could subclass that class and delegate custom fields methods to the format? (e.g. CustomField.format => CustomFieldFormat::String)

That's exactly the point I'm stuck at, would be so much easier if doubly polymorphic associations were possible/easy ;-) Well, one way that might work if in each FooCustomField we defined the FooCustomField::Bar class for each Bar, but that's a potentially too rapidly growing number of classes I guess.

Another Idea I wanted to explore was to see if a module could be included into AR objects depending on a custom_field_type column, so that something like CustomFieldFormat::Bar could be included dynamically. What would definitely be great would be if we could define CustomValue associations from the module so that each custom field type can be associated to the best fitting custom value.

I guess the delegate would work in any case, I'd have to read up on that pattern to give a definitive answer though.

Simple example.

 1class CustomField
 2  def custom_field_format
 3    custom_field_type.classify.constantilize.magic.rainbows # convert "user" to CustomFieldFormat::User
 4  end
 5
 6  delegate :to_s, :to_object, :to => :custom_field_format, :prefix => true, :allow_nil => true
 7end
 8
 9# assume user 1 is Eric Davis
10c = CustomField.new(:custom_field_format => "user")
11c.value = 1
12c.custom_field_format_to_s # => "Eric Davis" 
13c.custom_field_format_to_object # <User::ActiveRecord id:1...>

I'd be happy to have a look at the code. As I said, I'm looking for solutions to the "double polymorphism" thing, I think once that's out of the way the rest won't be too hard.

My first step was to get HTML-ish custom fields working. This first required each CustomFieldFormat class to define if it's content needed to be h() escaped or not.

https://github.com/edavis10/redmine_url_custom_field/blob/master/init.rb

Eric Davis

(1-3/3)