Starting a conversation: OO, CMS's, Zope, open source

[Justin Fagnani-Bell <ju...@paraliansoftware.com>]

Hello everyone,

   I have been working in Cocoon for a couple of years now and have 
built up my own web-app framework over time. It uses Cocoon, but like 
Cocoon in many ways replaces Servlets by handling all incoming 
requests, my web app in some ways replaces Cocoon by handling all 
requests into a single pipeline. It's based very much on OO principles 
and uses a SQL backend to store objects.

Here's the ting though; since I've created this in a vacuum, I don't 
know if it's good design or not. It's been a lot of work, and sometimes 
I feel like I might be wasting my time by not just doing things the 
standard cocoon way (I know there's many ways to do things in Cocoon, 
but I mean with XSPs, aggregators, multiple pipelines, etc). On the 
other hand it makes sense to me and feels right.

I'd like to start a discussion on design principles in web apps. Maybe 
someone will talk me out of the way I'm doing things. Maybe some people 
will like it. I've also been wondering if I should open source it or 
not.

Here's the basic concepts:

The web application is based on an object tree. All objects have a 
name, and URLs point to a particular object, though the hierarchy of 
the tree. For example http://mysite.com/section1/chapter2/page1/ refers 
to the object named page1 that is a child of the object chapter2, 
etc... The closest I've seen another web app come to this is Zope.

The database has an objects table that stores the type and the name and 
links for building the object tree. it's basically just a hierarchical 
db built on a relational db. (I question this setup a lot, but I don't 
have any experience with OO databases). Each object in the database is 
represented by a java object, which is kind of like a lightweight 
Cocoon Generator and Action rolled into one. The java classes have a 
method to generate their XML representation and call that method on 
their children.

So the above URL, with real simple java implementations would generate 
XML that looks a little like this:

<section name="section1">
   <chapter name="chapter1">
     <page name="page1"/>
   </chapter>
</section>

that's leaving a lot out, but it gives an idea that the XML is nested 
and represents the actual nesting of the objects. Objects can have 
attributes as well, and the IDs are printed too. This is the output of 
my generator. The transformers are the standard Cocoon ones, but I 
always use an XSLT transformer and have wired it so that an object can 
choose what stylesheet to use. There's all kinds of other stuff that 
makes it a usable system, objects can control what other objects are 
printed by including them, they can have actions, they can generate 
different xml based on extension, or a concept of a view.

The java classes are generated from xml files that are a lot like XSP. 
These files are sort of a combination of Model, View, and Controller. 
There's a schema section describing the attributes and content, there's 
a views section which is similar to XSP, and there's an actions section 
with is like a XSPAction. When you drop one of these files in the new 
type becomes available to the web-app editor. The editor is the 
graphical front end to the system where you can assemble the object 
tree and edit the object properties. I'm working on editing the styles 
too.

Well, that's an overview. I have to think that other people, besides 
the Zope guys, have thought about or tried something like this, but I 
can't really find anything out there even though Java seems very well 
suited to this. That's why I wonder if my concept is flawed in some 
way. I've used it in some live sites, but small ones, so I don't know 
if it scales. I had performance issues at first, but implemented some 
caching that helped.

So if anyone has any comments or opinions on this stuff I'd love to 
hear it. I know there's a lot of CMS systems based on Cocoon already. 
Is there interest in another one?

Thanks,
   Justin


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org

Re: Starting a conversation: OO, CMS's, Zope, open source

[Justin Fagnani-Bell <ju...@paraliansoftware.com>]

Andrzej,

   Thanks for the reply, it's been a busy week, therefore the delay in 
getting back to you.

>> I'd like to start a discussion on design principles in web apps. Maybe
>> someone will talk me out of the way I'm doing things. Maybe some 
>> people
>> will like it. I've also been wondering if I should open source it or 
>> not.
>
> <snip the design overview>
>
> The issue I see is that design never lives in a vaccum.  To really 
> comment on
> a design you have to know what problems it is trying to address.
>
> So, with that, what problems is your software trying to solve,

Ideally I want a system where a non-programmer can assemble a fairly 
complex web app by graphically assembling pre-built components. I know 
this doesn't really describe a particular problem.

A lot of this design has come from my experience when I was developing 
web based training. WBT is mostly content, with some interactivity like 
quizes or a simulation. The content breaks down into a nice object 
model (ie. course -> section -> lesson - > page) and each type of 
content is displayed differently. Somehow writing course.jsp, 
section.jsp, etc... so that you could have urls like 
"something.com/course.jsp?id=1" never seemed right. It actually becomes 
a problem when you're reusing your code for a project where they have a 
different course layout. A customer might use course -> module or test 
-> section -> chapter. Being able to arrange the content in arbitrary 
ways seems better.

>  and what unique features does it provide (compared with other 
> solutions based on Cocoon, Zope, etc)?

I truthfully need to look more into Zope. I don't know much about it 
beyond that it's based on an OO concept and that objects are authored 
in python. I know it has a standard graphical editor for assembling 
site, which is pretty similar in some ways to mine.

The feature I like most over Cocoon is that the XML is generated by 
traversing the object tree and reflects the structure. each object only 
need to generate it's own XML. If you change an object definition it's 
reflected everywhere that uses that object.

Some features (current and planned)...

graphical editor
object definition files can be dropped in and used in the editor 
without any configuration
object-level permissions with users and groups, like UNIX filesystems
easy content reuse by linking to objects in a library

I feel like I should describe how I'm building my current project, but 
I don't have the time now.

> It also seems that you are mixing up different strata of "design".
> Application architecture, with is moving towards SOA principles, and 
> code-
> level design which can be based on OO.

I don't see how using an OO architecture keeps you from using SOA. The 
project I'm working on now is going to use SOAP to interact with a 
authorization server. An object in my system will be responsible for 
the communication between my app and the web service. In this way SOAP 
is just message passing between objects. A normal HTTP request is a 
message passed to an object; a request for it's content. I'm looking at 
everything as messages passed to objects.

It also preserves SoC. Programmers author objects. Site administrators 
or programmers can build the web site with the editor, and graphic 
artists can handle the XSL/HTML/CSS end. Since XSL isn't very well know 
out there (in my experience) I often use a two tiered XSL 
transformation. The first one transforms to a very generic XHTML files 
that's suitable for transforming again to the final HTML or sending to 
the browser with CSS.

> It's usually a mistake to try to use OO at the overall architecture 
> level.

Why is this? I do see that it doesn't have some of the flexibility of 
the sitemap, which acts like a declarative programming language in many 
ways, but it's very consistent and easier to understand.

I'm thinking of it as OO at the content level. Most sites are mostly 
hierarchal content. Sections of a site, articles with in sections, etc. 
I think a files system is a actually great way to layout a site because 
it's easy to see that folders and files actually relate to the URL. Of 
course abstracting the URL space is a nice feature of Cocoon.

> Just some initial thoughts to kick of your discussion.
>
> Andrzej Jan Taramina
> Chaeron Corporation: Enterprise System Solutions
> http://www.chaeron.com
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org

Re: Starting a conversation: OO, CMS's, Zope, open source

[Andrzej Jan Taramina <an...@chaeron.com>]

Justin:

> I'd like to start a discussion on design principles in web apps. Maybe
> someone will talk me out of the way I'm doing things. Maybe some people
> will like it. I've also been wondering if I should open source it or not.

<snip the design overview>

The issue I see is that design never lives in a vaccum.  To really comment on 
a design you have to know what problems it is trying to address.

So, with that, what problems is your software trying to solve, and what 
unique features does it provide (compared with other solutions based on 
Cocoon, Zope, etc)?

It also seems that you are mixing up different strata of "design".  
Application architecture, with is moving towards SOA principles, and code-
level design which can be based on OO.  It's usually a mistake to try to use 
OO at the overall architecture level.

Just some initial thoughts to kick of your discussion.

Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org