Hi,

analogous to the export (http://drupal.org/node/335892) bibtex import must also take care of the ct_id for the biblio type that it imports. I.e., every biblio type has a different ct_id value for authors of type 1 etc. The attached patch tries to figure out the ct_id according to the biblio_contributor_type table on bibtex import.

For editors, we first check if this biblio type has defined an editor type (10/14) among its contributor types.
Otherwise we store editors as authors of type 2 (should be "Secondary author" for most types) to somehow distinguish authors and editors.

CommentFileSizeAuthor
biblio_bibtex_author_import.patch2.44 KBFrank Steiner

Comments

rjerome’s picture

rjerome commented

Hi Frank,

Given the number of times we are running into this mapping of author types I'm thinking that a stand alone function, which statically caches the results might be appropriate. I'm also thinking from a programmers point of view, perhaps using the names rather integer ids in the code would make it more readable. This whole feature is completely new in 6.x so it's in a state of flux right now, I'm still looking for the best way to approach it.

Frank Steiner’s picture

Frank Steiner commented

I see! I there's anything I can do/test, let me know!

rjerome’s picture

rjerome commented

Hi Frank,

My message above was not intended to stifle your work, but rather solicit your input/comments (if any) on this issue.

Cheers,

Ron.

Frank Steiner’s picture

Frank Steiner commented

Ah, ok, I thought you were already working on something :-)

Yes, using one function for all places where mapping is needed would be a good idea, and using the names, too, of course.

I'm not sure how the data structure for a static caching would have to look like. I looked at all places where I used this so far (didn't check how you solved the bibtex export call, though) and I'm fetching slightly different information from biblio_contributor_type every time.

However, I wonder if caching would be worth the effort here: While I care a lot about normal page loading times in my installation, I never considered execution times for loading edit forms or imports/export that much, because I don't do that regularly. So I don't mind if importing or exporting some bibtexs takes 2 or 4 seconds or if the edit forms builds in 300 or 400ms.
But that's just my personal view.

I can't promise I can look into this soon, my boss wants our page to be launched so currently I'm trying to hack only the stuff that we need here (very selfish, I know ;-)) But I'll put that on my list.

Frank Steiner’s picture

Frank Steiner commented

With the current version (-dev from Dec 18th), I now see that I can solve this problem by knowing biblios code: On import, editors are given the author_type of the second author_catagory. So I solve this problem by always chosing "Editor" as "Secondary Author" in the biblio type edit form.

I'm fine with this personally, but one needs to look at the source code to understand this :-) Maybe some hint was needed in the type edit form to explain that editors must be placed as secondary author so that import and export works as expected?

rjerome’s picture

rjerome commented
Status: Needs review » Closed (fixed)