the Easy framework for Agile development with Oracle WebCenter Sites
AgileSites is a framework for Oracle WebCenter Sites that changes the rules of the game in Fatwire/Sites Development.
It modernises Oracle WebCenter Site development providing a layer that introduces a lot of features allowing development in a modern, easier and agile way.
The inspiration of the framework are modern and agile web frameworks like Ruby on Rails or Play! Framework.
This framework is opinionated. It is built based on the following assumptions, or opinions if you prefer (incidentally those opinions are very similar to those advocated by the Agile Development Moviment):
If you disagree with those opinions and think the traditional way of working is just fine, then maybe this framework is not for you.
While changing all the rules of the game, it tries to play fair with Oracle Support rule.
As a result you need not to worry of incompatible changes would break the site, since they would affect any other site.
The framework is a fully documentation-compliant website implementation.
AgileSites is a framework for Oracle WebCenter Sites designed with the following goals in mind:
In short AgileSites scale and speed up development with Oracle WebCenter Sites.
Here is a list of what it has to offer.
WebCenter Sites api is pretty old, sometimes ugly and inconsistent.
Furthermore it is offering too many options, resulting in a confusing api, The documentation and the API is not guiding the developer to follow best practices.
A new, simplified, consistent API is offered. This API hide many of the complexities of the Fawire API, like the different way to access basic and flex attributes.
The goal is to provide 80% of the functionality with 20% of the complexity. However, all the existing WebCenter Sites is kept accessible and available, and can be used if required.
A WebCenter Sites website is typically very complex to deploy, since it is comprised of many different components: library jars, customization jars, css and javascript files, CSElements, Templates, database tables and some content that must be always present.
The system is provided from the ground up with an automated build system that performs all the step for the installation and update. Everything is kept in source form and can be deployed in an unchanged blank system.
A whole site can be install a new system with 2 commands:
wcs-setup before starting the application server, wcs-deploy after starting the application serverThen a site can be updated with a single command (wcs-deploy) You do not need to restart the application server except once, the first time, when installing the core.
Rarely a project exists in a vacuum, so if you decide to give a try to this framework, you want to be able to keep your existing work and not having to rewrite everything.
The framework is totally compatible with any existing project. It implements template logic in Java, but templates are called by standard JSP, so you can freely mix framework managed templates with existing templates.
You can even write templates partially in JSP and partially in Java using the entire hot deploy infrastructure of the framework.
Continuous Integration a key practices in Agile development.
Every developer should work in isolation in his own machine but when many developers are working at the same time, they should commit to a version control system that will rebuild and run the full test suite continuosly.
Because of the limitations of the CMS, usually developers share a common development environment and rely on this for working as a team. This practice has a lot of shortcomings, including periods of unavailabilty of the shared environment because of some mistakes, conflicts in accessing the same template or definition , inability to work without a working internet connection and so on.
The entire framework is built in order to enable Agile development practices.
Since building the site is pretty easy from a single source, every developer can get a development environment working in his local machine quickly and easily, so there is no need to share a development environment.
Since there is a build and writing tests is easy, and a version control system can be used, every developer have just to commit his changes to the version control system
Using a standard Continuous Integration server like Jenkins is just a matter of:
Coding in JSP with WebCenter Sites has the advantage that you can see immediately the result without restarting the application server.
Traditionally, when coding in Java instead a major hassle is the requirement to restart the application server to see the code change.
The framework features hot deploy as a key feature. After any code change, a jar is automatically built and copied in place, and the code is picked up immediately. No need to restart anything.
So you have the advantage of being able to use full java without losing the immediate gratification of seeing the result without any delay that usually breaks the development flow and is a productivity killer.
The choice of development tool usable with WebCenter Sites has been traditionally very limited. Traditionally you have to use the windows-only and limited Content Server Explorer. More recently a few plugins has been made available, all of them Eclipse based, including the CSDT tool.
But if you want to use another IDE, or just Eclipse without a plugin (that may be unavailable or incompatibile with your eclipse flavor) you are out of luck.
The application built with AgileSites is a completely standard Java application not requiring any plugin to be edited: just add the relevant jars in the classpath, and a tool to generate the correct classpath and download them from repositories is included.
As a result, nothing else but any java IDE is required, and this can be Eclipse without plugins, NetBeans, Idea or even nothing at all. Compilation, packaging and deploying is included by a command line tool that is part of the framework.
Sites/WebCenter Sites require developers implement templates either using JSP or its proprietary XML based language.
JSP are great for implementing simple rendering logic, and they dynamic, since they are recompiled on the fly. Developers enjoy instant gratifications seeing immediately the results of their efforts.
With those advantages comes many disadvantages. The problem with JSP is that they are really meant to implement simple rendering logic ONLY. A normal Java Web Applications uses also servlet as controllers, and very often MVC frameworks like Struts or Spring MVC to better organize the code.
In Sites/WebCenter Sites unfortunately JSP is the only mean to develop code, unless you write an extensions jar to add to the webapp, then you deploy it and restart the application server.
Since restarting the application server is slow, most developers end up writing complex logic directly in the JSP, writing JSP that are almost all comprised of Java code. This practice has many shortcomings.
You can use a JSP in WebCenter Sites as a CSElement and call it from another JSP, but they are very cumbersome to use.
Alternatively, you can write your code in a Java class, deploy it in a separate jar, then restart the application server before using it. This is very cumbersome in the development process.
Second, the syntax of JSP is frankly ugly and unreadable. Indentation is very difficult, and often you cannot indent at all to avoid generating tons unindented HTML (that must required to be readable too).
Third, WebCenter Sites is complicating things because the API can often be invoked only through the tag, so you end up switching from java to html and back only to call an API through a tag.
Many projects end up with a lot of Java code inside a JSP, with a lot of code copied and pasted between JSP, getting a large, unmanageable amount of spaghetti code with lot of repetitions.
This is not entirely a WebCenter Sites fault but definitely the limitations of JSP encourage those bad practices.
The fundamental feature of this framework is allowing developers to write templates directly in Java, and providing APIs to render the view from an unchanged HTML (the typical HTML that you receive from web designers).
Since accessing to the content model in WebCenter Sites is usually done using JSP tags, a specific API has been developed to provide easy invocation of JSP tags directly in Java.
To keep the Agility of development using JSP, all your code is stored in a jar that is dinamically redeployed when you change it, so there is no need to restart the application server. You keep the instant gratification of JSP, but you can write ordered, clean Java code, splitting it in multiple classes and reusing code without limite call-elements.
You have all the Java power at your finger tips. However, templates are still templates, and they are invoked by a JSP. The stub code to generate the JSP is managed automatically by the framework so you don't have to worry of it.
A common problem in WebCenter Sites development is that templates do not implement a Model-View-Controller pattern.
Instead, a template is just a JSP where you mix the rendering logic (view), the content reading logic (model) and some specific business logic (control)
The AgileSites framework enables you writing your code in Java, not in JSP.
Each template now has a corresponding class that acts as a controller.
A specific API to define the content (model) and retrieve it, is provided, separating the model from the controller.
Furthermore, also the view is kept separated, and in its original form: the view is indeed the original HTML as provided by web designers.
Developers write all the template code in plain Java, implementing a controller that collect data from the model and place it in the view as needed.
In any large web development project, web designer are different people from web developers, since different skills are required.
Usually Web Designer deliever their work as a set of html/css/javascript files that must then used by web developers to implement the web site in the CMS.
Major problems arises when Web Designers update the web design, since at every update developer have to track down html changes and update code following the changes in the design.
The framework allows developer to use unchanged original HTML files. A specific API, using jquery-like CSS based selectors allow to pick specific pieces of html, replace with content and render them without having to mix code and HTML. This way web designer can freely update the html and the CSS and, as long as id and classes are kept unchanged, there is no need to change the business logic code.
Deploying code though publishing templates is error prone, does not capture real dependencies in code and is very hard to track.
The deployment of an AgileSites project is a single jar containing both source code and html resources. The jar is automatically packaged and deployed just copying it on his final destinations. Changes are picked when the jar is deployed.
Since all the code is a single jar, deploying a site is only a matter of copying a jar in place, and it is possible to compare the complete code deployed for a site just comparing the deployed jar.
If you pick the framework, you may want to keep getting support from the vendor, and using this framework should not be a reason to lose support.
Furthermore you want to use all the available feature of WebCenter Sites without being limited in any way.
AgileSites does not change WebCenter Sites way of operate in any way. Templates are still invoked using JSP, and JSP code is standard Java code, so nothing is different from standard practices.
The entire hot deploy api is actually a standard feature of Java that exists since Java 1.0: it is implemented using the standard class loader used for applets. Everything else is provided either with java classes that extends existing api (but don't change it) and a standard external build tool that packges your code and deploy it.
Finally, the asset model update is implemented using standard WebCenter Sites Elements and SiteEntries, invoked through the Catalog Manager.
In conclusion, all the framework is a layer built on top of standard WebCenter Sites and nothing is "invalidating your guarantee", except you may not ask support for the specific framework to the Vendor. Support for the framework however is available from us.
Agile programming mandates you write tests for every features you implement.
In addition to unit test, is is important to be able to perform integration test in an automated way.
Unfortunately, with WebCenter Sites templates live inside the CMS and are almost impossible to test: they can be called only through HTTP and often not directly.
Templates depends on the current content model so you cannot reproduce their behaviour unless you initialise the whole content in an expected way, that can be a lot time consuming.
Since all the templates are implemented in a Java class, they can now be tested outside of the CMS. Furthermore, you can simulate the behaviour of the CMS outside of it using a set of provided mocks.
This makes very easy to write unit test. Furthermore, the framework integrates content impor and the tool selenium. This make easy to write also integration test to be used in [[continuous integration|Feature-Continuous-Integration]].
Developers cannot really use a version control system with standard WebCenter Sites since all the templates are stored inside the database and it may required to version control database records, that is not easy (if possible at all).
A limited solution is using internal WebCenter Sites revision tracking, but that is not a real version control system. It is more suitable for revision tracking content, not code. It lacks many of the features of typical VCS, like merging changes from different developers and allowing concurrent development.
Furthermore you do not have a real source code of your templates, since they are actually stored inside the database. Comparing versions is pretty difficult (you have to manually export templates, compare then then compare manually database records storing metadata about the templates).
The framework keeps everything in source form in Java code, including metadata for templates. Developers work entirely outside of the CMS, then they update metadata and deploy code with a single command, without having to restart the application server. The development lifecycle is pretty fast.
However, since everything is still in source format and not kept outside the CMS, it can be revision controlled, shared, merged and tracked using any standard version control system, either subversion, git, mercurial or proprietary systems.