Adding new fields to QubitActor

62 views
Skip to first unread message

dany siriphol

unread,
Nov 7, 2014, 2:15:47 AM11/7/14
to qubi...@googlegroups.com
Hello

I am currently developping a plugin to support ISAD(G) for audiovisual content. I have been able the custom fields I need but now
I need each "creators" of an archival description to have a "role" property (such as Producer, Writer for example).
Adding a new property to QubitActor seems to me the easier way to implement this, unfortunately I have hard time figuring out how to do this.

I would like to add this feature inside my plugin code without altering Qubit code.

Do you have any guidelines about this? I noticed the sfIsaarPlugin is changing the way actors are displayed but it's quite obscure to me

Best regards

Jesús García Crespo

unread,
Nov 7, 2014, 1:09:03 PM11/7/14
to qubit-dev
Hi Dany,

Symfony 1.x + Propel let you have your own custom config/schema.yml file under a plugin. We do that in qbAclPlugin. You may want to take a look the official Symfony1 docs where they explain how to use the plugin infrastructure to extend the application. For example: http://symfony.com/legacy/doc/jobeet/1_4/en/20?orm=Propel

We also create classes that wrap our models adding more properties that are stored in the QubitProperty table when we don't think that it's worth it to alter the schema. An example could be plugins/sfRadPlugin/lib/sfRadPlugin.class.php - note how the constructor stores the resource and the __get and __set magic methods allow us to add fields to the original QubitInformationObject. Internally, these new fields are stored in the property table.

We make extensive use of class inheritance and PHP tricks like magic methods. I can understand how that doesn't make the code easier to understand. I'd say that something helpful to me is to remember the workflow on how a request/response is handled in the application. For example, when someone is visiting a ISAAR description, the controller starts on http://goo.gl/6p4mY1, but first thing we do is to call ActorIndexAction which hydrates the QubitActor instance and stores it in $this->resource. In L34, we wrap that object as a sfIsaarPlugin object, which basically adds the maintenanceNotes []property which as you can see in L36, it's persisted using QubitNote which is a 1:N. These magic methods are somehow cryptic but they are well documented in php.net.

For your particular case, you should look at EventEditComponent and InformationObjectEventComponent. You could subclass InformationObjectEventComponent for your particular case adding the files that you need and managing how are they stored, using your own tables or leveraging QubitProperty, QubitNote, etc...

Let me know if you have more questions. I know it can be tricky!

--
You received this message because you are subscribed to the Google Groups "Qubit Toolkit Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qubit-dev+...@googlegroups.com.
To post to this group, send email to qubi...@googlegroups.com.
Visit this group at http://groups.google.com/group/qubit-dev.
For more options, visit https://groups.google.com/d/optout.



--
Jesús García Crespo

mi...@artefactual.com

unread,
Nov 7, 2014, 7:39:12 PM11/7/14
to qubi...@googlegroups.com
Hi Dany,

I recently did something that sounds very similar to what you're doing. What I did was reference the sfDcPlugin as it lets you edit actor type in the same way you might want to edit an actor's role. It's a fairly involved process, but possible if you've got the time to work through it.

To add actor roles you'll want to:

1) Add an actor role taxonomy:

  * Add a constant to for the new taxonony's ID in lib/model/QubitTaxonomy.php
  * Add a migration in lib/task/migrate/migrations to populate the taxonomy with terms

2) Add an actor role column to the schema:

  * Add the column to config/schema.yml
  * Update the SQL initialization file to reflect new schema: ./symfony propel:build-sql
  * Update the PHP class definitions to reflect new schema: ./symfony propel:build-model

3) Add the ability to edit the actor role in the UI:
  * Add a component for editing actors, Dublin Core plugin shows example of this:
    plugins/sfDcPlugin/modules/sfDcPlugin/actions/dcNamesComponent.class.php
  * Make a partial template for your component, example:
    plugins/sfDcPlugin/modules/sfDcPlugin/templates/_dcNames.php
  * Change your plugin's edit action to use the component, example:
    plugins/sfDcPlugin/modules/sfDcPlugin/actions/editAction.class.php
  * Change addFile and processField to deal with the role field, example:
    plugins/sfDcPlugin/modules/sfDcPlugin/actions/editAction.class.php

4) Add the ability to show the role for those viewing descriptions
   * See DC view template for example: plugins/sfDcPlugin/modules/sfDcPlugin/templates/indexSuccess.php

Cheers,
Mike Cantelon
Artefactual Systems
Reply all
Reply to author
Forward
0 new messages