Presentation Layer Technologies on Church Websites?

I know that there are various technologies out there for templating the presentation layer of a web application and keeping it separate from the business logic. If I remember right, Joomla CMS, which the TechLDS website appears to be running, uses CSS, XHTML, and a series of calls to Joomla specific PHP functions that produce the dynamic content. Other PHP applications use Smarty.

In the web application development at the company where I work, we have chosen to use XSLT for our presentation layer. So the business logic and MVC framework of our web application only produce XML documents. Then the resulting XML is passed to an XSLT parser along with the XSL template to use to transform the XML into an XHTML, CSS, Javascript webpage. This way our presentation logic is not only separated from the business logic itself, but is also largely language independent. Right now our code is primary written in Object Oriented PHP5, with a PostgreSQL data model. Theoretically, if we decide that we need to change portions or all of the backend application to use different technologies, as long as those technologies produce the same XML documents, the presentation layer should work with little modification. Of course, practically, different XSLT parsers will likely not work the same.

What technologies does the church currently use to separate its presentation from its business code? Are there other approaches in the works?

And out of curiosity, what do other LDS web application programmers out there use?

jmaxwilson wrote:What technologies does the church currently use to separate its presentation from its business code? Are there other approaches in the works?

And out of curiosity, what do other LDS web application programmers out there use?

Check out Joel's blog (http://ldscio.org) and search for "Java Stack". That may answer some of your questions.

Hey jmaxwilson,

There are a bunch of different solutions that we have in place. I honestly can't claim to know all of them.

So I would say that the one that I most commonly deal with at the Church is a plain separation of information is formatting using xhtml and css. The interaction design team (you can see some of their cool work and ideas at http://www.northtemple.com/ ) cranks out their prototypes in xhtml that has been cut from their png files. In most of the java apps we simply mark up their xhtml with JSF tags using Faclets. This isn't as pure of a solution that your team has produced, but there are areas in which we do something quite similar to what you have described. The apps I mentioned above are more of CRUD style or heavy business logic driven apps.

More of our static content driven sites follow a model that at the surface appears to be very similar to yours. We actually store the content of the site in XML and apply XSL, and then CSS for the look and feel of the site. I could be mistaken (I am not on that specific project), but I believe the beta.lds.org is written this way. It is ran through Vignette, but the principal is very similar to yours.

There is a framework for the Java side of things called Cocoon that is very much like what you have done in PHP. It has been a few years since I used it, but the mechanism then was very close to what you are doing in PHP. The documentation was very poor at the time, but has since gotten much better and I have heard that multiple people locally (not at the Church) have had good luck with it.

Thanks for the information. I've been subscribed to the northtemple feed since early December--it's great stuff!

If you are right, it does sound like the beta.lds.org uses a similar concept to what we are using, although all of our xml documents are produced dynamically on request. I'll have to take a look at Cocoon.

I am the enterprise architect for the new LDS.org site. Its content is stored in an Oracle database. When a page is rendered, the database is queried using software from Vignette. Vignette returns the query results as XML, which is then transformed using XSLT into the presentation you see.

You may be interested to know that the Curriculum department is moving to an XML-based production workflow for the content it creates, which includes the Church magazines, manuals, scriptures, etc. When this effort is completed, content will be created and managed as XML throughout its lifecycle.

Thanks for your explanation, Shellinese. It sounds very similar to what we are doing with PostgreSQL, our Custom PHP5 Application, and XSLT.

It is also exciting to know about the Curriculum move to XML.

Are there any plans to perhaps provide public APIs for some of the data so that independent developers can create custom applications that interact with official church content?

The idea of syndicating Church content has come up, but we aren't doing anything specifically related to that right now. Nevertheless, we will have the technical ability to do so in the near future. In the meantime, look for more and more RSS links on LDS.org.

shellinese wrote:The idea of syndicating Church content has come up, but we aren't doing anything specifically related to that right now. Nevertheless, we will have the technical ability to do so.

I am curious to know why the decision has been made to not move forward with syndicating church content right now. From the outside it looks like a no-brainer. So, not trying to complain, but curious about the logic behind this decision.

I can't speak for the Curriculum department, which owns that decision, but I believe it's a simple matter of priority. There are many, many projects already underway that need to be completed before resources can be allocated to other work.

Just out of curiosity: What are some of the use cases that you and others are interested in that syndication would address?