Extending Zymonic with polymorphism (sub-classing)
In general sub-classing is done by copying the existing class e.g. Zymonic/Field.pm into the appropriate sub-directory (Field) with a new name e.g. Zymonic/Field/MySubClass.pm, changing the package name, the content of the POD and removing all the methods from the original file apart from any you intend to modify.
my $self = shift;return ( $self->SUPER::script_includes(), '/Zymonic/Field/01_MySubClass.js' );
If the HTML needs changing then the XSL must also be extended; generally this can be done by adding XSL that has a specific template match on 'subtype' e.g.
<xsl:template match="*[@type='FieldFillCalculation' and @subtype='SubForm']">
Including the XSL is currently a bit of a work in progress... Historically it required a change to at least one of the already used XSL templates to add an 'import' line that imported the XSL associated with the object e.g. in stylesheets/ZymonicField.xsl there is:
<xsl:include href="Field/Choice.xsl" /> <xsl:include href="Field/DateTime.xsl" /> <xsl:include href="Field/File.xsl" /> <xsl:include href="Field/Glob.xsl" /> <xsl:include href="Field/HTML.xsl" /> <xsl:include href="Field/LinkedField.xsl" /> <xsl:include href="Field/MultipleChoice.xsl"/> <xsl:include href="Field/MultipleChoiceLinkedField.xsl" /> <xsl:include href="Field/MultipleValue.xsl"/> <xsl:include href="Field/PasswordCapture.xsl" /> <xsl:include href="Field/SubFilter.xsl" /> <xsl:include href="Field/SubForm.xsl" /> <xsl:include href="Field/ZymonicXML.xsl" />
However, recently we added a mechanism for XML authors to add XSL that would be added to the 'main' (and block combined) XSL for the system by the Installer / config build:
<xs:complexType name="IncludeXSL"> <xs:annotation> <xs:documentation>Used to add XSL to the Main and Block XSL</xs:documentation> </xs:annotation> <xs:choice maxOccurs="unbounded"> <xs:element minOccurs="1" maxOccurs="1" ref="ZName" /> <xs:element minOccurs="1" maxOccurs="1" type="xs:string" name="XSLhref" /> </xs:choice> </xs:complexType>
I believe it should be possible for new custom field classes to leverage this functionality - but it will require them to trigger code during config build.
TODO - replace the above once its actually been tried!