share config/forms: extend existing?

[aweber1nj]

Sorry if I missed this somewhere painfully obvious, but I have to ask before I start copy-and-pasting a ton of XML

Is there a way to include or extend an existing form or entire config for node-type and model-type evaluators?  Basically, if I have a two or three deep content model, instead of copying each parent's forms, I'd like to "include" them or "extend" them in the child form and only add the necessary additional properties and possibly override the visibility or appearance.

Basically, good object-oriented work.

Other than thinking there might be a way to set an "or" in the condition-attribute (but then how would I control the order in which the elements were merged), I haven't figured out how to do this.  It seems like a straightforward thing to (possibly substantially) reduce the amount of copy-and-paste of the xml-config which reduces implementation errors and really lowers maintenance of the config.

Thanks in advance,
AJ

[amandaluniz_z]

That would be great….

[aweber1nj]

So you're telling me I did not miss reading about this feature – it does not exist?

[amandaluniz_z]

As far as I know it does not exist…. You need to do what you say, copy across all the properties defined in the parent type's form so they're visible in the subtype

[aweber1nj]

This sounds like a straightforward enhancement/patch if I find the right part of the FormsService/FormConfig code.

Don't know if I have the time to tackle it right now, but I may…

Thanks for the help (even if it wasn't the answer I hoped for!).

-AJ

[aweber1nj]

I have an initial test working pretty well.  I'm going to perform some more thorough testing and polish it up a bit.

Basically if you have something like:

<config evaluator="node-type" condition="tst:TypeA" >
  <forms>
    <form>
                <field-visibility>
                    <show id="cm:name" />
                    <show id="cm:title" force="true" />
                    <show id="cm:description" force="true" />
                    <show id="mimetype" />
                    <show id="cm:author" force="true" />
                    <show id="size" for-mode="view" />
        …
              </field-visibility>
              <appearance>
                    <field id="cm:title" label-id="prop.cm_title">
                        <control template="/org/alfresco/components/form/controls/textfield.ftl" />
                    </field>
        …
              </appearance>
    </form>
  </forms>
</config>
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

With the "typical" one-to-three forms defined (I have three).

Then you follow that somewhere later in your xml (the code should re-order them as necessary before merging them, but I haven't tested that yet)…

<config evaluator="node-type" condition="tst:TypeB" extends="tst:TypeA" >
  <forms>
    <form>
                <field-visibility>
                    <show id="tst:type_b_special" />
                     …
              </field-visibility>
              <appearance>
                    …
              </appearance>
    </form>
  </forms>
</config>
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

(Note the additional config attribute "extends".)

Such that you only added the difference and changes from TypeA to TypeB – not copied and pasted the entire config and edited it – it will correctly merge the two such that TypeB will display as if it was TypeA, and use the changes you specify (to hide something that TypeA showed, or use a different appearance, or added a property - as above).  And it will continue multiple levels deep (it will work if you have TypeC –> TypeB –> TypeA extending in order).

In this case, displaying the properties for "TypeB" will list the name, title, description, etc. inherited from TypeA's config which we "extended", as well as any additions you put into TypeB's config.

This cuts down on the amount of XML you have to copy-and-paste, edit and maintain significantly (IMHO, of course).

I have tested merging and overriding field-visibility and appearance elements so far.  I will test the rest!

A lot of the ".combine()" methods were already written by Alfresco Eng., I just had to write the code to logically walk the hierarchical configs backwards and make sure they were matched-up properly (ie. this should work for any consistent evaluator, condition, extends set).

More to follow if anyone cares!
-AJ

[amandaluniz_z]

That's great!!

Thanks for it! It would be nice if you could let us know which java classes you edited

Adei

[aweber1nj]

(Sorry to be away from my desk for a long-weekend….)

I had to edit the XMLConfigService.java (and its interface source, which just has constants).  I would have liked to just extend that class, but a lot of the methods were private and thorough, so I edited the original.  One other class, I think - I have them written down.  Once I test them, I'll post them all back to the community.

The nice thing is that, from all my testing so far, this class loads the xml configs at startup, so while there's probably some tiny additional overhead during startup for it to sort and consolidate the config elements, there's no impact whatsoever on runtime performance.

-AJ