Closed (fixed)
Project:
Feed Element Mapper
Version:
6.x-2.x-dev
Component:
Code
Priority:
Critical
Category:
Feature request
Assigned:
Issue tags:
Reporter:
Created:
14 Apr 2009 at 14:44 UTC
Updated:
7 Jan 2010 at 07:11 UTC
Jump to comment: Most recent file
Comments
Comment #1
alex_b commentedhttp://skitch.com/alexbarth/bmsut/development-seed-technological-solutio...
Comment #2
aron novakwill be done tomorrow
Comment #3
aron novakComment #4
alex_b commentedLet's use a hook_feedapi_mapper_default() for declaring default mappings:
You see that only one module will be able to declare a mapping for one node or one node type. This could create funny behavior but I think this is good for the moment.
Comment #5
aron novakNow the exported stuff should be put into that hook.
Comment #6
Ian Ward commentedI tested this, works great. One suggestion I have is to show/indicate when a map is overridden, and allow the user to "revert" back to the default setting. It would also be great to click to see a diff of the default map versus the overridden version, like the features module. What do you think about that?
Comment #7
alex_b commentedIndicate whether overridden is essential. Diff nice to have. I'd say let's get the patch in with the 'overridden' indicator and create a diff feature request on a separate follow up issue.
Comment #8
alex_b commentedI've thought more about this and I realize that if we have exportables we need to be able to have a UI to manage mapping sets. Say we ship a module like FeedAPI Node or FeedAPI Data with a default mapping. Now a user overrides this mapping for their specific needs. The user wants to be still able to export this mapping to code.
But with this patch he couldn't because there is already a default mapping defined in code by a contrib module.
The solution is an explicit managing of mapping sets. Imagine you can save a mapping, create a new one and then pick which mapping to use for a specific node or a specific content type by setting it to active just like you pick a theme or the default filter for your site.
Comment #9
alex_b commentedWe should use Ctools as it has features integration for free #532256: CTools/export integration - Including Panels export
Comment #10
alex_b commentedComment #11
alex_b commentedThis is critical for beta 1.
Comment #12
aron novakKnown problems / things to do:
- no revert link for the content-type mappings
- When you visit a node and exports the mapping and the node uses the content-type's mapping, this will result in an empty object.
Unfortunately it's not possible to simply do
ctools_export_object('feedapi_mapper', array_pop(ctools_export_load_object(....))here because of the complexity of per-node and per-content-type settings.Comment #13
alex_b commentedShould we not have a nid(unsigned) and a type(varchar) column instead of a single param column?
Comment #14
alex_b commented"Unfortunately it's not possible to simply do ctools_export_object('feedapi_mapper', array_pop(ctools_export_load_object(....))"
- I think we can't solve this because of the issue that node id's can't be unique. Node mappings should not be exportable.
Comment #15
aron novak#13: any benefit of having two columns?
Comment #16
alex_b commented#16: no mixing of field types, clear name for the purpose of the field ('type', 'nid')
Comment #17
aron novak#16: which one should be the primary field? Would you store NULL in the other one _always_? It's anything, but not elegant.
Other way is to create two tables.
Comment #18
alex_b commented#17: $param it is then : )
Comment #19
alex_b commented- Cleaned up some language
- Added doc to README for explaining how to export
- Simplified 'status' (revert) readings.
- removed the ability to export per node mappings.
I think this is very close. After the remaining issues from #12 are addressed, we should commit this.
However, the normal/default/override UI in this patch make it very clear that we need to follow up with #542260: Allow definition of multiple mappings, pick 'active' mapping once this patch is committed.
Comment #20
aron novak#19: thanks for updating the patch!
What i did in that patch below in addition:
- when you export a per-node mapping, the warning appeared in the textarea, without any highlighting. I replaced it to drupal_set_message('foo', 'warning'), i assume this is the good way to show such messages to the user
- there was a broken /map/override link on the content-type mapping page, fixed, this should not appear there. Also i fixed the text there.
- revert functionality is fixed. you can only revert per-content-type mapping (but you can do that also when you are on a node/nid page and watching a per-content-type mapping, tricky :) )
- there was an issue when an exported mapping is on the UI and someone added a new mapping, the exported one wasn't merged into the new one and it started with an empty mapping. fixed
- put link to the README.txt at export to make it easier to access to the README, just as simpletest does it
- fixed typo in the README, missing )
Comment #21
aron novakHm, and after these, i think this needs review.
Comment #22
alex_b commented- Fixed call to drupal_write_record() in add function
- Fixed 'revert' string (minor)
- Fixed URL construction by adding a str_replace - str_replace('_', '-', $feed_node->type)
There is a remaining problem of confusion between 'override content type settings' and 'override default settings'. We should address this with #542260: Allow definition of multiple mappings, pick 'active' mapping though.
RTBC from my point of view, commit at your discretion, please.
Nice work.
Comment #23
aron novakI did a little fix, removed an unneccessary variable assignment in add function.
Attached the final patch.
Comment #24
aron novakCommitted.
I wonder how many people will complain about the added hard dependency ;)
Comment #25
aron novakA serious bug was fixed after #23 was committed.
Replaced
To:
Obvious, when i cast to array, is_array will be surely TRUE. Damn. Fixed. Also added 'ctools' to all the test setUp functions.
Comment #26
aron novakComment #27
rickvug commentedtagging for reference.