Content type specific metadata capture form

Hi All,
Is it possible to have multiple metadatacapture forms?
We need seperate forms for the various content types, is it possible? if yes how?

Find more posts tagged with

Comments

kshitiz

You can define more than one ruleset in local/config/datacapture.cfg. And then you can map each rule to different content type using the vpath in metadata-rules.cfg.

If you go through TS Admin Guide, you can find more info about this.

iw_store

Hi All,
Is it possible to have multiple metadatacapture forms?
We need seperate forms for the various content types, is it possible? if yes how?

You can Have a container inside DCT as MetaData container define all items which are needed as metadata items and using FormApi or workflow you set as attribute.

OR If you are pushing to DB you can directly map between dcr and DB.

By this way you can have saparate netadata items for each cat/datatype

milind

You can Have a container inside DCT as MetaData container define all items which are needed as metadata items and using FormApi or workflow you set as attribute.

OR If you are pushing to DB you can directly map between dcr and DB.

By this way you can have saparate netadata items for each cat/datatype

This solutions seems better,
any other ideas are welcome.

Adam Stoller

This solutions seems better,
any other ideas are welcome.

It depends on your end-user experience requirements/desires and your overall design/objectives.

Putting the metadata fields within the FormsPublisher DCT is generally simpler on the end-user but may create an overwhelming form, which is then generally harder on the end-user.

Putting the metadata fields within the FormsPublisher DCT allows you to use FormAPI code which might help to offset the potential problems above (FormAPI is not *yet* available in the metadata capture form - but it's coming) - however, if you don't need FormAPI code for your metadata fields the original issue remains.

Putting the metadata fields within the FormsPublisher DCT means that you will either need to parse the DCR to find the metadata, or parse it to set the EAs on the files (an extra processing step) - here it's more of an issue of what you intend to do with this metadata and how you wish to access it down the line.

Putting the metadata fields within the metadata capture DCT means the metadata will automatically be added as extended attributes on the files (do you want the metadata on the DCRs or the generated files or both?)

As was stated earlier - you can utilize the metadata-rules.cfg along with multiple ruleset definitions in the metadata capture DCT in order to specify different sets (or sub-sets) of metadata fields based on branch paths, directory paths, file names and/or extensions (or a combination of all). The code for this would then be centralized instead of spread throughout various DCTs (though that could potentially be overcome with inline calls, but that in turn might slow down rendering of the FormsPublisher DCT form)

There are all sorts of trade-offs here - ultimately it comes back to what I mentioned in the beginning: requirements and design.