1 / 15

CMS and You A Love Story

CMS and You A Love Story. The first of a three-part mini series. Mission and Goals. Mission

christian-zurlo
Download Presentation

CMS and You A Love Story

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CMS and YouA Love Story The first of a three-part mini series.

  2. Mission and Goals Mission • “The mission of the web group is to facilitate the timely electronic dissemination of oceanographic information, especially the work of WHOI investigators and students, and support the web needs of the WHOI community.” Goals • Provide web-based tools and applications to increase efficiency and effectiveness of WHOI staff • Enable content owners to manage their web content with minimal technical effort • Convey at WHOI.edu the excitement and breadth of WHOI investigators’ and students’ science and engineering research • Improve visitors’ experience at WHOI.edu and attract additional visitors

  3. Historically… • Whoi.edu is mostly static pages • Most everything needs to be posted by a web developer or a designer • Some dynamic stuff (mostly form pages), but done with older style/code • code hard to reuse w/o maintenance cost • Goals becoming increasingly difficult to meet: we spend an increasing amount of time doing maintenance, when we need to be looking forward

  4. How does dynamic content help meet our goals? • It decreases maintenance cost (our time, their money) • code and design reuse • one change affects multiple pages • Web team doesn’t have to own/manage the content • Spreads out workload. • Encourages standards for designers and developers • for instance, all 40+ live homepage builder sites have consistent look and feel, and are self-maintained. • Conclusion: moving from static pages to a dynamic, database-backed cms system is an ongoing paradigm shift. It will require changes in the way we work, but it will allow us to meet our goals, and will benefit everyone: content owners, designers, developers, and users.

  5. Steps towards dynamic pages There’s been a steady progression in web technologies, with a tendency towards dynamic content. • Initially most pages static • Early dynamic pages usually built as CGIs using Perl • More advances scripting languages improved upon Perl: Cold Fusion, ASP, JSP • “Model 2” MVC architecture uses a scripting language (ASP or JSP) in the templates, and has the templates calling upon reusable components in a framework (most commonly Struts or ASP.NET).

  6. MVC: Model-View-Controller • What is it? • Separation of data (“M”), look and feel (“V”), functionality (“C”) • Why separate? • Data: data can be used by more than one function • Web pages • LDAP • ConnectWHOI • Mailing lists • LAF: quickly disseminate content to multiple displays (mission stmt ) • Web pages • PDAs • Allows for personalization • Functionality: to facilitate quick turnaround in changing technologies & admin. decisions • Authentication schemes • Database storage techniques

  7. Static Site: a mess • Static pages are difficult to manage, and the management issue is compounded as the site grows. Currently we have almost 35,000 static pages.

  8. Templated Sites • In areas of the site where we have large amounts of similar-looking content, a single template can be used to format the display of many pages. • For instance, templates for Headlines, Press Releases, and Obituaries have or soon will replace hundreds of static files.

  9. First pass: Divine • Strengths: strong underlying architectural design • MVC Implementation • Database (Oracle) • Functionality (ContentServer) • Look and Feel (Template Assets) • Weaknesses: • corporate travails (four owners in two years!) • could not change functionality (ContentServer - unchangeable) • hard to integrate with existing systems (LDAP) • difficult to build custom admin apps • unreliable publishing (stage-to-prod) • business logic is stored as DB assets (bad!) • Performance issues • weak support • closed and undocumented APIs.

  10. Why build our own? • We will have control over functionality (“C” of MVC) • Can build to our exact specifications (WHOI is a unique place) • Integrate with any other contexts (LDAP, ConnectWHOI ) • We can reuse the pieces bought with Divine • Oracle • WebLogic • eWebEditPro • Divine design concepts • We can reuse pre-built industry framework standards • Struts • Hibernate • Ant • Jakarta-Commons

  11. Second Pass: WHOI CMS • CMS is a web application running inside of WebLogic • Ideally, each layer is only aware of the layer above and below it (in practice, templates sometimes call the WHOI API directly). • The “stack” of technologies we use: • Templates • WHOI Tag Library • WHOI API • Struts • Hibernate

  12. Architectural Details • Templates: what the user actually requests, they package content in a look and feel. Templates are a mix of HTML, Javascript, CSS, WHOI tags, and bits of Java. • WHOI Tag Library: built by us, similar to Cold Fusion tags, they look like HTML. Make templates more readable by reducing the amount of Java they contain. For example, the <whoi:cs> </whoi:cs> tag creates a connection to the contentService (part of the WHOI API). • WHOI API: the Application Programming Interface we’ve written to encapsulate much of the Java code. Does things like access content in the database, or authenticate users. A typical command would be “saveOrUpdateArticle,” which, surprisingly, saves or updates an article. • Struts: an open-source MVC framework for web applications, upon which our API is based. The WHOI API is built by extending the classes (programs) that come with Struts. • Hibernate: an open-source object-relational mapping tool simplifies the way Java interacts with the database, and adds flexibility.

  13. Third Pass (and 4th, and 5th...) • Continue to build up library of reusable modules (calendaring, etc.) • Build our own tag library. Have just started this (we’ve got one tag! woohoo!). Once we have a larger selection of tags, it will further encapsulate commonly used code, and make templates more readable. • Improve performance (it’s ok now, but can be further optimized) • Once “content” is being managed, we’ll be free to attack problems we haven’t been able to address at all in the past: real time data use, etc.

  14. How It Changes How We Work • Communication between team members is essential -- separating functions is more efficient, but requires more communication. • Need to plan builds, i.e., the way we move new code to production will change. On the bright side, we won’t be moving much content to production at all – content owners will do most of that. • Related to above, we will need to test more in development – it’s now an application, rather than a collection of unconnected files. • Once the CMS is in place, we’ll be free to work on interesting new problems, of which we have a never-ending supply – the ultimate goal is that we all do less drudge work and more creative work.

  15. Further Info • WHOI API documentation: http://ragnarok.whoi.edu:7001/docs/ • Struts: http://struts.apache.org/ • Hibernate: http://hibernate.org/

More Related