cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michel Lehon" <>
Subject Re: xBug -Reply
Date Thu, 20 Jan 2000 15:22:11 GMT
That would indeed be a wonderful showcase of what Cocoon and XSP can do.
It would also be a good teaching tool for everyone (me included)
+1 (Even if I don't have rights to vote).

I hope there will be much most discussions about the evolution of this
project, since it could be used to grow the number of people 'educated' to
the core Cocoon technologies.

Data Warehousing and Web enablement.

----- Original Message -----
From: Ricardo Rocha <>
To: <>
Sent: Thursday, January 20, 2000 15:52
Subject: RE: xBug -Reply

> 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
> > 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
>     to nested, structured elements, etc, As a rule, resulting tag names
>     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
>     (reopen, verify, close). For operations returning values ("function"
>     methods), express resulting values in terms of tag(s) specified in
> 5) Derive a DTD/XSchema extension for dynamic tags defined by the
>     above identified operations. As a rule, resulting tag names here will
>     _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

View raw message