Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
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:
- This module's users will get the same rich functionality as other fields.
- Module maintainers may drop code that duplicates what's already in fields.
Comment | File | Size | Author |
---|---|---|---|
#61 | photo.JPG | 415.99 KB | smithdalec |
#2 | biblio.tar_.gz | 14.58 KB | Aren Cambre |
Comments
Comment #1
Aren Cambre CreditAttribution: Aren Cambre commentedI'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).
Comment #2
Aren Cambre CreditAttribution: Aren Cambre commentedFound 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."
Comment #3
rjerome CreditAttribution: rjerome commentedThanks 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.
Comment #4
Aren Cambre CreditAttribution: Aren Cambre commentedI 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:
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?
Comment #5
Aren Cambre CreditAttribution: Aren Cambre commentedAfter 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?
Comment #6
rjerome CreditAttribution: rjerome commentedMy 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.
Comment #7
Aren Cambre CreditAttribution: Aren Cambre commentedExcellent! 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.
Comment #8
rjerome CreditAttribution: rjerome commentedWithout 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.
Comment #9
Aren Cambre CreditAttribution: Aren Cambre commentedI 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).
Comment #10
rjerome CreditAttribution: rjerome commentedI 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.
Comment #11
Aren Cambre CreditAttribution: Aren Cambre commentedBut reckless abandon is so fun!
Comment #12
hchall CreditAttribution: hchall commentedtracking.... and thanks for all of your efforts, Ron!
Comment #13
Aren Cambre CreditAttribution: Aren Cambre commentedConfiguration Management, Automation & Features could define a path towards CCK support.
Comment #14
bekasu CreditAttribution: bekasu commentedAren,
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.
Comment #15
Aren Cambre CreditAttribution: Aren Cambre commented@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.
Comment #16
bekasu CreditAttribution: bekasu commented@aren
I understand the concept. Just looking forward to seeing your code. It will help many folks.
Comment #17
Aren Cambre CreditAttribution: Aren Cambre commentedThat'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?
Comment #18
rjerome CreditAttribution: rjerome commentedWould you care to share the names of those modules with us?
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.
Comment #19
Aren Cambre CreditAttribution: Aren Cambre commented@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.
Comment #20
Gerben Zaagsma CreditAttribution: Gerben Zaagsma commentedsubscribing
Comment #21
iko CreditAttribution: iko commentedHi,
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...
Comment #22
rjerome CreditAttribution: rjerome commentedThank 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.
Comment #23
iko CreditAttribution: iko commentedHmm, 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 !
Comment #24
xkater CreditAttribution: xkater commentediko: i just noticed this (accidentally) - ! this is a wonderful explanation ! and should become a "Case Study"!
Comment #25
rjerome CreditAttribution: rjerome commentedYes, I agree. I hope you didn't interpret my lack of reply for lack of respect, I've just been swamped lately.
Ron.
Comment #26
iko CreditAttribution: iko commentedno problem ! thanks !
Comment #27
roderikI 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?
Comment #28
Aren Cambre CreditAttribution: Aren Cambre commented@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.
Comment #29
roderikThe 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.
Comment #30
Aren Cambre CreditAttribution: Aren Cambre commentedI see your point. Yes, this could be relevant once the fields-aware version is far enough along to test the upgrade process.
Comment #31
steinmb CreditAttribution: steinmb commentedYay! 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
Comment #32
rjerome CreditAttribution: rjerome commentedTrust 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.
Comment #33
kehan CreditAttribution: kehan commentedsubscribing
Comment #34
shenzhuxi CreditAttribution: shenzhuxi commentedHope 7.x-2.x release soon. Maybe I will contribute codes for better pubmed import.
Comment #35
rjerome CreditAttribution: rjerome commentedContributions are always welcome.
Comment #36
shenzhuxi CreditAttribution: shenzhuxi commented@rjerome
I add the idea to 2011 SoC.
http://groups.drupal.org/node/134664
Can I access the latest codes from git now?
Comment #37
vunger CreditAttribution: vunger commentedHi,
Is it safe to assume that CCK fields will only be supported in 7.x versions and not in 6.x?
Comment #38
rjerome CreditAttribution: rjerome commentedThat'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.
Comment #39
azin CreditAttribution: azin commentedAny ETA on 7.x-2.x release as yet?
Comment #40
rjerome CreditAttribution: rjerome commentedNo, 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.
Comment #41
dominikb1888 CreditAttribution: dominikb1888 commentedIf 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?
Comment #42
rjerome CreditAttribution: rjerome commentedFrom 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.
Comment #43
dominikb1888 CreditAttribution: dominikb1888 commentedGood 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.
Comment #44
scor CreditAttribution: scor commentedIMO 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.
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.
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.
Comment #45
dominikb1888 CreditAttribution: dominikb1888 commentedOk, true. Custom Entity types is the better option... still thinking d6 too much.
Comment #46
rjerome CreditAttribution: rjerome commentedThanks guys, all good input and food for thought!
Ron
Comment #47
dominikb1888 CreditAttribution: dominikb1888 commentedOne 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.
Comment #48
dominikb1888 CreditAttribution: dominikb1888 commentedIf 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?
Comment #49
scor CreditAttribution: scor commentedIn 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.
Comment #50
ar-jan CreditAttribution: ar-jan commentedAlthough I have nothing much to weigh in on code/architecture, this
sounds good. The idea of separate content types for publication types reminds me of the term "content type madness" ;)
Comment #51
azin CreditAttribution: azin commented+1 for "IMO biblio should remain its content type,"
Comment #52
smithdalec CreditAttribution: smithdalec commentedI am starting the conversion to Drupal's Field system on the 7.x-2.x branch.
So far this is what's planned:
Any other thoughts?
Comment #53
Mark F CreditAttribution: Mark F commentedGreat news.
Comment #54
dominikb1888 CreditAttribution: dominikb1888 commented@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...
Comment #55
smithdalec CreditAttribution: smithdalec commentedUpdate 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.
Comment #56
steinmb CreditAttribution: steinmb commentedGood news @smithdalec :)
Looking back on #42, what will be used to create the relations between fields/entities?
Comment #57
smithdalec CreditAttribution: smithdalec commented@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.
Comment #58
rjerome CreditAttribution: rjerome commentedFirst 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.
Comment #59
rjerome CreditAttribution: rjerome commented@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.
Comment #60
scor CreditAttribution: scor commented@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.
Comment #61
smithdalec CreditAttribution: smithdalec commented@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.
Comment #62
ar-jan CreditAttribution: ar-jan commentedJust 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.
Comment #63
dominikb1888 CreditAttribution: dominikb1888 commentedHey 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
Comment #64
pomgod CreditAttribution: pomgod commentedAny update on the matter?
Comment #65
sdrycroft CreditAttribution: sdrycroft commentedIt 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.
Comment #66
steinmb CreditAttribution: steinmb commentedComment #67
Liam Morland