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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to