Closed (outdated)
Project:
Feeds
Version:
6.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
26 Jun 2010 at 02:14 UTC
Updated:
16 Jun 2016 at 22:40 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
infojunkieJust noticed the comment on
formatted_number_feeds_set_targetwas wrong. Re-uploaded.Comment #2
alex_b commentedWouldn't it be easier to just add formatted number into the array of allowed field types in content_feeds_node_processor_targets_alter() ?
I know, not 100 % clean in the spirit of 'on behalf' implementations, but it looks we're copying a lot of code here.
Comment #3
infojunkieWe can't add formatted number handling to mappers/content.inc , since the handling is slightly different. Specifically, we need to call
parse_formatted_numberwhen assigning the value, since this is the function that does the magic of converting a formatted number to a decimal.Maybe it would be good to provide an infrastructure that CCK field mappers can reuse, but that's beyond my scope for now.
Comment #4
alex_b commentedDidn't catch that. Will review.
Comment #5
alex_b commentedThis looks good. Needs minimal test. See tests/feeds_mapper_content.test. You should be able to use content.csv for testing.
Comment #6
infojunkieAttached is a new version of the patch containing simple tests as well as support for all Formatted Number types, not just decimal.
Comment #7
alex_b commentedReviewed. All tests passing, this is looking good. Will commit shortly.
Comment #8
alex_b commentedThis is committed.
Comment #9
alex_b commentedFYI #857928: Breaks installation profiles
Comment #10
alex_b commented#857928-3: Breaks installation profiles - I'd love if you could way in on this. If the module maintainer does not accept a patch to the broken hook_requirements() implementation in FNCCK, I would rather have this functionality live in FNCCK.
Comment #11
infojunkieI guess we have the option of:
* Remove this from Feeds and re-submit it to FNCCK
* Remove FNCCK tests
In general, I think it is a big responsibility that Feeds undertakes of including mappers for all 3rd party fields. Another approach might be to open another module, Feeds Mappers, that just provides these mappers. Tests in this module need not be as rigorous as in Feeds core.
However, this should wait until the mapper infrastructure is stabilized, e.g. in reference to the issue of converting them to proper plugins #860748: Config for mappers?.
Comment #12
alex_b commented- Remove from Feeds and resubmit to FNCCK
is my preferred way of action.
I would not want to maintain that module then :) Srsly: the fact that Feeds integrates with so many modules is the main reason why tests are so incredibly important. The mappers are some of the most test worthy integration points.
Comment #13
alex_b commentedI just removed what I've committed - we are back to #7, sorry :-(
Re: preferred way of action - this is all up to you now. My only restraining factor is that I can't commit the FNCCK mapper to Feeds if it breaks the test profile...
Comment #14
summit commentedSubscribing, greetings, Martijn
Comment #15
joetsuihk commentedI have moved the code into a module, just like location_feeds module is doing. Feel free to use and test and do anything you want.
As there is not huge interest, i think i will not create a separate d.o project for this tiny module.
Please let me know if there are bugs, thx.
Comment #17
twistor commented