cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ricardo Rocha" <>
Subject RE: xBug -Reply
Date Thu, 20 Jan 2000 14:52:44 GMT
On Jan-20-2000 John Morrison wrote:

> OK, this is what I plan to do.
> 1. In collaboration with you lot, work out what it is we want the bug
> tracking system to be. What fields are stored, using what DTD,
> providing what functionality etc. I have ripped off the input forms
> for both the Mozilla and Apache bug systems and will use these as
> the starting point for discussion.
> 2. Prototype the system using something quick (for me) like FileMaker Pro,
> running on one of my servers. With the aim that a useable system will be
> up and running (and doing it's job) asap.
> 3. in the meantime, learn SQL etc. and get on with the Cocoon version.

Advocating XSP for this purpose (again), and asuming a purely database-
driven approach (as opposed to an object-oriented one) I'd suggest the
following road map:

0) "Retrofit" Bugzilla from the forms you ripped off by applying
    entity-relationship modelling. Identify entities (bug, platform,
    servlet engine), domains (status, priority, severity), attributes
    (summary, keywords) and relationships (assigned-to, dependent

1) Retrofit a state model from Bugzilla's "Bug's Life Cycle". Identify
    initial state, valid transitions, events triggering transitions,
    associated with events, etc

2) Derive an SQL database schema from this entity-relationship
    model. Rules for this transformation are straightforward: entities
    map to tables, domains to check constraints, attributes to columns,
    relationships to foreign keys and intersection tables, etc.

3) Derive a DTD or, better yet, an XSchema for the static tags implicit
    in the entity-relationship model. Transformation rules are similar to
    those for a DB schema: entities map to elements, e-r attributes to
    nested, textual elements or XML attributes, some relationship types
    to idrefs, domains to XML attribute values, mandatory 1:N relationships
    to nested, structured elements, etc, As a rule, resulting tag names here
    will be _nouns_.

4) In addition to "normal" SQL DML operations (INSERT, UPDATE, DELETE)
    identify operations (methods) defined on entities in the model
    change-priority) as well as those defined by the state transition model
    (reopen, verify, close). For operations returning values ("function"
    methods), express resulting values in terms of tag(s) specified in (3).

5) Derive a DTD/XSchema extension for dynamic tags defined by the
    above identified operations. As a rule, resulting tag names here will be

6) Write XSP libraries implementing the dynamic tags identified in (5)

7) Write XSLT stylesheets required to transform static tags identified
     in (3) into presentation-oriented markup (e.g. HTML)

8) Write XML form and XSP pages providing the user interface

I know there's much more detail to this than sketched above, but
this is a start:

    We need a formal methodology for building dynamic
    web applications with Cocoon!!!

I'd prefer to use UML class and state diagrams for conceptual
modeling (as opposed to entity-relationship modeling) if we want
to make our solution object-oriented. Among the obvious benefits,
this approach allows us to delegate database persistence to technologies
such as Castor JDO and/or EJB. I feel entity-relationship modeling is ok
for strictly database-driven applications, though.

What do you guys think?


View raw message