#97 ✓resolved
James

Add choices/enumerations to extended fields

Reported by James | October 17th, 2008 @ 11:05 AM | in 1.2

  • Create a Choice model with label and value attributes
  • Create what is called a “polymorphic join model” in Ruby on Rails to associate choices with things that can have choices, in this case Extended Fields
  • Modify the Extended Fields controller so that choices can optionally be mapped to a field
  • Modify existing methods and templates for extended fields when being displayed in a form to use choices when the ftype (field type) is appropriate

Comments and changes to this ticket

  • James

    James October 23rd, 2008 @ 01:45 PM

    • State changed from “new” to “open”

    Walter,

    I'm finding the existing code (esp. _extended_field_mapping.rhtml) isn't the easiest to work with as it's pretty unstructured.

    Here's the path I'm heading down:

    • Refactoring _extended_field_mapping.rhtml into a bunch of helpers to simplying things greatly

    • Moving e/f XML generation/parsing to the model and to facilitate the addition of proper validations of e/f values, and simplify the topics_controller actions

    • Changing where in the params hash the extended content is sent (i.e. params[:topic][:extended_content][:first_name] which contains a string or Array depending on multiples, etc. This will simplify the handling of POSTed data

    Strictly speaking, the second and third points aren't essential, but they do remove a bunch of code that seems overly complex.

    Thoughts?

    Cheers, James

  • Walter McGinnis

    Walter McGinnis October 23rd, 2008 @ 02:56 PM

    "seems overly complex" is the key phrase. I'm sure refactoring is a good idea as extended_fields are from some of the oldest code in Kete, but extended_fields do have a decent amount of gotchas and requirements. So they may have a decent amount of inherent complexity.

    So what I recommend is a doing as simple as possible proof of concept of each of those three changes to see if they are worthwhile to sink more time into. I would probably experiment with moving the xml generation/parsing to the model first, since it will inform the others.

    There are some xml generating helpers that you will likely have to include in your models to make them work... i.e. they are originally view code that may need tweaking to make work in the model context.

    Rails now does have a way of including view helper methods in models, I believe. That is a relatively recent development, IIRC. This will be an interesting experiment with that, since that is the big thing stopping us from moving oai_record generation to the model... it relies heavily on things like url_for, etc.

    Anyway, please do an experiment with extended_fields rendering in model and report back after the first simplest experiment.

    Cheers, Walter

  • Walter McGinnis

    Walter McGinnis January 7th, 2009 @ 03:29 PM

    Looking at lib/extended_content.rb. Nice work overall. Found one very small change (but there maybe other places where it should be changed, too):

    line 209:

    value_pairs = extended_content_pairs.select { |k, v| k == field.label.downcase.gsub(/\s/, '') + "multiple" }

    There is a ExtendedField#label_for_params method that you should use instead of that downcase and gsub.

  • Walter McGinnis

    Walter McGinnis January 8th, 2009 @ 10:57 AM

    Hi James,

    I'm looking at lib/extended_content.rb and it looks good so far. One thing that might be generally useful and actually help to shorten up convert_extended_content_to_xml into smaller components is creating method missing setters for extended field (or perhaps more accurately, the extended field to content/topic type mapping).

    In other words, to add the extended fields value to the extended_content attribute you would call something like this (if field_name is a variable):

    self.send(field_name +'=', value)

    and then behind the scenes it would do the bits that convert_extended_content_to_xml does for each mapping.

    I'm thinking that the setter method would also take an optional argument that tells it whether to work with a passed in "xml" builder var or grab existing content and update it.

    Thoughts?

    I think this would be handy for the importer stuff and also updating extended fields with values with data derived from a binary files embedded metadata (what I'm working on now).

  • Walter McGinnis

    Walter McGinnis January 14th, 2009 @ 11:06 AM

    Just some clarification on the accessors and a little code review:

    • the importer stuff updates the params_hash, so probably all that needs to be done there is make things match how individual item params_hash are now processed (item.attributes(params) or something?)

    • dealing with all extended fields in a group for lib/extended_content.rb#convert_extended_content_to_xml is fine, it probably isn't worth updating that method to call the individual extended field setter methods, as they are likely have worse performance.

    Code review:

    • app/helpers/application_helper.rb#limit_search_to_choice_control and possibly other method definitions that are only going to be used in the search views should only live in the app/helpers/search_helper.rb, unless I'm missing a reason why they might be used in views.

    • am I missing something or is the choice dropdown ftype incompatible with "Allow user addition of choices" as far as interface? Either we need to add to the interface to make it work or we need to hide that option o the extended field edit form.

  • Walter McGinnis

    Walter McGinnis January 14th, 2009 @ 11:43 AM

    Pretty cool stuff as I play with it. However, we should probably have a chat about choices label vs value. I'm coming across some things that I have questions about or need a little bit of work.

  • Walter McGinnis

    Walter McGinnis January 20th, 2009 @ 10:17 AM

    I came across some weird behavior when using autocomple with choices where their value differed from their label.

    The autocomplete wanted to match label (seems logical), but put in as value the label, rather than the label.

    Perhaps it needs to match label OR value for autocomplete and we definitely need to make sure that value is what is submitted as choice.

    That being said, we may want to capture (hash?) both label and value for the internal storage in extended_content as we discussed. The XML would look something like this:

    <extended_field_label><1 label="choice_label">choice_value</1></extended_field_label>

    That way we may represent in the display of extended fields the value and/or label. It is particularly useful for links in extended field values, where create an anchor tag based on value as href and label for the choice as string being displayed.

    Make sense? Any reason this is a bad idea or issues with implementing it?

    Cheers, Walter

  • James

    James January 21st, 2009 @ 11:54 AM

    • Tag changed from enhancement, extended_fields, ui to enhancement, extended_fields, import, importer, ui

    The importer changes required were very minor (in fact it worked without modification). However I have changed the params hash to match what happens in the main application and added a small amount of error handling to catch situations where no field values are passed when fields are mapped.

    A testing article is coming shortly.

    James

  • James

    James January 21st, 2009 @ 11:56 AM

    The minor importer changes can be seen here: http://github.com/kete/kete/comm...

    James

  • Walter McGinnis

    Walter McGinnis March 9th, 2009 @ 02:48 PM

    • State changed from “open” to “resolved”

    This has been in master for awhile and debugged. There will probably be some refinement after 1.2 is released and we get feedback from the community, but the first version of it is done.

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป

Kete was developed by Horowhenua Library Trust and Katipo Communications Ltd. to build a digital library of Horowhenua material.

People watching this ticket

Pages