Re: Managing Java applications in CMS

(Argh, this is my second repost. I don't know why this doesn't appear on 
the list. sorry if you get duplicates)

Ethan Michaels wrote:
> I've tried posting this a few times now. Apologies if more than one copy 
> appears.
> 
> At our shop we are using J2EE to build Web apps. For example, we have 
> signup forms for some of our various programs implemented as servlet/JSP 
> applications. We will soon purchase a CMS. I am wondering how those two 
> things are going to go together. The way we set up Java applications is 
> to package the whole application into a ".war" file (.war : "Web 
> archive") and place that into the anointed directory of JRun. Every part 
> of the application, servlets and JSP files, images, etc., is inside this 
> .war file.
> 
> This mode of operation does not seem like it would work in a CMS 
> environment. From what I understand, a CMS stores all these page 
> elements in a database and assembles them either at run time or in 
> advance. But you can't break a .war file apart and store the pieces in a 
> database and still have a working application.
> 
> There are many Web apps and they are scattered throughout the site. So 
> what we really need is to manage their page elements at the same time 
> that we manage the elements of our HTML pages.
> 
> Any insight or information about this issue would be greatly appreciated.

When we began the design of our CMS product a year ago, we anticipated 
this and based our architecture around the upcoming portlet spec (what 
we did was to copy the IBM WPS 4.1 API which was the foundation for the 
Portlet API, JSR168). By doing this, and by writing ALL our own 
HTML-generation code as portlets using this API, we get native support 
for exactly what you're asking for.

When you buy our CMS you'll get a bunch of portlets we've written which 
do texts and fonts and navigation and such. Stuff related to CMS. Then 
you can deploy your own WAR file, and either implement your own portlet 
or use a wrapper portlet which simply does an include of your 
application, and then embed that into any page, just as you would with 
any of our own portlets. Your own portlets also show up integrated in 
the admin UI for the site, so there's really no way for the admin user 
to tell what are bundled portlets and what are custom ones. Because of 
the extremely loose and easy integration this provides it's really an 
excellent way to do it.

I just finished the first round of converting our internal API to the 
public draft of the Portlet API, and also all the portlets we bundle, 
and it was very easy to do, especially the portlets which were written 
as servlets(/JSPs) which used a generic include-portlet.

I expect that this is how all major Java CMS/portal vendors will allow 
custom extensions within a year from now. The others I expect to either 
die, or become even more proprietary in order to survive.

regards,
   Rickard


--
http://cms-list.org/
more signal, less noise.