cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ricardo Rocha" <rica...@apache.org>
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
    bug(s)).

1) Retrofit a state model from Bugzilla's "Bug's Life Cycle". Identify
    initial state, valid transitions, events triggering transitions,
processes
    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
(assign-to,
    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
    _verbs_.

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?

Ricardo


Mime
View raw message