nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Deploying Only DCRs

PaulW

I have just arrived at a client site where they wish to deploy only DCRs to the web site. Someone somewhere has made the decision to take the page generation process away from TeamSite. Instead they want to use Apache Cocoon to render pages, based on XSL. This seems a bit rediculous to me. Does anyone have any comments regarding this?

A more specific question also. They want to structure the folders so that files are easier to find within TeamSite. Currently because they are structured under templatedata within their categories, they find it hard to find their files. Would the best approach to this be to generate XML files into a folder structure in the root of the area? Just like what is done with websites that have pages generated by PTLs.

Find more posts tagged with

Comments

Migrateduser

DCRs escape and nest data in funny ways leading to very long XPath statements and other clutter in the XSL. XSL does not have all of the programming logic features that you may want - you may find that it is a limitation on what you can do. Plus if you change the DCT/DCR structure you would also have to change the XSL. I would strongly suggest generating XML files from the DCRs in a folder structure that users are more happy with.

If you are using VFE be sure to configure it for XHTML.

herald10

How about generating symbolic links for those templatedata folders so that they can be easily accessed from XSL.
I am not too sure about this either... but i guess it might work.

PaulW

Thanks for your comments. But if you change the DCT, you would have to generate a different format XML file and then change the XSL anway, wouldn't you? I do agree that the XML paths could be a pain in the ....

Migrateduser

It depends on the scope of the change. Sometimes you change the DCT just to change the UI (such as putting containers around things). Then you would only have to change the TPL that generates the XML to look in the container. For other kinds of changes (new data elements, etc.) you might have to change the XML and that would mean DCT, DCR, PT and XSL changes. I guess that makes your problem worse. To avoid this I generally try to make the XML and XSL formats as generic as possible - for instance instead of creating a relatedLinks element I would create a references element with a type attribute, then if you later add downloadable files you can use the same XML/XSL fragments. XSL can generally be written in a more generic way than TPL - even if something is expected to occur only once the code can loop so if a container becomes a replicant the XSL does not need to get updated. I can't give good specifics off the top of my head, this is just my general recommendation.

XSL is also much more maleable and easier to validate - you can validate it against a DTD, you can download XML and compile it with XSL in offline tools such as XMLSpy, and I think because there's no Perl there's less chance of syntax errors getting into production. Once you start trying to loop over an item nested in a replicant within a replicant in Java you may determine that the only way to work with DCRs is with TPLs.

Migrateduser

I have one other comment on this subject. Personally I think a front-end system should never be designed around the constraints of the back-end system. If you think of the website and the CMS that feeds it as separate components you probably don't want to use vendor-specific technology (DCR XML format) on a standalone system (the website) - if you ever replace the CMS you would not want to have your new CMS write XML in DCR format or rewrite all the XSLs to deal with the new format. I understand it's a theoretical argument because once an enterprise system gets in it's rarely replaced, but it is at least worth considering in making this decision.

Bowker

I'm in agreement with the use of XML to generate the pages 'just in time' for the end-user. I also agree that using DCR format on the web server may not be the best idea.

If you use XML on the server then it is way easier to share content between pages and even between sites. It is also easier to make formatting changes to one xsl document and push that out to the server than regenerating 10, 100, 1000, ... documents and pushing all that out.

Using XML to generate the pages via XSL also allows other areas in the organization to utilize that same content however they want. They don't need to be TeamSite users and mess with generation of pages... However, I would suggest reformatting the DCRs into non DCR-XML for the reasons others have stated.

PaulW

In one instance, I have a News category. there are two output for this category. A single XML file for each news article, along with a master XML file with all news articles. The users want to store all XML files in TS in the web server folder structure so they are easier to navigate. And for me that is good because I can make the deployments simpler.

So my question is:
1) Should I store the DCR in a DCR format in templatedata, and then use to presentaiton templates to generate the XML files in the web folder structure?

2)Or should I Store the DCR as XML and then generate the News Article List XML file based on the XML, and just generate an unchanged copy of the DCR XML file into the web folder structure?

Bowker

I would suggest keeping DCRs in DCR format and generate XML from those in the web folder and deploy from the web folder. (Personal opinion)

You seem to have more options on layout of the XML and the folder/file structure if you do it that way.