Please use fields ("CCK" in D6 and prior) for data in the D7 version of this module.

Several issues are requesting this, and there's a wiki page at groups.drupal.org to coordinate this.

Fields in D7 has several benefits. Two examples:

  1. This module's users will get the same rich functionality as other fields.
  2. Module maintainers may drop code that duplicates what's already in fields.
CommentFileSizeAuthor
#61 photo.JPG415.99 KBsmithdalec
#2 biblio.tar_.gz14.58 KBAren Cambre
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Aren Cambre’s picture

Status: Needs work » Active

I've (admittedly liberally) marked these as duplicate:
#397332: Conversion to CCK data model
#86086: Integrating biblio into user profiles
#220005: Integrate Biblio types as CCK Types
#583604: Author field as CCK field in Views2
#272901: Add one more Contributor Type - Artist
#359260: filter by uid uses node-creator-uid instead of contributor-uid
#261177: How to attach pdf to biblio nodes? Do I need webfm or similar module?
#525050: Importing from nodes
#129607: Adding CCK fields like User reference to Bibliography fields.
#151687: Import a cck field?
#205922: CCK to Biblio node import?
#207262: Patch to export bibliographic data as CSV file
#436130: update on last posted version
#572260: Distributed Search or web services interface?
#455746: Subtitle
#151165: Can be added images of books with bibliography module?
#384932: code as plain text in views
#342780: Options/limitations for using biblio fields (URL, PDF att) in another node type
#334135: Date granularity (yyyy, mm, dd)
#350309: Picture
#366059: Text field with checkbox for copyright statement
#314249: URLimage - display a small image next to bib entry
#264540: Adding a filter item
#261738: Authors filed is not showing
#132024: attach files during import
#473612: Organize journal in D6
#201149: Bibilography of individual authors
#526740: Make file display configurable
#412700: Attached images exposed in Views?
#210957: Author as node reference
#358154: Secondary sort by year
#484872: export links in views
#672916: Publication Type Comment

Not quite duplicate but significantly advanced by fulfilling this issue:
#659006: recent publications block sort by date
#408500: Filter/search without cookies
#665136: Publications Link On Profile Page Link
#672620: Alphabetical sort of Pub. type select list for node/add?

In some cases the other issue is not a literal duplicate but would be fully resolved with fields integration. In many cases, rjerome is being asked to implement functionality that is already present directly in fields (CCK) or available in well-supported modules already used with fields (CCK).

Aren Cambre’s picture

Status: Active » Needs work
FileSize
14.58 KB

Found these at groups.drupal.org: Porting Biblio to CCK and Porting Biblio to CCK (yes, they are different nodes with same titles). These reference Coornail's 2009 Google Summer of Code project, which is at #56 of #234891: Views integration. rjerome described it as "somewhat incomplete CCK integration effort."

I've attached his code here and marked this issue as "needs work."

rjerome’s picture

Thanks for that Aren,

I am aware of all the CCK requests and issues. My intent for D7 is to roll out a D6 compatible version as 7.x-1.x, meaning there will be no major changes to the DB structure in the initial release. It has been my experience that mixing major Drupal updates and major structural changes to the module is a a bad thing. As it is, there are hundreds of changes to the code just to get it to run with the new Database API, changes to the Forms API etc.

There will be a 7.x-2.x branch which will incorporate the biblio data structures into "Fields", and I would certainly welcome your input and contributions on this front.

As for the SOC code, I was trying to be as diplomatic, politically correct and generous as I could with the comment ""somewhat incomplete CCK integration effort".

In my view, the biggest challenge to the entire Biblio in Fields effort will be the author handling. This is something the SOC code completely ignores and I'm not willing to compromise on, given the amount of effort that went into creating the relational schema that the authors are now stored in.

I know there are numerous benefits to going to Fields, but lets not overlook the potential pitfalls either... I suspect there is going to be a serious performance hit for large databases, the code is getting exponentially more complicated and thus it's taking longer and longer between release cycles. D7 is a perfect example, I'd be willing to be that it will be another 6 - 8 months before it hits the streets, and it's turning into this very strange mix of procedural and OO code.

Anyway that's my $0.02 worth.

Ron.

Aren Cambre’s picture

I interpret the fields (CCK) integration path as to shove this module's logic into one very complex CCK field. That is a cosmetic transition that maintains biblio data's second class status.

This module's fields integration needs to promote all biblio data to first class fields data. This gives biblio data full access to rich functionality available to fields, and it could drastically simplify the module as all "reinventing the wheel" code could be dropped.

Biblio should only provide two things:

  1. Custom fields that implement logic not already in core fields or well-maintained modules.
  2. A management interface that gives a wizard, or equivalent functionality, to create bibliography content types or add biblio fields to an existing content type. The management interface could be a simple as only creating a single content type that has all the fields of the current (D6) module. Future enhancements could include "recipes" for common biblio content types that don't need all fields. After creation, the user just uses built-in fields functionality to further manage the content type.

In doing this, the biblio module's data becomes first class content. That means users will get the rich functionality available to all other first-class content.

I grant that some custom rendering logic may be necessary to ensure proper compact display of bibliography entries. Not sure yet how this would be implemented, but possibly as a custom Views row style?

As for author handling, can you tell me more about this? How is biblio unique? What would be a challenge for transition to fields?

Aren Cambre’s picture

After finding all those duplicate issues, I sure hope that the 1.x D7 upgrade effort will be limited to adapting existing code to D7. In so many cases, the new functionality being requested of you is actually in other modules; you are being asked to duplicate other well-established logic within the biblio stovepipe.

Perhaps the 2.x D7 upgrade project should begin immediately, with the primary goal to have full fields integration? If it proceeds well enough, the 1.x line might only be a reference for 2.x and may never be released?

rjerome’s picture

My plan is to have a fully functional 7.x-1.x module ready prior to embarking on the conversion to Fields path. That being said, I am almost at that point now. I haven't touched the D7 code in a few weeks, but if I recall correctly it's mostly working, and a drop in replacement for the current 6.x code line. Given the rate at which the core D7 code is progressing, it is entirely possible that a Fields 7.x-2.x branch might be ready when D7 is released, but I'm not willing to make any guarantees on that.

As I stated earlier, I would be delighted to receive code submissions which would help the D7 Biblio code meet that target.

Ron.

Aren Cambre’s picture

Excellent! 7.x-2.x probably needs discussion and a clear plan before works starts. I believe the vision I outlined in #4 conflicts with the prior attempt's architecture, so it would be good to clarify plans and define a strategy.

rjerome’s picture

Without doubt, much planning and study of the API (at least on my part) is needed. I really wasn't involved in the prior attempt at CCK, it was just presented to me.

I still feel however that one needs to be cognizant of the performance implications and not just assume the CCK/Fields is going to be the answer to all your prayers. One need not dig too deep to find all kinds of performance related issues and Fields in Core related issues. This one is a particularly interesting read.

Ron.

Aren Cambre’s picture

I understand your concerns. However, the 1st link is generic performance-tagged D7 issues that could affect any module, the second link are just generic issues that one would expect in any prerelease product, and the third link (to #615822: Benchmarking / profiling of D7) is again another issue that's just the nature of pre-optimization, prerelease code.

#615822: Benchmarking / profiling of D7 was closed as duplicate of #513984: Find bottlenecks in HEAD - meta issue, which is a generic performance improvement issue for the base system, again something standard for prerelease software.

It's safe to assume that fields (CCK) will provide acceptable performance once D7 is released. If it doesn't, then the entire Drupal project is a failure. I don't expect that.

EDIT: As of 7/14/10, there is only one D7 performance issue related to fields (link).

rjerome’s picture

I respect your optimism, and I'm certainly willing to explore this avenue, but I have seen bigger projects fall flat on their faces trying to catch the proverbial "killer feature" so I wouldn't rule anything out.

Aren Cambre’s picture

But reckless abandon is so fun!

hchall’s picture

tracking.... and thanks for all of your efforts, Ron!

Aren Cambre’s picture

Status: Active » Needs work

Configuration Management, Automation & Features could define a path towards CCK support.

bekasu’s picture

Aren,
It appears you have figured out a solution for the CCK/biblio many-to-many relationships. When you finish the coding, I'd be interested in seeing the final result.

Aren Cambre’s picture

@bekasu: Many-to-many is easy with the CCK nodereference field. For example, if a biblio node had a nodereference to an author, then you effectively have a many-to-many relationship.

bekasu’s picture

@aren
I understand the concept. Just looking forward to seeing your code. It will help many folks.

Aren Cambre’s picture

That's the problem: there's no code. It's already implemented in other modules. That's a point I've been trying to make about Biblio--it's forcing you two to do what other modules do already. Why reinvent the wheel?

rjerome’s picture

It's already implemented in other modules

Would you care to share the names of those modules with us?

That's a point I've been trying to make about Biblio--it's forcing you two to do what other modules do already. Why reinvent the wheel?

It's not forcing you to do anything, if you don't like it then don't use it, end of story! There are however more than 1500 sites that seem to think it's doing something useful.

Aren Cambre’s picture

@rjerome--CCK's native nodereference field does this. The module would be CCK with D6. Nodeference and userreference didn't make it into core with D7, so they will continue to be a contrib module.

As for "forcing"--sorry, I mean it's forcing the maintainers to do additional work, not users.

Gerben Zaagsma’s picture

subscribing

iko’s picture

Hi,

I'm unable to provide any code, but very, very eager to see Biblio integrated with Fields ; yes, the nodereference module would be indispensable - "author" would be a content type by itself with all fields needed, including an optionnal userreference field for handling the problem of "authors-who-are-users-and-have-a-profile-and-authors-who-are-not-and-have-no-profile". Note that the userreference module includes a "reverse link" functionnality which links user's profile to any node referencing him ; several modules provide this kind of functionnality for node reference, among them : Node Relationships, BackReference, Corresponding Node References, or Node Referrer : an "author node" would automatically displays his bibliography. (Also mention the "backlinks" view generated by the Search module)

If you set very few fields in "author" content type (nodetitle would be the name, a userref, a multi-valued noderef to biblios), anyone could add more if necessary (a "nom de plume", a date of birth/death ..) or set an automaticnodetitle-generated title.

The fact is, I have absolutely no idea of how to integrate the import functionnalities with the nodereference's functions. That would certainly be a big problem. There are several "import nodes" modules : I don't know how (and if) they integrate nodereference.

Biblio module is awesome ; but when you say "There are however more than 1500 sites that seem to think it's doing something useful.", you're right, but you just don't know how many sites have built a "local bibliography feature" using CCK and Views because Biblio module didn't suit their needs, and couldn't be easily tailored...

Of course I'm aware of the work and I'm sorry for being unable to help you. Hope you will find good ideas with the modules I mentionned.

Marie-Hélène

ps. oh, and I forgot : it is also possible to create an author node "on the fly", I mean from the biblio edit form : have a look at NodeRefCreate, Popups:Add'nReference or Node Widget...

rjerome’s picture

Thank you for you comments Marie-Hélène,

Believe me when I say that I understand the "Whys" of moving to CCK, but I hope you and others also understand that the "Hows" are often a bigger problem.

I have lots of plans for Biblio, but only so many hours to make them happen :-(

BTW, when you say "couldn't be easily tailored... " could you give me any examples of what you mean by this. This would give me a better understanding of the (often diverse) requirements of the users. Often ,what seems like an obvious requirement to you, may have never even crossed my mind :-)

Ron.

iko’s picture

Hmm, as a matter of fact, for the "tailoring problem" I only have one case in mind, I built a bibliographic system because Biblio module was much too big for my needs : I developped a social network for my family, and they asked me "hey, Marie-Hélène, we would like to share our favorite books". I didn't need the complete Biblio module and it was quicker to create two content types (author and book) with a very few number of fields : author has only a title and a nodereference to books (which is populated by Corresponding NodeReference), book has only a (noderef) author, a title, an optionnal "publisher's stuff" (optionnal because in general you like a book, not a particular publication of the book), and the body is the "summary and personnal review". The nodetitle is populated by Automatic Nodetitle with the author's name and book's title. I mapped Author as a content type so that I would be able to create other content types referencing to it (yes, I'm ready for the "hey, Marie-Hélène, we would like to share our favorite movies" :-)). My main concern was to make the whole stuff sustainable (datamapping-wise) but easy for my users (they don't care to fill in plenty of fields).

The most complicated was to create a "quotation feature" : I wanted to make it possible to quote a sentence from the book, and the quotations would appear randomly in a block on home page. I tested the Quote module of NancyDru, which is good, but I wanted only one authors' list (for books and quotations), and I wanted the source to be - OR MAY NOT BE - a registered book (to be clear : you can create a quotation from your favorite book OR regardless of any book, for exemple a wisdom's maxim). The "source" field of the quotation type is therefore a fieldgroup of two fields : a nodereference to books and a textfield for any other case (I didn't map the other cases). The nodereference uses a NodeReference URL widget : so every registered book displays a "Add a Quotation from this book" link and the user doesn't need to mention any source (he may add the page number in the text field). But it's also possible to click "Create content > Quotation" : the nodereference remains empty and you can fill in the source textfield (or leave it).

Well... I hope my explanations are clear enough (even in french it is pretty complicated to express :-)). It's not completely perfect : the data-mapping is not exactly optimum, the source textfield is potentially a big bag of any type of information, authors are not categorized... but I couldn't do something more complicated for my users. I can't give you a link, the site is private and you wouldn't see anything. Just believe me : it works !

... But this situation may be very special ! I don't use Biblio module in a scholar context, although I plan a site (a kind of books' reviews platform, a personnal plan) where it would be useful. However, I hesitate to adopt it because, in fact the main problem (in my opinion) of the "CCK-non-integration" is the sustainability of Biblio's data mapping inside Drupal's data mapping. If I build my planned site with Biblio (I mean the CCK-non-integrated one), and if, for any reason, I want or must to give up Biblio, I guess it will be painful to get my datas in Drupal's datamapping. It seems to me better for a module to "follow" the general mapping ; but a Drupal-experienced coder may have a different opinion. I'm neither much Drupal-experienced (one year) nor a coder.

So I won't help you but I'm looking forward the next generation of Biblio module. Until now, I never found time to start my own CCK-integrated biblio feature (for my planned site) and would be glad to find it done. Thanks for all your work, I understand your time's problem quite well (days have only 24 hours in the East side of the Atlantic Ocean as well)... Cheers !

xkater’s picture

iko: i just noticed this (accidentally) - ! this is a wonderful explanation ! and should become a "Case Study"!

rjerome’s picture

Yes, I agree. I hope you didn't interpret my lack of reply for lack of respect, I've just been swamped lately.

Ron.

iko’s picture

no problem ! thanks !

roderik’s picture

I know absolutely nothing about this, so ignore me.... I just happened to spot http://drupal.org/project/field_convert

Maybe useful for whoever wants to assist/test in the 7.x-1.x to 7.x-2.x path?

Aren Cambre’s picture

@roderik: My reading of that module is it would be useful only when someone upgrades from non-fields (CCK) to fields-aware version of some module.

roderik’s picture

The upgrade path from 7.x-1.x to 7.x-2.x is going to be 'converting from non-fields to fields-aware version of the biblio module', right?
Otherwise I totally misunderstood.

My reading of the first line on the field_convert module page (as well as a.o. http://drupal.org/node/366364#comment-2691168) is:

A framework for non-CCK modules to use to convert their Drupal 6 custom data to Drupal 7 FieldAPI fields.

---

Still - it's just a framework, I don't know its details, and I don't know what would work better: figuring out Joachim's code or writing stuff yourself.

Aren Cambre’s picture

I see your point. Yes, this could be relevant once the fields-aware version is far enough along to test the upgrade process.

steinmb’s picture

Yay! Drupal 7 RC1 is out.
I have been reading the interesting thread but I feel most have been sad. We have implemented a lot of what what the biblio module do with views, cck, noderef, ... simply because we needed the data stored in fields. We are soon moving to D7 to level some RDFa awesomeness and I think that is another compelling reason to get biblio moved toward fields.

I have not yet started working on imports but I think http://drupal.org/project/feeds is a wonderful project to build the needed parsers on. Views should be able to provide us with most of the needed output by help from projects like http://drupal.org/project/views_datasource

rjerome’s picture

Trust me when I say that I have been working on this (albeit mostly in my mind). 7.x-1.x is just going through some final testing and then it can be considered a drop in replacement for the 6.x version. When this is done, the 7.x-2.x brach will be born and "Biblio in Fields" will begin in earnest.

I just took a look a feeds again, and it would seem that it has come a long way since that last time I looked, and your right, it does look like a good fit for the import filters.

I've been revisiting the Views code in Biblio lately with an eye towards moving completely in that direction, so I think we are on the same page.

And thanks for that pointer to views_datasource, that looks like it might provide the framework examples required for the export side of things. So it's all good!

All I need now is time :-(

Ron.

kehan’s picture

subscribing

shenzhuxi’s picture

Hope 7.x-2.x release soon. Maybe I will contribute codes for better pubmed import.

rjerome’s picture

Contributions are always welcome.

shenzhuxi’s picture

@rjerome
I add the idea to 2011 SoC.
http://groups.drupal.org/node/134664

Can I access the latest codes from git now?

vunger’s picture

Hi,

Is it safe to assume that CCK fields will only be supported in 7.x versions and not in 6.x?

rjerome’s picture

That's probably a safe comment, but it sort of depends if the 7.x implementation lends itself to back porting. I'm trying to keep the 6.x-2.x and 7.x branches as similar as possible to facilitate feature movement between branches.

Ron.

azin’s picture

Any ETA on 7.x-2.x release as yet?

rjerome’s picture

No, but I was starting to look the specifics of converting to "Fields" last weekend, so it is in the works. You will see a 7.x-2.x-dev version when there is something concrete to work with.

Ron.

dominikb1888’s picture

If there's anything we can help you with, let us know we're waiting for this feature to port biblio_mendeley and can surely assist. Is there any more complex problem involved other than creating a field api field for each biblio field?

rjerome’s picture

From where I sit, there are a few issues somewhat more complex than just creating fields. One is creating/maintaining a relationship between "author" fields (which will contain all the columns in the biblio_contributor_data table and the "biblio" fields which will contain the columns in the biblio table.

There is also the issue of "Publication types" and whether each type should be a separate content type or the type should just be a column of the biblio field.

Maybe these are non-issues, but until I actually write some code it's hard to tell.

Just so you know, I am starting to work on this so hopefully will have answers to these questions soon(ish).

Ron.

dominikb1888’s picture

Good to know! Thx for the quick response.

Does anything speak against creating authors as individual nodes and linking these through node relationships? Each author node could contain a user relationship to link authors and users. If relying on another contrib module isn't to much, Relation API could probably be useful http://drupal.org/project/relation

Have you considered taking on biblio node and conditional fields on the user interface? http://drupal.org/project/conditional_fields This would leave you with one node type and some standard configurations for certain biblio types.

scor’s picture

There is also the issue of "Publication types" and whether each type should be a separate content type or the type should just be a column of the biblio field.

IMO biblio should remain its content type, or become its own entity type with a bundle for each publication type. http://drupal.org/project/entity would provide good foundations to build this. Several modules have gone this directions, like profile2, commerce and many more.

If relying on another contrib module isn't to much, Relation API could probably be useful http://drupal.org/project/relation

I bet http://drupal.org/project/entityreference might be enough. relation is tackling a bigger problem, and I'm not sure it is mature enough for another module to rely one just yet.

Does anything speak against creating authors as individual nodes and linking these through node relationships?

nodes would have a terrible overhead compared to the current biblio authors. Not sure site admins would like to see all these nodes appearing on their site either. A specialized lightweight entity type for author sounds more appropriate here.

dominikb1888’s picture

Ok, true. Custom Entity types is the better option... still thinking d6 too much.

rjerome’s picture

Thanks guys, all good input and food for thought!

Ron

dominikb1888’s picture

One thing that may speak against entityreference or would need to be implemented separately: reverse referencing, i.e. relationship, from user profile. So users can choose an author name on their profiles and an admin can choose a certain user on the author entity. The http://drupal.org/project/er module seems to be providing this, but is still in a very nascent stage.

dominikb1888’s picture

If entities and fields are available we should probably have a separate discussion on ontology mappings to provide as standard. The first ones coming to my mind are SWRC http://ontoware.org/swrc/ and BIBO http://bibliontology.com/

@scor: Any other ontology that should be taken into account? What is the Science Collaboration Framework using?

scor’s picture

In SCF we use CITO and SWAN Citations, though there are efforts to align them. There is also some work going on for the ScholarlyArticle on schema.org, though it won't cover 100% of the biblio use cases. This won't be a problem though since RDFa allows to easily extend schema.org with other vocabularies like BIBO.

ar-jan’s picture

Although I have nothing much to weigh in on code/architecture, this

IMO biblio should remain its content type, or become its own entity type with a bundle for each publication type.

sounds good. The idea of separate content types for publication types reminds me of the term "content type madness" ;)

azin’s picture

+1 for "IMO biblio should remain its content type,"

smithdalec’s picture

I am starting the conversion to Drupal's Field system on the 7.x-2.x branch.
So far this is what's planned:

  • Biblio content type will become its own entity
  • Publication types will become separate bundles of the Biblio entity
  • Contributors will have its own entity
  • Keywords will become taxonomy terms
  • Other biblio_* fields will become standard Drupal Fields

Any other thoughts?

Mark F’s picture

Great news.

dominikb1888’s picture

@smithdalec, ref #52: The plan sounds very good! Any news on the implementation front? We'd definitely be in, helping to port this to entities. Any dev version outside of the drupal repo? Seen the tag is already there...

smithdalec’s picture

Update on the 7.x-2.x branch:
I've implemented the biblio entity type (with it's own custom controller class), and gotten fields/field instances set up, with user input and BibTex imports adding data to fields. There's a mass amount of code that still needs to be converted from using node entities to the new structure of biblio entities, which is what I've been working on for the last couple of weeks.
I am about to take a small detour to start working on getting the contributors entity type in place. I'll be using the Entity API module (with which I am currently familiarizing myself) to implement the contributors entity. If that works out well, I'll change the main biblio entity to use the features of Entity API, so that I don't need the current custom controller class/helper functions.
Once the contributors entity/fields are set up and working, I'll continue to migrate code from using the node structure, to the new biblio/contributor entities structure.
After most of the code is re-written using the new entities, I'll work on the Taxonomy terms integration.
At this point, I believe the Biblio module will be mostly functional. I'll still need to get the theme/views layers working properly, and make everything look visually similar to the current version of Biblio.
Finally, I'll need help going through the code and seeing what could be improved, testing functionality, testing usability, etc.

@dominikb1888 I'm definitely up for some help, if you'd like to join in on the fun. I could use some more developer's opinions on how I'm structuring things.
I'm working out of the 7.x-2.x branch on the Drupal repository. Go ahead and take a look at the code/commits on that branch, if you've got some time to kill. :P
Additionally, we can ask @rjerome if he's ok with adding more maintainers. Otherwise, I could always put this code on a separate sandbox project.

steinmb’s picture

Good news @smithdalec :)
Looking back on #42, what will be used to create the relations between fields/entities?

smithdalec’s picture

@steinmb Currently, I'm using Drupal's built-in system of linking each field entry to the entity ID for field/entity relationships.
As far as the contributor/biblio relationship goes, I have the same system in place for now (entity ID for each contributor listing).
The problem with this is that there are duplicate contributors in the database for each biblio record to which they contribute. My original plan to combat this was to implement a biblio_contribution join table between the biblio table and the biblio_contributor table in the database. I may still do this at some point, but I just wanted to get entities and fields working, first.
There may be a better relationship model than what I had in mind. If so, please let me know.

rjerome’s picture

First off, I would like to express my appreciation for all the hard work Dale is doing with regard to getting Biblio fully "fielded", I know how large an undertaking this is. I have been tied up on some other projects lately, so I've been taking a somewhat hands off approach, but I will definitely be back in the 7.x-2.x code shortly.

With regards to adding more maintainers... If dominikb1888 would like write access to the 7.x-2.x branch, that's not a problem. With the proviso that I'm kept in the loop as to what's going on.

@smithdalec, with regards to authors, you might also want to look at the http://drupal.org/project/name project, it may yield some ideas or perhaps it can be used as is.

I have also been working on moving all the gruesome "query building" code into a views plugin and the list display into views display plugin.

I don't anticipate the Keywords -> Taxonomy transition will be a big deal, since I pretty much had it all working at one point in the past, then reverted it back so that the 7.x-1.x branch would be as compatible as possible with the 6.x branch.

I will also look after CiteProc integration, which may also turn into a views "row" plugin.

Thanks again to all those pitching in to help. Together I think we can make an even better Biblio.

Ron.

rjerome’s picture

@smithdalec (#57) I believe you are on the right track with a linking table between the contributor entities and biblio entities. This is much like how Taxonomy terms are handled using the taxonomy_index table.

scor’s picture

@smithdalec have you considered http://drupal.org/project/entityreference? I'd be curious to hear your thoughts on that. One advantage here is that it is aligned with the trend of breaking dependencies on SQL and possibly allowing non-SQL backend storing. This is one of the trends I felt at DrupalCon Denver while discussing Drupal 8.

smithdalec’s picture

FileSize
415.99 KB

@scor I like the concept of limiting SQL queries as much as possible, so the Entity Reference module may be a good solution here. Either way, We'll need to solve the many-to-many relationship between biblio entries and authors. From what it looks like to me, it seems that Entity Reference would be a good solution if the Biblio/Author relationship was many-to-one. What I may be able to do with this is create a third entity type ("contribution" or similar) with two entity references, one referring to a biblio entry, and the other would refer to the author. This third entity could act as a "join table" between the biblio and contributor entities. I'm attaching a quick diagram I drew of how I imagine things would work.

ar-jan’s picture

Just throwing this in here as an idea (not a coder, I don't know how suitable this is): the Relation module seems to do these kinds of things very well and is light-weight - "Relation is an API module and storage model for both simple and the most complex relations between entities."

Edit: Oh, I see this was mentioned before in #43.

dominikb1888’s picture

Hey everyone,

sorry for not answering earlier on this. Was offline for two weeks...

@smithdalec: I've created a local sandbox with 7.x-2.x and will be testing this with a larger dataset. I will add bugs to the issue queue consecutively.

@rjerome: I'd be very glad to gain write access and will keep you in the loop. Is there any possibility to do pull requests on d.o? So one maintainer could be in control of the changes to be included.

Best,
Dominik

pomgod’s picture

Any update on the matter?

sdrycroft’s picture

It looks like work on the 7.x-2.x branch of Biblio has ground to a halt (the last commit was 2012-11-19). Is this the case? Is Biblio likely to move to use Fields any time soon?

Apologies for the slightly harsh tone of my message, but it has been over three years since this issue was first raised.

steinmb’s picture

Status: Needs work » Active
Issue tags: +Needs issue summary update
Liam Morland’s picture

Category: Task » Feature request
Issue summary: View changes