Leveraging templating engine services more generally

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

jpotts

Any thoughts on how the templating will be implemented? It seems like there is an opportunity to do something that could be useful not only for non-technical content contributors of web content but for more general cases as well.

For example, if you were to use an XForms implementation, you'd need an intuitive way for people to describe the model and a simple form layout. The web content would be stored as XML and transformed into whatever format (HTML, PDF, etc.) using XSLT.

But this could also be more generalized for uses beyond WCM which would give non-technical users the ability to create simple forms that could be rendered in their web sites or on their portals and submitted back in to the repository as XML (and subsequently being transformed, routed around as part of a workflow, etc.).

Will the templating implementation lend itself to this?

Jeff

kvc

For example, if you were to use an XForms implementation, you'd need an intuitive way for people to describe the model and a simple form layout. The web content would be stored as XML and transformed into whatever format (HTML, PDF, etc.) using XSLT.

Yes.  Our goal is to provide a simple wizard to create/register a new content type.  Each content type would be defined by an XML Schema.  In the case of an intranet, for example, a delegated admin would be able to use the wizard to create a simple form (two textboxes, 50 characters in length, mandatory; one textarea, 250 characters max, WYSIWYG editing) and have the wizard generate the XSD on the fly.  Simple things will be simple.  For more complex publishing use cases, for example product information publishing to an eCommerce site, a web developer can use the wizard to upload an existing XSD (created by the developer using whatever tool s/he chose to use) and register the new content type.  Complex things will be possible.

In either case, you get standardized XML.   We also plan on supporting a plugging templating engine and allow you to register a default template that gets applied against this XML when you create the new content type.  One a site by site basis, a delegated admin select a particular form to be used on their site can override the default and choose their own template to be applied to the XML to generate site-specific page.  By default, we will support Freemarker and XSLT as templating engine, with our own sample down in Freemarker. 

But this could also be more generalized for uses beyond WCM which would give non-technical users the ability to create simple forms that could be rendered in their web sites or on their portals and submitted back in to the repository as XML (and subsequently being transformed, routed around as part of a workflow, etc.).

Will the templating implementation lend itself to this?

A design goal is to expose our data capture controls for use in your run-time environment.   This means that instead of just pulling up an Alfresco-specific form you could programmatic via your XSLT or Freemarker template generate a web page that had your layout and look-and-feel that contain Alfresco control for capture content, streaming back XML to our back-end content management repository (as opposed to the Alfresco repository being used to serve run-time content), and initiate workflow, version control, staging, etc.

We plan on posting an update to the wiki end of next week that outlines the design of our new data capture mechanism.

Stay tuned for the exciting details!