You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Jerm <je...@media.demon.co.uk> on 2000/01/20 12:52:59 UTC
xBug
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 related XSP Questions
Posted by Michael Glenn <mi...@mglenn.com>.
Ricardo Rocha wrote:
>
> On Jan-20-2000 Michael Glenn wrote:
[deletia]
> > Where would the code to add the retrieved information into the database
> > reside and how would it be referenced?
>
> XSP follows a layered (TM by Stefano Mazzocchi) approach where
> libraries are applied in sequence so that the "output" of one library
> becomes the "input" of another, not unlike the good ole' Unix pipeline
> concept.
>
> Thus, xBug could well be expressed in terms of Donald's upcoming SQL
> XSP library.
>
> Violating the sacrosanct principle of wrapping all business logic as
> Java Beans and also improvising a SQL library syntax Donald is sure
> to denounce as ridiculous, the following example illustrates the point:
>
> 1) "User" XSP Page:
>
> <xbug:add-bug>
.
.
.
[deletia]
BANG! That cleared up the confusion for me, thanks Ricardo. I appreciate
all the effort as well. The more examples the better. The value of XSP
is growing on me. :-)
--
Michael Glenn, http://www.mglenn.com
Principal and Web Architect
North 49 Design
http://www.north49design.com
RE: xBug related XSP Questions
Posted by Ricardo Rocha <ri...@apache.org>.
On Jan-20-2000 Michael Glenn wrote:
> I starting to see how this would work, but my understanding of XSP is
> still very rusty. I'm hoping you can confirm and clarify my analysis
> then perhaps I can be of some use. Using this as a real world example
> will help me to grasp the XSP concept.
> <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>
> I understand <xbug:add-bug> to be a library tag as well as
> <xbug:platform> and <request:...>, correct?
> Some of this code resides within the XSPRequest library, referenced
> using <xsp:page>, correct?
Yes. In general, each library defines its own namespace (though
this restriction is likely to be lifted in the near future).
Thus, the example <xbug:> namespace would be supported by
the corresponding xBug library.
The same is true of <request:>, which is one of XSP's built-in
libraries. XSP provides libraries for all servlet objects: request,
response, session, servletContext and Cookie. There's also a
(demo) Util library containing general-purpose file, URL and
date dynamic tags.
> Where would the code to add the retrieved information into the database
> reside and how would it be referenced?
XSP follows a layered (TM by Stefano Mazzocchi) approach where
libraries are applied in sequence so that the "output" of one library
becomes the "input" of another, not unlike the good ole' Unix pipeline
concept.
Thus, xBug could well be expressed in terms of Donald's upcoming SQL
XSP library.
Violating the sacrosanct principle of wrapping all business logic as
Java Beans and also improvising a SQL library syntax Donald is sure
to denounce as ridiculous, the following example illustrates the point:
1) "User" XSP Page:
<xbug:add-bug>
<xbug:platform>Linux</xbug:platform>
<xbug:version>1.6</xbug:version>
<xbug:component>XSP</xbug:component>
<xbug:summary>
Error loading generated Java classes after restarting
servlet engine
</xbug:summary>
</xbug:add-bug>
2) <xbug:> Library
<xsl:template match="xbug:add-bug">
<sql:do-insert table-name="bugs" connection="xbugConnection">
<sql:column name="platform">
<xsl:value-of select="xbug:platform"/>
</sql:column>
<sql:column name="version">
<xsl:value-of select="xbug:version"/>
</sql:column>
<sql:column name="platform">
<xsl:value-of select="xbug:component"/>
</sql:column>
<sql:column name="platform">
<xsl:value-of select="xbug:summary"/>
</sql:column>
</sql:do-insert>
</xsl:template>
3) <sql:> library
<xsl:template match="sql:do-insert">
<xsp:logic> {
Connection connection = <xsl:value-of select="@connection"/>;
String sqlText =
"INSERT INTO <xsl:value-of select="@table-name"/> ( " +
<xsl:for-each select="sql:column">
<!-- Warning: generates a spurious trailing comma! -->
"<xsl:value-of select="@name">, " +
</xsl:for-each>
") VALUES ( " +
<xsl:for-each select="sql:column">
<!-- Warning: generates a spurious trailing comma! -->
"'<xsl:value-of select=".">', " +
</xsl:for-each>
")";
Statement statement = connection.createStatement();
statement.execute(sqlText);
} </xsp:logic>
</xsl:template>
After applying libraries, the resulting code would look like:
Connection connection = myConnection;
String sqlText =
"INSERT INTO bugs ( " +
"platform , " +
"version, " +
"component, " +
"summary "
") VALUES ( " +
"'Linux', " +
"'1.6', " +
"'XSP', " +
"'Error loading generated Java classes after restarting
servlet engine'" +
")";
Statement statement = connection.createStatement();
statement.execute(sqlText);
Again, this is _NOT_ the idea!!! I've used this form because
of its relative simplicity.
I'm preparing a document about library authoring where
the "true path" is introduced. The above example is too
ASP-like, :-(
ASPers of the world: repent before it's too late! Eschew ASP
and look-alikes, embrace the shining path of true dynamic XML
authoring!! :-)
Ricardo
xBug related XSP Questions
Posted by Michael Glenn <mi...@mglenn.com>.
Ricardo Rocha wrote:
>
> On Jan-20-2000 Michael Glenn wrote:
>
> > FYI, my framework for grabbing input would be something like...
> > All controlled by custom Producer or components of said Producer.
>
> > If someone has a more efficient method please let me know. I'm starting
> > to develop all my Cocoon applications like this and have yet to come up
> > with anything better for retrieving data from forms and storing it into
> > tables.
>
> Risking to appear too insistent, I'd say an XSP-based solution
> is much easier to implement, maintain and extend than developing
> a special purpose producer.
>
> For a more detailed explanation, please see my previous posting
> where I outline an (admittedly crude) methodology for developing
> dynamic web applications in Cocoon
I starting to see how this would work, but my understanding of XSP is
still very rusty. I'm hoping you can confirm and clarify my analysis
then perhaps I can be of some use. Using this as a real world example
will help me to grasp the XSP concept.
Using your previous example...
<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>
...perhaps you can confirm some assumptions of mine.
I understand <xbug:add-bug> to be a library tag as well as
<xbug:platform> and <request:...>, correct?
Some of this code resides within the XSPRequest library, referenced
using <xsp:page>, correct?
Where would the code to add the retrieved information into the database
reside and how would it be referenced?
--
Michael Glenn, http://www.mglenn.com
Principal and Web Architect
North 49 Design
http://www.north49design.com
RE: xBug
Posted by James & Sue Ann Birchfield <js...@home.com>.
I agree. I found it much easier to do the LDAP and
Mail processors over into taglibs. I think you
will find these much easier...
=====================================
James Birchfield
Chief Technology Officer
jmbirchfield@proteus-technologies.com
http://www.proteus-technologies.com
=====================================
> -----Original Message-----
> From: Ricardo Rocha [mailto:ricardo@apache.org]
> Sent: Thursday, January 20, 2000 10:05 AM
> To: cocoon-dev@xml.apache.org
> Subject: RE: xBug
>
>
> On Jan-20-2000 Michael Glenn wrote:
>
> > FYI, my framework for grabbing input would be something like...
> > All controlled by custom Producer or components of said Producer.
>
> > If someone has a more efficient method please let me know. I'm starting
> > to develop all my Cocoon applications like this and have yet to come up
> > with anything better for retrieving data from forms and storing it into
> > tables.
>
> Risking to appear too insistent, I'd say an XSP-based solution
> is much easier to implement, maintain and extend than developing
> a special purpose producer.
>
> For a more detailed explanation, please see my previous posting
> where I outline an (admittedly crude) methodology for developing
> dynamic web applications in Cocoon
>
RE: xBug
Posted by Ricardo Rocha <ri...@apache.org>.
On Jan-20-2000 Michael Glenn wrote:
> FYI, my framework for grabbing input would be something like...
> All controlled by custom Producer or components of said Producer.
> If someone has a more efficient method please let me know. I'm starting
> to develop all my Cocoon applications like this and have yet to come up
> with anything better for retrieving data from forms and storing it into
> tables.
Risking to appear too insistent, I'd say an XSP-based solution
is much easier to implement, maintain and extend than developing
a special purpose producer.
For a more detailed explanation, please see my previous posting
where I outline an (admittedly crude) methodology for developing
dynamic web applications in Cocoon
Re: xBug
Posted by Michael Glenn <mi...@mglenn.com>.
Jerm wrote:
>
> 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 ... ;-)
Jeremy,
I'll volunteer my services to code xBug entities (i.e. issue, category,
etc.) and the respective tables and table functions (createTable,
insert, update, delete). I'd go with John's suggestions regarding SQL
queries and use SQLProducer. Pass along the DTD when you've draw it up.
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?
FYI, my framework for grabbing input would be something like...
All controlled by custom Producer or components of said Producer.
pass HttpRequest object
|
|(fields retrieved by)
|
v
FormGrabber
|
|(place fields into)
|
v
Entity
|
|(insert entity into table)
|
v
Table.insert(Entity)
If someone has a more efficient method please let me know. I'm starting
to develop all my Cocoon applications like this and have yet to come up
with anything better for retrieving data from forms and storing it into
tables.
--
Michael Glenn, http://www.mglenn.com
Principal and Web Architect
North 49 Design
http://www.north49design.com
Re: xBug
Posted by Donald Ball <ba...@webslingerZ.com>.
On Thu, 20 Jan 2000, Jerm wrote:
> 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 dunno, I take some issue with this. Yes, I wrote the current version of
the SQLProcessor (and am working on the taglib version), but I'm not
necessarily the SQL advocate. I think you should only mess around with
storing data in a SQL database instead of in an XML file if there are an
insane number of entities to be stored (more than a few hundred to a
thousand, depending on the complexity of the entities), or if your
commonly performed queries are complex and performance is really critical.
For most things, I'd much rather put the data into an XML file (or a set
of 'em) and use XSLT (and by extension, XPath) to extract and render the
bits that I'm interested in. Writing complex SQL queries, or even worse,
writing logic to write complex SQL queries, is much more painful IMHO.
Furthermore, it's much easier to add, uh, special case data fragments in
XML than it is in SQL. For instance, suppose you decided that each bug
report would be assigned to single designated fixer, but then you ran into
a bug that needed to have two designated fixers. In XML, you'd just add
another <fixer> to the <bug>, but in SQL you'd either have to add a series
of columns to the bug table (e.g. fixer2_name, fixer2_email) or you'd have
to move the fixer information to a foreign table and then put a reference
to the foreign table in the original bug table and then rewrite all of
your queries that reference fixer to do the lookup into the foreign table.
Ick.
Naw, for the number of bugs per project I think we'll have (several dozen
to a hundred?) I can't see any reason to go through the trouble of messing
with SQL. Plus it'd give us some valuable experience working with largish
XML datasets. I wrote SQLProcessor to give myself a bridge to 'legacy'
data, and to access datasets that I simply couldn't work with as straight
XML (e.g. databases with thousands of articles with thousands of words).
Perhaps I am missing some compelling reason to choose SQL for this app
though? If so, I'd love to hear it.
- donald
Re: xBug
Posted by Seth Ladd <sh...@osfmail.isc.rit.edu>.
> 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.
This sounds great. I think the world needs to see Cocoon power a data
driven web site.
Having said that, I would vote that in the meantime, we get a bug system
up ASAP. We could implement one of the many existing bug systems while
the xBug system is being developed. I volunteer to help. I'd just rather
see a short term solution up now while we work on xBug.
Another nice thing about xBug is that we'll finally get Cocoon installed
on xml.apache.org, something I've been looking forward to. :)
Thanks,
Seth