add fields to institution description

[Bojan Marinkovic]

Dear all,

I am working on AtoM 2.1 within CENDARI project.

During the project my colleagues have developed the new schema for the description of an institution. It differs from the actual Isdiah format a little bit, namely, couple of the new fields have to be added.

My plan is to add all those fields within the repository table, so my plan is to realize by following:
- change config/schema.yml
- make a new plugin by editing existing sfIsdiahPlugin
- to enable the new plugin

I have couple of questions:
- is it possible to achieve this goal by the proposed plan?
- if it is possible, do I need to make changes in some other parts (lib/form or lib/routing /apps/qubit/modules/repository)?
- is there some other better, cleaner or simpler way to realize this goal?

Kind regards
Bojan Marinkovic

[Jesús García Crespo]

Hi Bojan,

On Fri, Dec 12, 2014 at 2:53 AM, Bojan Marinkovic <bol...@gmail.com> wrote:

I have couple of questions:
- is it possible to achieve this goal by the proposed plan?
- if it is possible, do I need to make changes in some other parts (lib/form or lib/routing /apps/qubit/modules/repository)?
- is there some other better, cleaner or simpler way to realize this goal?

Changing the repository table may bring your application to a state where it's hard to keep your own customized version of AtoM up to date because there is a lack of tooling in order to support local schema changes - our sql-upgrade task is a bit too rudimentary if you compare it with other more advanced tools out there. Assuming that you don't want to stop pulling new upgrades from the AtoM public project in the future, I'd suggest to do data model changes that are less invasive, e.g. instead of modifying the stock repository table you could create an additional repository_whatever table (1:1) with the extra fields that you need. The plugin infrastructure lets you define additional schema.yml files. See qbAclPlugin as an example.

You may want to take a look at sfRadPlugin too, where we took a different approach. Instead of creating a new table we added fields in QubitProperty (propery table), which is basically a key/value store. Inside the plugin there is also a sfRadPlugin class that wraps a QubitInformationObject with the additional fields. The wrapper provides a magic getter/setter that maps its properties to its respective tuples in the property table of the database. I'm not sure if that sounds scary but it's actually pretty easy to manage. Take a look at the sfRadPlugin class:https://github.com/artefactual/atom/blob/qa/2.2.x/plugins/sfRadPlugin/lib/sfRadPlugin.class.php.

Let us know if you have more questions. If you open source your project we'll be able to provide better help.

Regards,

 

--

Jesús García Crespo,
Software Engineer, Artefactual Systems Inc.
http://www.artefactual.com | +1.604.527.2056

[Bojan Marinkovic]

Hi Jesús,

Changing the repository table may bring your application to a state where it's hard to keep your own customized version of AtoM up to date because there is a lack of tooling in order to support local schema changes - our sql-upgrade task is a bit too rudimentary if you compare it with other more advanced tools out there. Assuming that you don't want to stop pulling new upgrades from the AtoM public project in the future, I'd suggest to do data model changes that are less invasive, e.g. instead of modifying the stock repository table you could create an additional repository_whatever table (1:1) with the extra fields that you need. The plugin infrastructure lets you define additional schema.yml files. See qbAclPlugin as an example.

I can agree with you about that it is better to make less invasive changes.
 

You may want to take a look at sfRadPlugin too, where we took a different approach. Instead of creating a new table we added fields in QubitProperty (propery table), which is basically a key/value store. Inside the plugin there is also a sfRadPlugin class that wraps a QubitInformationObject with the additional fields. The wrapper provides a magic getter/setter that maps its properties to its respective tuples in the property table of the database. I'm not sure if that sounds scary but it's actually pretty easy to manage. Take a look at the sfRadPlugin class:https://github.com/artefactual/atom/blob/qa/2.2.x/plugins/sfRadPlugin/lib/sfRadPlugin.class.php.

Let us know if you have more questions. If you open source your project we'll be able to provide better help.

To be honest I was not able to understand how qbAclPlugin can solve "my" problem. For the second solution, it was a little bit easier to see what is going on, but still I cannot see the connection with the current online form for institutional description (where mentioned fields should stand) and this plugin.

To conclude, CENDARI project will provide open source results, and we need to add couple of new fields in the institutional description form and to store them to the database in the least invasive and the easiest way.

Regards
Bojan

[Dan Gillean]

Hi Bojan,

Jesús has tried to offer 2 different approaches that might help you achieve your development goals in the least invasive way possible, and has pointed to 2 areas of the code where you might find examples where we've taken these approaches in AtoM. But trying to offer detailed development guidance via a support forum can be very difficult!

I just thought I would mention here that, if you are really stuck, you might consider scheduling a training session with an Artefactual developer? We offer end-user training (see: http://www.artefactual.com/services/online-atom-training/) but we have also coordinated some guided developer training in the past. In short, we set up a WebEx video session, so you and the developer can share screens and talk in detail, with examples, about your development goals. We can record the session as well and make it available to you.

If this is of interest to you, please feel free to contact us off-list. Otherwise, I hope that you've found a good strategy to move forward in your development project!

Kind regards,

Dan Gillean, MAS, MLIS
AtoM Product Manager / Systems Analyst,
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

--
You received this message because you are subscribed to the Google Groups "ICA-AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To post to this group, send email to ica-ato...@googlegroups.com.
Visit this group at http://groups.google.com/group/ica-atom-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/a3346f3b-e43c-4fa2-b6db-cac022053f63%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.