I'm not really sure whether to file this here, with Feeds or with Data, but when using the XPath Parser and Data Processor, the "xpathparser:x" labeling really obscures what data is actually being dealt with. There doesn't seem to be a way to give more meaningful labels, both in the UI and for the feeds_data_* table columns. See attached for what I mean...and database:

+----------+----+------------+--------------+--------------+--------------+
| feed_nid | id | timestamp  | xpathparser0 | xpathparser1 | xpathparser2 |
+----------+----+------------+--------------+--------------+--------------+
|        0 |  1 | 1290736042 |        37429 |       100916 |          884 |
|        0 |  2 | 1290736042 |        37429 |       100917 |          884 |
|        0 |  3 | 1290736042 |        37429 |       100918 |          884 |
+----------+----+------------+--------------+--------------+--------------+

Any ideas how this could be improved?

CommentFileSizeAuthor
Screen shot 2010-11-26 at 3.32.34 PM.png27.02 KBnicolash

Comments

twistor’s picture

twistor commented
Assigned: Unassigned » twistor

You got me. I never liked that naming convention since we added field inheritance. Ideally, I'd like to use xpathparser:[target_id], for example xpathparser:title. We can't do that since you can map to a target multiple times. We'll have to do something like xpathparser:0:title, xpathparser:1:guid.

Would that help?

nicolash’s picture

nicolash commented

That would definitely be an enormous improvement...I already forgot what those columns above contain :).

Closely related, it would be nice to have the target in the Data table be independently named...which is a Feeds feature request: #982242: Allow Feeds to use existing Data table

This whole Feeds ecosystem is seriously awesome, just saying.

infojunkie’s picture

infojunkie
Location Vancouver
commented
Category: support » feature

+1

Another option would be to allow a manually-entered label per query. This label would override the auto-generated scheme above.

bibo’s picture

bibo commented

It's funny and annoying, because the Data module + feeds integration creates it's target table fields based on the the source name, while the XPATH mapper tries to create it's source names based on the target.

These cryptic fieldnames could and should be avoided if we can manually alter/create the fields, which is possible via data_ui AFTER feeds has created the table. This is definitely not intuitive, but it offers a temporary solution until a better one arrives. info stolen from: http://drupal.org/node/982242#comment-3924892

nyl_auster’s picture

nyl_auster commented

suscribe
i would like very much to have better "keys" for xpathparser : Can't we take directly que name of the xml attributes ? why code is using this syntax ?
And Thanks for this great module :-)

twistor’s picture

twistor commented
Assigned: twistor » Unassigned
Issue summary: View changes
Status: Active » Closed (works as designed)

Yup. I never got around to this in this module.

However, feeds_ex fixes this. So closing this issue.