You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Michael Glenn <mi...@mglenn.com> on 2000/01/20 17:24:59 UTC

xBug related XSP Questions

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 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