6

I have a question that I am struggeling with. A positive answer would help me to remove a piece of unwanted customization.

Is it possible to add metadata from the event system to a component where the field is not present in the metadata schema? The reason I ask this, is that I am creating a dynamic implementation where content is retrieved using metadata.

Some of the fields I would like to display are in the content tab of the component. This to make sure the Content Managers can find these fields. Because of this, I would like to add these fields to metadata during publishing. This to make this content available as metadata in the Broker database, where I can use the Broker API to retrieve these fields.

I have read a post on setting a value in a page's metadata by using the following fragment that Nuno provided:

    Itemfields meta = new ItemFields(page.Metadata, page.MetadataSchema);
    SingleLineTextField categorisationField = (SingleLineTextField)meta["categorisation"];
    categorisationField.Value = "Some value";
    page.Metadata = meta.ToXml();

What I tried was to get the metadata as an XML fragment, and manually add the node to the metadata section (using the correct schema namespace). I then set the components metadata by using component.Metadata = metadata; (where metadata is the XML fragment). The component has/had a metadata schema attached.

So my question is: Does the publisher use the in-memory component representation, where the metadata entry is present, or does it get a new copy of the component when publishing. If the latter is the case, I will need to add a .save() and beforehand add the field to the schema.

Any thoughts? Is this possible, or is there a good alternative?

7

I see your point, there is an old PS implementation called Metadata Processor that performs the following logic.

  1. At publishing time there an special syntax written at the beginning of the template that writes the Output variable, that special syntax will instruct which design fields should be considered metadata.
  2. At deployment time a Deployer Processor (Metadata Processor) will read that special syntax and put it in Metadata.

This solution is not free since it was developed by PS.

Other option that you can use if to write something similar by using the AddMetadata method available in your Template Building Blocks, it will add any metadata to the package (your design fields for instance) then you will need to write a deployer extension to read it and put in Custom Meta - Check this post AddMetadata.

| improve this answer | |
  • I really liked the Custom Metadata Processer. Typically you can get it "for free" through contracting time with PS (reach out to Sales or PS for specifics). One catch worth mentioning--all templates should add the same set of metadata to keep the published custom metadata synchronized. Oh and the order of the syntax didn't seem to matter (I used it with XSLT CTs at the end of the markup). – Alvin Reyes Nov 15 '13 at 4:51
  • A good suggestion, however this still requires a deployer extension, which is exactly what I want to get rid of. What I was looking for is hooking into the publisher process, and (programmatically) modifying the transport package's content to include additional metadata. – Paul de Maesschalck Nov 15 '13 at 8:05
  • You can create a Transport Handler so that you can update the package. – Eric Huiza Nov 15 '13 at 13:05
  • This sounds interesting. Is there any documentation available anywhere, or can you point me in the right direction? – Paul de Maesschalck Nov 18 '13 at 12:29
  • It is not a documented extension point, but check this answer tridion.stackexchange.com/questions/2559/… – Eric Huiza Nov 18 '13 at 14:45
4

Please read my blog posts on TridionDeveloper.com, titled Querying ECL Metadata in the Broker and ECL event handlers. In there I handle the exact same topic (but then related to ECL).

In the first article, I discuss the options you have available on how to get additional Metadata added at Publishing time. Mind you I am not using the unsupported approach of adding Metadata which does not conform to the Schema (because I find that a too dirty approach, but it is used in the field and does work as you can read in Eric's answer). So I actually have Metadata Schema fields which I populate at Publishing time (using a TBB).

The sample code for the TBB is available on GitHub Gist.

In the second article I discuss doing the same via an Event Handler, as I noticed that my TBB approach didn't always work flawlessly, and also that the Event Handler approach wasn't such a problem as I initially thought.

The example Event Handler is available on Google Code and SDL Tridion World.

To come back on your question directly; does the publisher use the in-memory Component representation (or the Package Item)? No it doesn't, it requests the actual source for the item directly from the database. I found this out while trying to make ECL external metadata available in the Broker.

| improve this answer | |
  • Bart, Thank you for the quick reply. If I look at the code on GitHub, there still is a .save() present in the code, which means that I need to have the metadata fields already present in the schema. That means that the content managers will see duplicate fields when they re-open the component (Unless I hide them using a GUI extension). Is there no way to hook into the publishing process, at a time when no schema validation is done anymore ? The dirty solution as you call it? – Paul de Maesschalck Nov 14 '13 at 14:23
  • @PauldeMaesschalck Yes for my approach a save is required and thus you must have the Metadata field. As discussed in my second article, you can opt for hiding those fields from your editors through a UI extension like the Tridion FBI extension (as discussed here). If you want to hook into the Publisher process the 'dirty' way, then follow Eric's answer. – Bart Koopman Nov 14 '13 at 14:36
  • A description about the fields automatically being set during publish can help authors if you choose to leave the fields visible. If this wasn't delivery-side (custom) metadata, AppData would be another good place to store "hidden" information. The fields could even be a feature in case authors ever need to override the values. – Alvin Reyes Nov 15 '13 at 4:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.