Hi Ron,

this patch allows you to choose some terms from the taxonomy(ies) that are available for the biblio node when you import a file. There is no free-tagging (but it shouldn't be difficult to do).

It also correct a small bug. The _bibtex_import() function was returning a string of content whereas the calling function was waiting for an array of node ids. It was inconsistent with the others _X_import() functions. It now returns the expected array and print the string that was returned in a drupal message.

The _XML_import and _bibtex_import are a little bit inconsistent in the way they handle message printing. I think that the way it is done in _bibtex_import is better (but didn't want to change the XML function because I have no XML file to test it).

IMO it would be better to externalize this part in a small helper function, but I didn't do it. This is up to you to do it or not but if you think that it is a good idea and have no time to do it I can do it.

I mean this part could maybe be in an helper.


foreach ($node_array as $node) {
        $node_obj = (object)$node;
        $nodeid = node_save($node_obj);
        if ($node_obj->nid) {
      $node_ids[] = $node_obj->nid;
      drupal_set_message(t('Succesfully imported node ' . l("$node_obj->nid", "node/$node_obj->nid")));
        }
      }

Being in an helper function would facilitate the consistency between the import functions in case of future modifications.

damien

CommentFileSizeAuthor
biblio.module_1.patch3.38 KBcirotix

Comments

rjerome’s picture

rjerome commented

Hi Damien,

We seem to be on the same wavelength these days... I spent the weekend working on the free tagging part :-) Basically I made the keywords free tags, so I was just pondering whether to let the user select a vocabulary to insert the tags into or just create a default biblio vocabulary. I'll most probably do both, any thought on the matter?

I realize there were some inconsistencies with the import and export files, unfortunately these are usually the last to get my attention. What you did is the way I was moving. I wanted to get an array of node_id's back from the import filters. The reason I changed this was that I am also building a unit test module for the biblio module (see project/simpletest for more). Getting an array of nid's back from the import filter made it easier to clean up after the tests, I could then just go and delete any new node that were created by the tests. The first tests I wrote were for the XML filters so thats why the change showed up there first.

It's funny you should mention externalizing that bit of code, since I almost did just that the other day.

Since you seem to be most interested int he bibtex stuff... what you could do if you want is move the _bibtex_export() function to an include file like the xml ones. Also you could move the bib2node from the bibtex.php to it's own file as well and as you mentioned before, this would make updating the structures_bibtex file much easier.

I was thinking about moving all the import/export functionality to a separate helper module, mainly to cut down on the size of the main module, and perhaps be slightly more efficient. Any thoughts?

Ron.

cirotix’s picture

cirotix commented

Basically I made the keywords free tags, so I was just pondering whether to let the user select a vocabulary to insert the tags into or just create a default biblio vocabulary. I'll most probably do both, any thought on the matter?

This is an excellent move. IMO the keywords should be included in a default keywords vocabulary. The fact is that you need to know which vocabulary is used for the keyword in order to be able to export them. Or maybe the best solution would be to provide a default keywords vocabulary (called "Keywords" for exemple) but let the user the possibility to override the default choice in the settings of biblio. The user will be able to choose the name she wants for the keywords and you will know what vocabulary export.

Maybe we could also think of multiple vocabularies: one for the keywords, which will reproduce the behavior you already have with your hard-coded keywords. Then the user can also define other vocabularies. For exemple I have one called Bibliography with terms such as: Sound state of the art and key issues, Music state of the art and key issues, Interaction state of the art and key issues,... I use them to classify my full bibliograhy in cluster [0] . For now I can use the taxonomy module to display the publications by "Bibliography". Of course they are displayed as node and not nicely has in the example.com/biblio view. In the future I guess that it could be possible to do some fancy stuffs with user-defined bibliography. Of course, the planned integration with the Views module will be a milestone toward this.

I am also building a unit test module for the biblio module

Very good.

since I almost did just that the other day.

Is it commited? As I think that tight integration with Views, Taxonomy (and maybe relationship, it could be very cool) require deep changes, maybe we could have an experimental branch on the CVS to do experiments. I don't know if it feats Drupal policy for CVS branching. I am ready to help as you may have understood. In am new to Drupal, but I find it pretty neat and cool to program (actually I have also a very basic level of PHP, tough not new to programming) so, as I also need this module to do fancy stuffs for work, I think that it is an excellent occasion to contribute.

Since you seem to be most interested int he bibtex stuff... what you could do if you want is move the _bibtex_export() function to an include file like the xml ones. Also you could move the bib2node from the bibtex.php to it's own file as well and as you mentioned before, this would make updating the structures_bibtex file much easier.

Yes my main interest is bibtex. If you don't mind I will check bibliophile to see if it is better than bibtex.php (I have found an other bug in bibtex.php) and will do as you have you mentioned.

I was thinking about moving all the import/export functionality to a separate helper module, mainly to cut down on the size of the main module, and perhaps be slightly more efficient. Any thoughts?

Yes is probably a good idea. The main module is already pretty long and the export/import part is quite independent of the rest of the module. BTW the export could also be a view. Instead of returning a file it could return the content of the export within Drupal. Maybe it could be done in addition to the regular export and will be quite easy to do once Views will be integrated.

cheers,
damien

[0] For the little story we are writing a roadmap for Sound and Music Computing, and I need to attach publications to different book pages, corresponding to the different parts of the roadmap. The original form of the roadmap is LaTeX and your module is one of the component that I need to provide an automatic (or semi-automatic at least) export from LaTeX to Drupal. I will document how I am doing that when it will be finished.

rjerome’s picture

rjerome commented

For now I can use the taxonomy module to display the publications by "Bibliography". Of course they are displayed as node and not nicely has in the example.com/biblio view. In the future I guess that it could be possible to do some fancy stuffs with user-defined bibliography

Yes, I knew the first time I saw a "taxonomy" list of biblio entries this would be the next problem. Not insurmountable though, I think with some sql "Joins" to the term_node table something like biblio/term/2 could produce a list of all of the biblio entries related to term 2. Fortunately, I have recently been refactoring the SQL building code in biblio_db_search() to make it easier to add arbitrary joins to other tables. This was due to another idea that I've been working on which is related to author indexing. Basically I'm building a table of unique author names and node to author relation table (much like term_data and term_node), then using this table to sort and filter on author names.

Is it commited? As I think that tight integration with Views, Taxonomy (and maybe relationship, it could be very cool) require deep changes

I have to admit that I haven't really look at or used the views module to much, but certainly everyone seems to rave about it. Does it only produce tabular data or can you create any sort of layout? Perhaps you would like to lead the charge with views integration? You may have noticed a few empty views related functions a the bottom of the module, this is as far as I have progressed so far. I don't know if we need a new branch, I have been doing most of my development/experiments in HEAD and then merging what works over to the other branches.

Yes my main interest is bibtex. If you don't mind I will check bibliophile to see if it is better than bibtex.php (I have found an other bug in bibtex.php) and will do as you have you mentioned.

The good news here is that it's almost a drop in replacement. I tried it when I put that new version of Structures_Bibtex in, it was no problem at all.

Instead of returning a file it could return the content of the export within Drupal.

Interesting, but I don't really see the advantage of this, can you explain/describe more?

That's all for now...

Ron.

rjerome’s picture

rjerome commented

The patch in now in the -dev branches.

Ron.

bekasu’s picture

bekasu commented
Status: Reviewed & tested by the community » Closed (fixed)

Upgrading to the Biblio 6.x version addresses this issue.
bekasu