Templating and Normalized Modular Content

I'm designing templates and DCT's for a new website. I'd like to make the content modular to support content reuse.

My vision is that authors would be able to select content for insertion to parent host DCT's and use TPL's for whole pages calling component tpl's for the modular bits.

This is old hat as I've done this before. Is this the BEST approach or is there other methods?

There are some common issues with this method.

1). If a component gets updated how do you force the generation of all pages that consume it?

2). What mechanisms can be used to filter the list of content components listed for selection in the host DCT. Is it metadata? If so is it true EA metadata for values in the DCR?

Solaris 6.7.1

Find more posts tagged with

Comments

ISCBorisB

I'm designing templates and DCT's for a new website. I'd like to make the content modular to support content reuse.

My vision is that authors would be able to select content for insertion to parent host DCT's and use TPL's for whole pages calling component tpl's for the modular bits.

This is old hat as I've done this before. Is this the BEST approach or is there other methods?

There are some common issues with this method.

1). If a component gets updated how do you force the generation of all pages that consume it?

2). What mechanisms can be used to filter the list of content components listed for selection in the host DCT. Is it metadata? If so is it true EA metadata for values in the DCR?

Solaris 6.7.1

I normally try to make such components *truly* shared. This way you do not have to regenerate anything.

How to do it depends (mostly) on your rendition Environment. It can be SSI, asp's include [file|virtual],
jsp's include directive and/or the jsp:include element, XML Entities, JS Lists, DB Entries and whatnot.
Without details all that are just theoretical ruminations though.

MLee7404

I'm designing templates and DCT's for a new website. I'd like to make the content modular to support content reuse.

My vision is that authors would be able to select content for insertion to parent host DCT's and use TPL's for whole pages calling component tpl's for the modular bits.

This is old hat as I've done this before. Is this the BEST approach or is there other methods?

There are some common issues with this method.

1). If a component gets updated how do you force the generation of all pages that consume it?

2). What mechanisms can be used to filter the list of content components listed for selection in the host DCT. Is it metadata? If so is it true EA metadata for values in the DCR?

Solaris 6.7.1

This works if the content and the modules are rendered at run time and not page generated.

Tim__D

I normally try to make such components *truly* shared. This way you do not have to regenerate anything.

How to do it depends (mostly) on your rendition Environment. It can be SSI, asp's include [file|virtual],
jsp's include directive and/or the jsp:include element, XML Entities, JS Lists, DB Entries and whatnot.
Without details all that are just theoretical ruminations though.

Ok. I'm generating jsp pages. Here is what I'm thinking. The "host" DCT has browse / select fields whose label is something of meaning but whos value is a path to an XML file. Selecting a conent component results in a pointer to that XML resource. I then use a normal TPL to render a full jsp page but for the component parts of the jsp page say a product or review I just embed tags which use the pointer to render them on the fly using XSLT? That way when I update the resource the site updates without regenerating?

Any suggestions?

Tim__D

This works if the content and the modules are rendered at run time and not page generated.

Thanks. Yes that what I'd like to do..see the other thread. I do have questions though about the managment of the resources.

1) If I have pages that consume XML resources should I use auto naming of DCR's and remove rename functionality? I dont happen to like the generated names and am a little concerned about how they get created and if it will create an issue when users may be creating records in multiple branches and merging results. Also they may be merging resources to other applications? File naming is a bit of a concern and I also want to try to keep users out of file and directory diving as much as possible duing the authoring process.

ISCBorisB

Ok. I'm generating jsp pages. Here is what I'm thinking. The "host" DCT has browse / select fields whose label is something of meaning but whos value is a path to an XML file. Selecting a conent component results in a pointer to that XML resource. I then use a normal TPL to render a full jsp page but for the component parts of the jsp page say a product or review I just embed tags which use the pointer to render them on the fly using XSLT? That way when I update the resource the site updates without regenerating?

Any suggestions?

If you can, generate it all on the server side. Do not delay shared resource processing to the Browser, XML/XSL parsing and whatnot.

What I mean is to process (generate from TPL, whatever) your shared Components into full blown JSP Fragments, not XMLs.
If you need XML for something else as well, generate two assets from the Component's DCR: an XML, whatever you need
it for and JSP Fragment to point to from other JSP Pages.

Then when you generate full jsp pages you will generate corresponding JSP include directives <%@ include file="filename" %>
to reference Component JSP fragments. The include directive is processed when the JSP page is translated into a servlet class.
The end result is a Component de-referenced from multiple full Pages and not inserted into any of them. When you change this shared
resource there is no need to regenerate any *full* Page, it's the same include!

Beware! Compiled JSPs are servlets and can be cached (in the bytecode form) by servlet Engine. There are various ways to make sure
that modified assets are recompiled and that the cache is refreshed. You may for example use cache Tag to set certain timeout
for the Page fragments that contain includes, use flush Tag, etc.

Tim__D

If you can, generate it all on the server side. Do not delay shared resource processing to the Browser, XML/XSL parsing and whatnot.

What I mean is to process (generate from TPL, whatever) your shared Components into full blown JSP Fragments, not XMLs.
If you need XML for something else as well, generate two assets from the Component's DCR: an XML, whatever you need
it for and JSP Fragment to point to from other JSP Pages.

Then when you generate full jsp pages you will generate corresponding JSP include directives <%@ include file="filename" %>
to reference Component JSP fragments. The include directive is processed when the JSP page is translated into a servlet class.
The end result is a Component de-referenced from multiple full Pages and not inserted into any of them. When you change this shared
resource there is no need to regenerate any *full* Page, it's the same include!

Beware! Compiled JSPs are servlets and can be cached (in the bytecode form) by servlet Engine. There are various ways to make sure
that modified assets are recompiled and that the cache is refreshed. You may for example use cache Tag to set certain timeout
for the Page fragments that contain includes, use flush Tag, etc.

That idea looks promising. However I could see the number of assets growing a lot depending on the number of formats you have. That's why I like the concept of using XSLT on the server side to do the transformation of the source XML on the fly based on a desired format using an XSL stylesheet. That way like templating, I have 1 XML source and any number of formats that I can use as needed without growing the number of assets.