You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by John Morrison <jo...@experian.com> on 2000/01/20 13:49:39 UTC
xBug -Reply
I don't know much about how to get the data _into_ a db, but the
structure of the db should be quite easy. Can't you use the SQL
producer + xsl stylesheets/transformations to get the data out?
>>> Jerm <je...@media.demon.co.uk> 20/January/2000 11:52am >>>
Dear All,
I have been in discussion with Stefano over the last couple of days,
about
building a Bug Tracking system for Cocoon, in Cocoon.
After going over various ways of handling this, we decided that the only
technique that really makes any sense, is to store bugs in an SQL
Database.
I am offering to build the project, but the first problem is that I have never
used SQL before .... consequentially, it will probably take me longer to
complete this than almost anyone else on this list ... ;-)
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.
I'll be working on this part-time.
My desired outcome includes the following:
- A solid bug tracking system that meets our needs.
- An example of how to handle HTML Form submission and DB writing
within Cocoon
- A practical demonstration of the power of Cocoon
- A vast improvement in my Java skills .....
- A framework for building my own remote/dynamically editable sites
So, any comments so far?
Is there anybody out there about to say "I got one of those, I can set it up
in
10 minutes!"?
I will no-doubt be asking lots of basic question, please have patience ...
regards Jeremy
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com>
<http://www.media.demon.co.uk>
<phone:+44.[0].207.737.6831> <pa...@sms.genie.co.uk>
Re: xBug -Reply
Posted by Stefano Mazzocchi <st...@apache.org>.
Michel Lehon wrote:
>
> 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.
Guys,
it's _very_ nice for me to see all of you discussing such things. I also
love when people come to me saying "I don't know SQL, but that's no big
deal", amazing :)
Why? because it means I was right!!! Cocoon is a framework to allow
people that never had the skills or the design patterns to build a
data-driven web site to think that with Cocoon the problems are
someplace else... but also, they totally understand that if you invest
some time learning such technologies, they will be paying off forever.
This whole xBug system is a test, a test to see how ready Cocoon is to
do real stuf. Real web applications.
I was going to propose something like this, but Jeremy had the right
timing...
The evolution of a framework is not clear and the apache.org project has
currently three frameworks "cocoon", "turbine" and "avalon". Cocoon is
the only one that doesn't have a subproject that works inside its
framework... (Turbine has Jyve, Avalon has JAMES)
So we need one and now that XSP are available, like Ricardo says, you
don't need anything else.
Again, Ricardo is totally right: we need design patterns on how to build
xml web apps using Cocoon. And these can be defined only when you test
it on a real life system. The bug database is simple enough to be
handled in a short time and it might well indicate some design flaws
when Cocoon builds something more than a page.
Also, we need to define some "WAR equivalents, some much like the
Servlet API 2.2 does, but inside Cocoon. A way to deploy and install
your web application without too much effort. I'll be open to all
suggestions in this field.
All right, people. Let's this what this baby can do :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Come to the first official Apache Software Foundation Conference!
------------------------- http://ApacheCon.Com ---------------------
Re: xBug -Reply
Posted by Michel Lehon <na...@hotmail.com>.
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.
Michel.
Michel.Lehon@Outwares.com
Data Warehousing and Web enablement.
----- Original Message -----
From: Ricardo Rocha <ri...@apache.org>
To: <co...@xml.apache.org>
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
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
>
>
RE: xBug -Reply
Posted by Ricardo Rocha <ri...@apache.org>.
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
RE: xBug -Reply
Posted by Kevin Sonney <ke...@webslingerZ.com>.
On Thu, 20 Jan 2000, Ricardo Rocha wrote:
> You may want to consider XSP instead of DCP for this. Development,
> debugging and usability are much better.
Hmm. Good idea. I was just thinking about using DCP as a temporary
work-arround until Donald or I can find & correct a difficulty I'm having
with INSERT/UPDATE statements in SQLProcessor.
I like the idea of XSP, though. I *DO* need to learn it anyway. <grin>
--
- Kevin Sonney
kevin@webslingerZ.com
RE: xBug -Reply
Posted by Ricardo Rocha <ri...@apache.org>.
On Jan-20-2000 Kevin Sonney wrote:
> Yup - getting the data out shouldn't be a problem with the SQLProcessor.
> However, there may be an issue with putting data in - DCP might be a
> little better until Donald (or I) can figure out a minor weirdness I'm
> seeing in the SQLProcessor adding stuff to a DB.
You may want to consider XSP instead of DCP for this. Development,
debugging and usability are much better.
As an example of how you could put data in your SQL database,
consider:
<xbug:add-bug>
<xbug:platform>Linux</xbug:platform>
<xbug:version>1.6</xbug:version>
<xbug:component>XSP</xbug:component>
<xbug:servlet-engine>JRun</xbug:servlet-engine>
<xbug:java-version>JDK1.3</xbug:java-version>
<xbug:priority>1</xbug:priority>
<xbug:severity>Critical</xbug:severity>
<xbug:summary>
Error loading generated Java classes after restarting
servlet engine
</xbug:summary>
<xbug:related-bug>1234</xbug:related-bug>
</xbug:add-bug>
The XBug XSP library may easily translate this into an
equivalent SQL INSERT statement that would be further
processed by Donald's SQL Processor XSP library...
Of course, in real-world usage, the above example
would be populated from an Html form, like in:
<xbug:add-bug>
<xbug:platform>
<request:get-parameter name="platform"/>
</xbug:platform>
<xbug:version>
<request:get-parameter name="version"/>
</xbug:version>
<xbug:component>
<request:get-parameter name="component"/>
</xbug:component>
. . .
</xbug:add-bug>
Re: xBug -Reply
Posted by Kevin Sonney <ke...@webslingerZ.com>.
On Thu, 20 Jan 2000, John Morrison wrote:
> I don't know much about how to get the data _into_ a db, but the
> structure of the db should be quite easy. Can't you use the SQL
> producer + xsl stylesheets/transformations to get the data out?
Yup - getting the data out shouldn't be a problem with the SQLProcessor.
However, there may be an issue with putting data in - DCP might be a
little better until Donald (or I) can figure out a minor weirdness I'm
seeing in the SQLProcessor adding stuff to a DB.
As to the structure, Juts tell me what fields you need, and I can whip up
the table definitions in short order.
--
- Kevin Sonney
kevin@webslingerZ.com