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
|