My motivation for requesting a drupal.org CVS account is to contribute a module for building custom interfaces to Fedora Commons repositories (http://www.fedora-commons.org/). The Fedora REST API module provides a programming interface to invoke Fedora Commons REST methods. By itself, the module can be used to create a simple presentation layer for a collection of objects in the repository, without any module development or PHP coding. But its real power is as a rapid application development tool to code custom modules for creating, managing and publishing collections of complex digital objects.
The module provides a programming interface to invoke Fedora Commons REST methods, including a PHP class that encapsulates all the REST API methods so they can be easily invoked from other Drupal modules. It also defines a type of node ("fedora_object") that represents a digital object in the repository. This content-type can be extended by defining a new content-type in a custom module and invoking my module's hook implementations to add the Fedora object attributes to the node. A template .module file is included to simplify the process of creating modules that extend the "fedora_object" content-type.
This module is based on work I did for the Digital Humanities Observatory which is described here: http://www.slideshare.net/gourley/integrating-drupal-fedora.
RELATED WORK:
Islandora (http://www.fedora-commons.org/confluence/display/ISLANDORA/Islandora) is the only other module that integrates Drupal with Fedora Commons repository software that I am aware of. Islandora is hosted at the Fedora Commons site rather than drupal.org. Moreover, there are differences in purpose and approach between Islandora and my Fedora REST API that justify their co-existence. My module is intended as a basic API and a tool for developing modules to meet local requirements and idiosyncrasies. Islandora is a complete, almost turn-key, application for viewing and managing digital objects stored in Fedora, and does not expose a Fedora Commons web services API for extension. Another important difference is that my module has a flexible mechanism for mapping Fedora object structure and description to Drupal nodes, so it can work with the numerous core and contributed modules that operate on nodes, such as search, taxonomy, CCK, workflow, and the like. Islandora, on the other hand, provides an interface to Fedora Commons functionality for searching and browsing rather than storing structural or descriptive metadata in the Drupal database, so Fedora-linked nodes cannot be used in standard Drupal ways.
STATUS:
The Fedora REST API module is fully functional. Earlier versions of it have been used to create Drupal web sites for the Digital Humanities Observatory, for example: http://dho.ie/doegen/. However, I would like to share it with other repository projects so we can get sense of (and improve) how well it works with different kinds of digital content and use cases, and to get additional maintainers from other institutions to share in its ongoing development.
The module has not yet been migrated and tested for Drupal 7, but if my application is accepted I will have a Drupal 7 release as soon as Drupal 7 is released.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | fedora_rest-6.x-1.0-beta1.tar_.gz | 23.82 KB | gourley |
Comments
Comment #1
gourley commentedI have attached a tarball of my fedora_rest module.
Comment #2
avpadernoHello, and thanks for applying for a CVS account. I am adding the review tags, and some volunteers will review your code, pointing out what needs to be changed.
Comment #3
avpadernoThe query doesn't filter out the user accounts that have been blocked, depending on the case, this can be a security issue.
The code should probably use
db_rewrite_sql().Strings used in the user interface should be passed to
t()(with the exception of when that is already done by Drupal code).Exceptions are only present in PHP 5, but the module doesn't declare its dependency from that version. Drupal 6 is still compatible with PHP 4.
The query can return more than a row. If you want to get only the first row, you should call
db_query_range().The line is added by the packaging script, and it should not be manually added.
The query could delete variables defined from a module with a name starting with fedora_rest_ (someone could create a module called fedora_rest_extension, and the module would delete also those variables). The preferred way to delete variables is to delete them singularly with
variable_del().The module has never been hosted on Drupal.org. The update functions should be removed.
Using constants for the permissions would probably cause problems for the translation script, which is not able to extract the permission strings to put them in the translation template file (this means the permission strings will not be translated).
It is also better to keep the permission strings consistent (if the first permission makes reference to Fedora object node, also the other permission strings should use the same term).
Remove any calls to debugging functions.
Use the
t()-placeholders, instead of concatenating strings. This gives more context to who translates strings.Why isn't the code using
'#type' => 'value'?Strings used in the user interface should be in sentence case.
Why isn't the code using the default format set by Drupal?
The hook is an implementation of
hook_form_alter(), nothook_alter(). The last parameter is not passed to the function from Drupal. The code should use a local variable, or simply a literal string.Comment #4
gourley commentedThanks for the feedback. I am working on bringing it up to standards, but I'm not sure I can conform to drupal usage in all cases right now. So I'm posting the module on github and see if there is enough community interest to rewrite for contributing it to drupal.org.
If anyone is interested in using (or helping develop) this module, see http://github.com/dongourley/fedora_rest
Comment #5
avpadernoComment #6
avpadernoThere is already an application for a similar module (#771670: alxp [alxp]).
Comment #7
gourley commentedThanks.
Comment #8
avpadernoComment #9
gabidrg commentedHi Don and Alberto,
I've just had a presentation on Fedora Commons and Drupal at DrupalCamp Timisoara 2010 (http://drupalcamp.ro) this weekend. I included Don's module in a comparison vs Islandora and not Alexander's O'Neill work (http://drupal.org/node/771670) since Don's implementation of Fedora REST Api is complete: it includes both REST API's of FC, API-A for access, and API-M for management. As far as I've seen in the other project (alxp), only API-A is implemented there.
I followed Gabor Hojsty's suggestion to give some feedback on this issue, after presenting Fedora Commons and Drupal at our camp, so here it is. I suggest we have a merge between projects, maybe Don and Alex can agree. I think Don's module is more complete now. More, Don already has live sites running based on his contribution, so we have a broader base for starting and expanding the module. I've already contacted Don and I am volunteering to help solve the code standards issues. I already have a CVS account, so we can make a team of three working on this integration.
All the best,
Gabriel Dragomir
Drupal Romania Association
Comment #10
avpadernoLet's see what gourley thinks.
Comment #11
gourley commentedI think its a great idea, and I am very happy to get Gabriel's help with this. I would like to work with Alex also but am not sure what would be involved in merging our work.
Comment #12
gabidrg commentedAlexander O'Neill is one of the developers of Islandora, at UPEI. I am not sure where he intends to head with development on his API module and what's next on Islandora's plate, but as long as we get along having a Fedora REST API project released, we can think about what should be done next. For sure, a complete rewrite will be needed for Drupal 7 to accomodate the fields-instance-bundle paradigm and new database abstraction layer in D7.
When thinking about merging, I was more thinking about deciding which of the projects should get promoted into Drupal.org, since they really implement the same functionality, maybe with slightly different programming approaches. I will try to compare what we have in both projects. So far, I've seen Don's project as being more complete.
Comment #13
boris mann commentedPlease grant CVS access as a co-maintainer for Fedora Commons API #862262: Grant CVS access to gourley and alxp as co-maintainers
Comment #14
avpadernoThank you for your contribution! I am going to update your account.
These are some recommended readings to help with excellent maintainership:
You can find more contributors chatting on the IRC #drupal-contribute channel. So, come hang out and stay involved.
Thank you, also, for your patience with the review process.
Anyone is welcome to participate in the review process. Please consider reviewing other projects that are pending review. I encourage you to learn more about that process and join the group of reviewers.
I thank all the dedicated reviewers as well.
Comment #16
Yorkaev commentedHi EveryBody,
First of all, thanks for your module. Im trying to use your module but I dont know how to configure Fedora API settings. What should I have to put in the field "Collection URI"??
I have a fedora in http://localhost:8080/fedora with this information:
Base URL: http://localhost:8080/fedora
Version: 3.4.2
PID Namespace: changeme
PID Delimiter: :
Sample PID: changeme:100
Retain PID Namespace: *
OAI Namespace: example.org
OAI Delimiter: :
Sample OAI Identifier: oai:example.org:changeme:100
Sample Search URL: http://localhost:8080/fedora/objects
Sample Access URL: http://localhost:8080/fedora/objects/demo:5
Sample OAI URL: http://localhost:8080/fedora/oai?verb=Identify
Admin Email: bob@example.org
Admin Email: sally@example.org
The problem, is that when I try to create a fedora object, the combo "Repository Collection" is not filled.
Thanks in advance
Comment #17
avpadernoI am giving credits to the users who participated in this issue.
Comment #18
avpaderno