cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From PNar...@directsourcing.com
Subject RE: xBug -Reply
Date Thu, 20 Jan 2000 14:51:08 GMT
I say +1^0 to Ricardo's plan. This way we will have a good system working on
XSPs.

Pankaj

> -----Original Message-----
> From: Ricardo Rocha [mailto:ricardo@apache.org]
> Sent: Thursday, January 20, 2000 9:53 AM
> To: cocoon-dev@xml.apache.org
> 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 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