Page Layout and Site Management in Alfresco 2.1?

[edgar]

Hi,

A question about the WCM roadmap.

In the roadmap for 2.1 I read:

WCM will add new tools to simplify page layout, site management

On the Alfresco WSF Forum Luis Sala states:

the long term roadmap calls for making page layout management part of the product

You can see my questions coming.. 😉

1/ Will page layout and site management indeed be added in the upcoming 2.1 release?
2/ If so: can Alfresco give us any insight into these features at this moment?
3/ How do these features relate to what is done in the WSF project?
4/ Is Alfresco 2.1 GA still scheduled for mid-may?

What I also said on the Alfresco WSF forum is:

We expected page layout management to be on the short term roadmap for Alfresco WCM, not the long term.

Many web content management systems start out with a page management system and build their product from there. I think the approach that Alfresco (WCM) chooses is better in many ways. However if Alfresco does not offer a page layout management system in the short term as opposed to the long term we (and others with us) will not be able to wait..

cheers,

Edgar

[kvc]

Edgar -


No, page layout will not be available with 2.1, although 2.1 will provide the foundation for page layout.

This foundation will be based on web scripts.  A web script is an URL-addressable (REST-based) template to generate content using JavaScript, Freemarker, PHP, or Java.  Web scripts will form that base for end-user configurable web components for such common things as nav bars, breadcrumbs, content lists, and more.  Currently under design, a web component will essentially be an web form used to capture parameters needed to execute a particular web script (what content list to display?  how may to display?  what sort order?).  These web components will be exposed via a gallery in a new page composition environment, which will provide a WYSIWYG drag-and-drop environment for web publisher to composed dynamic web pages.  This WYSIWYG environment itself wll be based on our XForms implemenation (with a different presentation layer) and will output standard XML for versioning and staging.  These page XMLs will be married with a template for generating a standard JSP page (or aspx page) and that uses a pre-built tag for fetching an URL that corresponds to the web script to generate different sections of your page.

It's all very exciting stuff.

So, the core is our current XForms and upcoming web script infrastructure with 2.1.  This is our highest dev priority in WCM post 2.1 - the buildout of the page composition environment.

Keep pinging us for details.  We hope to get further along in the design (start implemenation?) this May.

Also, posted an update to the wiki on 2.1.  You can find that here:

http://wiki.alfresco.com/wiki/New_Web_Content_Management_Plan


Kevin

[edgar]

Cheers Kevin

It's all very exciting stuff.

Indeed! It sounds very good indeed. The main question we as a company have is: can we live without it in the meantime? So the Alfresco WCM roadmap is very crucial for us to answering our concern: do we invest in Alfresco WCM at this point in time?

Maybe you can also have a look at the reaction I posted on the WSF forum and post a reaction? I am curious if the way we see page layout is similar to yours.

Is it a better idea to use this forum for this discussion rather than the WSF forum?

cheers,

Edgar

[kvc]

In the current version of Alfreso (2.0) we have implemented the scenario above as follows:

- The page content model as well as the content models for the separate page content elements are implemented using Web Forms.
- These content element Web Forms have a XSLT template associated with them causing them to be rendered as a JSP fragment file.
- The page Web Form has a XSLT template associated with it that renders the HTML of the page and included all of the content elements as JSP includes.
- The references from the page Web Form to the external content items are implemented using anyURI fields.

First off, if you're looking to devolve responsibility for page creation in addition to content creation to business users, this is the best approach with 2.0.  This model also lends itself to where we will be heading in the near-term (page definitions an XML asset authored via a Web Form).

The page content model defines fields for all elements on the page that a content manager should be able to manage. Things like the page title, the page metadata, textual content but also references to content items that are managed _separately_ from the page. Take for example a news item: this news item is managed as a separate content item and can be shown on multiple pages. On the home page for example a list of links to the last 5 news items could be shown while every news item itself is shown on a separate news item page.

Agreed.  Moving forward, our plan is to support Web Forms for pages, components, and content.

Content created via a form will be the standard XML we create today.  This content can be sourced into one or multiple components on one or multiple pages.  Content referenced within a component will have that reference indexed with our upcoming links management system, with will enforce referential integrity upon submission for any move, rename, or delete events.

Components will be reusable assets across various web pages and web projects.  A component will be defined by a web script (a Freemarker template executed server-side and fetched via an URL) and a web form, which will specify what parameters of the component can be modified by and end-user.  For example, an end-user may be authorized for a list component to specify what list of items to fetch, how many to display, and what properties to output in the list.  We intend to ship a basic library of components (similar to the components you see in WSF, but refactored to use web scripts and web forms, using a new content model to define a component and store and manage in the data dictionary).

Pages will be end-user created content that specifies a set of included components, where they live on the page, and how the components are to be instantiated.  Pages will be defined by a web form, but with an alternative JSP binding to our XForms model to provide a WYSIWYG composition environment.  When creating a page, a user will be able to access the library of web components, add them to a page, and double-click to bring up the web form associated with the component to specify those paramaters needed to instantiate an instance of it on the page.  For example, a user might add three instances of a teaser component onto a page, and, double-clicking on each one, create a reference to a content item to be sourced into each teaser (where the teaser component uses that reference to extract the title and abstract and thumbnail image from the content XML, and creates a link to another web page that displays that content item).  The details on page components and all component parameters will be stored in a single page XML which will go through a normal Alfresco versioning, staging, workflow, and deployment process.  The overall layout and styling will be governed by your CSS, which will be independently managed by a web developer in the web project (where sandboxing and virtualization becomes key:  change the CSS,  and then test the overall site).

We also intend to support the notion of page templates.  A page template can be created by using a normal page form, putting some basic components on a page and pre-specifying their parameters.  You'll do this to set up basic headers, footers, and nav controls, and then save as a template.  When creating a Web Project, you'll be able to associate it with one or more page templates.  When a user goes to create a page, just like when they go to create a content item, they will be able to select from this available list and be off and running.

Now, a couple of things:

*  You will likely have a separation of users that will have access to create content versus access to creating pages.  This will differ for intranet and internet settings.  In an intranet, everyone may be able to create a page, where most of the page is locked down via the template except one main body section.  In an internet setting, web publishers (members of the web team) may be the only authorized people to create web pages, sourcing data created independently by lots of content contributors in the business.  The goal is to make the system as flexible as possible here.

*  Separating page creation and content creation is great, but in an intranet setting could mean too many extra click if you just want a basic page to display a single content item.  To solve that, when you're specifying the details of a component (for example, a content display comoponent in the main body section of an intranet page), where one doesn't exist, we'll let to kick-up the content creation form to create a new piece of content on-the-fly. 

*  Live-site editing.  Live-site editing becomes interesting in this model.  Do you want to modify the overall page (add or remove a component), modify the details of a particular component (change what asset it references), or the content item itself?  Any and all will be easily possible, but the GUI implications of how you discretely embed edit controls for the three possible things people want to modify we haven't completely thought through yet.  The user experience could become quite overwhelming.  More thought still needed here.

*  Static versus dynamic sites.  With the new model, we'll give you the option of pre-generating the page completely statically or deploying as a JSP (which will be responsible for fetching each web script, passing the appropriate parameters to that web script, and executing the server-side Freemarker template which does all the work).  Once again, choice is everything (Internet sites you may want to deploy dynamically, but intranet sites statically, for example).

Initially I am not looking for a drag-and-drop interface but I am looking for better support for the scenario I sketched above. The content manager should at the very least be able to see the difference between pages and other content items in the Alfresco Web Client.

If we can, we'll try and get the basics of the above out without being gated by the WYSIWYG interface.  We're working out details here.

Is it a better idea to use this forum for this discussion rather than the WSF forum?

Feel free to post to either.  Do note, however, that this is the only forum monitored (yes, every post is read by every engineer, even if it doesn't always seem that way) by Engineering.  The right model is to post specific questions and enhancements on the current implementation of WSF on the WSF forum, but anything related to future product enhancements along the lines above on this forum.

Cheers!

Kevin

[adriano]

So, in this scenario, if I understand correctly, the web scripts will be used to retrieve content items which could be generated by business users. Are these content items stored in the ECM or they should all be stored in the WCM ?

[kvc]

Either or both.

Generally, particularly for public-facing sites that you'll be replicating to multiple front-end servers outside your firewall, you'll likely to sourcing documents from a web project, where the documents are secure, locked-down PDF renditions "published" from an Alfresco space using a content rule (new to 2.0.1, you have a pre-built action in the Rules wizard to copy an asset from a space to a specific directory in a Web Project.  You can use this ideally to support conditional publishing of a document to multiple websites after transforming to PDF based on capturing some metadata property on document check-in - for example, select the "Publish" attribute and have that trigger the rule). 

If you're in an intranet setting, however, you're very likely to serve document directly from a space, most likely without any sort of transformation.  This is the model for lots of things, where documents might be created and one space used for internal collaboration and then promoted via a rule to a second space which represents an approved library of documents.  Items within this document library might need to be display via an HR website or internal IT website, for example, and doesn't necessarily need to be promoted into a web project, although web pages within a web projects will be able to display their content via a component (of course, if not promoted into a web project you will not have that version of the asset snapshoted along with the site, rather just the reference to it.  So you'll want to make the decision whether to promote to a web project or reference in place based on whether or not integrated snapshoting and rollback is needed).

Great question.  Please do take a look at the new support for rules-based promotion to a web project with 2.0.1.  This is critical, as knowledge workers should just work on business documents (particularly via CIFS) and shouldn't necessarily need to be concerned with the web publishing process.

Keep the questions coming.


Kevin