Use Cases

In general, Denina is designed to be used when a full re-code and re-deploy is not desirable. If you have unlimited and instant access to developers for your CMS (or if you are such a developer) and redeploys are instant and pain-free, then perhaps Denina provides no benefit.

What Denina proposes is a "second level" of development -- an editor who brings some level of development self-determination, to the point where they might be frustrated by their development team, or too demanding of it.

In the following situations, the case can be made for a limited, editor-managed development option:

• Static markup integration:
  Some projects have design requirements that are simply more easily implemented by hand-written HTML markup, rather than managed content. Denina provides a link between the editor and external resources -- either local on the file system, or remote over HTTP -- so that static HTML can be retrieved, transformed, and integrated when this makes sense for the project requirements.

• One-off content integration
  There are often odd situations that require integration with an external system. Many times, these situations are completely isolated to one instance ("It would be great if we could display the current weather in Moscow on this one page..."). You simply might not want to clutter up the core codebase with a one-off integration request.

• Temporary, campaign-based content functionality
  Often, organizations want to integrate external resources temporarily for a timed campaign, then cleanly remove that functionality once the campaign ends.

• Intranets and portals
  Intranets are fundamentally about content aggregation -- providing a single location for the reporting of information from disparate systems. Integrating other systems should be quicker and simpler than a full redeploy might allow.

• Migration/legacy code
  Many site migrations have been held up by legacy functionality that the organization didn't have time or budget to re-write. In these situations, the legacy application might be able to stay where it is and be integrated temporarily with Denina until such point it can be re-written into the main codebase.

• Distributed development operations
  Some aspects of a website could be developed by a separate team than the core CMS team, then integrated using Denina. For instance, an application could be written by a different team, in a different language, and hosted in a different environment, then simply added to the site via the Http.Proxy functionality (see HTTP Filters).

• Prototyping
  Editors might want to test functionality on their own before invoking their development team. Denina might give them an option to "rough in" functionality to test the adoption of an idea.

• User indecision
  Sometimes customers just can't make up their minds. Denina gives an option for a second level of development to quickly implement requests...until the customer changes their mind again.