You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2000/09/01 14:00:39 UTC
Re: C2 XSP SQL taglib
Per Kreipke wrote:
>
> Donald, Stefano,
>
> > > Interesting. I've been discussing with Ricardo a lot about this and I
> > > could not come up with a reasonable suggestion of something that
> > > required this functionality....
> > >
> > > But I'm open to change this for XSP 1.1 if you provide me with such
> > > meaningful example.
> > >
> > > To me, a compiled time element and attribute names means that you are
> > > looking for semantic troubles because you loose the contract between you
> > > and the stylesheet (unless, the stylesheet was written to use all
> > > possible cases of the result of the dynamic element name).
> >
> > simple example - suppose i want to use the column names of a sql query as
> > the names of the elements, and i don't want to have to type out all of the
> > columns. i might want to do this:
> >
> > <esql:execute-query>
> > <esql:query>select * from department_table</esql:query>
> > <esql:results>
> > <esql:get-columns/>
> > </esql:results>
> > </esql:execute-query>
> >
> > instead of
> >
> > <esql:execute-query>
> > <esql:query>select * from department_table</esql:query>
> > <esql:results>
> > <id><esql:get-integer/></id>
> > <name><esql:get-string/></name>
> > </esql:results>
> > </esql:execute-query>
> >
> > i can conceive of people wanting that feature, and wanting it very much.
> > me, i'd say you get more flexibility using the latter approach, and it's
> > not really that much extra typing, but if i had a fifty column table, i
> > can see where it would be handy.
>
> A concrete example of this would be a XSP script which displays database
> tables in their entirety. I would suggest a common (and more useful) example
> than the first one above is:
>
> <xsp:page>
> <mytable>
> <esql:execute-query>
> <esql:query>select * from <request:get-parameter
> name="table"/></esql:query>
> <esql:results>
> <esql:get-columns/>
> </esql:results>
> </esql:execute-query>
> </mytable>
> </xsp:page>
>
> Passing the table name as an argument generalizes the function. I use
> similar things under IIS/ASP and other platforms to view database tables in
> my browser. Sure, if there was a column that needed interpretation because
> of its type, this wouldn't handle it well. That's when I'd specialize the
> XSP file.
>
> I'd use something similar to this to display the table (without specifics):
>
> <xsl:template match="/*">
> <xsl:if test="position() = first()">
> <!-- header row with column names -->
> </xsl:if>
> <xsl:value-of select="name(.)"/>: <xsl:value-of
> select="."/></xsl:value-of>
> </xsl:template>
>
> I don't think everyone will use Cocoon for externally viewed pages. We may
> be using Cocoon to compose XML documents behind our webserver to be styled
> either at the client or by another process on the webserver. I think the
> ability to use Cocoon in this fashion, with loose 'contracts' between the
> stages in the pipeline, is also valuable.
Hmmmm, interesting concept.
Well, to follow the exact terminology, there is no such thing as a
"loose contract": a contract is either there or not. It's digital not
analog.
But on the other hand, I totally understand what you are saying: in your
sense, a loose contract is something that is based on the "logic" rather
than on the "schema".
This is the interesting concept and, admittedly, I've been blinded by a
"every contract is a schema" anti-pattern.
Ok, I'm convinced... now we can talk about how to implement this in XSP.
Proposals welcome.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: C2 XSP SQL taglib
Posted by Stefano Mazzocchi <st...@apache.org>.
Steve Muench wrote:
>
> Ricardo, Stefano,
>
> | We may also consider XSLT's own use of <xsl:element> where attribute
> | name can take a dynamic XPath expression:
> |
> | <xsl:element name="{@tagname}">...</xsl:element>
> |
> | Since XSP doesn't support XSLT's {...} idiom inside attributes, we
> | may need to do something like...
>
> Did you guys give up on the idea of thinking of XSP's
> as simple-form XSLT stylesheets that use the XSLT extension
> element mechanism? The archives are down at the moment or
> I would have dug up the mail trail from months ago where
> I thought Stefano had come around to this way of thinking...
Yes, I did change my mind on the subject but I still believe that XSLT
should _not_ have simple-form XSLT stylesheets. It's a hack, big time
hack.
> Whenever it seems that there's a need to invent a facility
> already provided by XSLT, then this idea pops back to the top
> of my head.
Oh, totally.
There is clear overlapping between XSP and XSLT and XSLT 1.1 extentions
might end up being _very_ similar to what Ricardo proposed with his
SiLLy language.
Now the question: do we _really_ want to add server pages capabilities
to XSLT?
I've asked Sharon to tell me why XSLT is still called XSLT and not XTL
or something equivalent but nothing about styling... and she said that
it's to avoid turning XSLT into a general language for
transformations...
(which already is, BTW, and almost everybody knows that styling has
nothing to do with semantic transformations, despite DSSSL friends
advocate the opposite)
but then you want to add portable, language abstracted, extentions and
even enforce to _remove_ the notion of transformation with the
simple-form model hack that moves from "transformation" to direct
"generation"...
I'm sorry, but I don't like this and I don't care if we have to include
90% of the XSLT elements into XSP or even invent some more... XSLT
simply is NOT designed for what we want to achieve for language
abstracted XML generation. Period.
BTW, if a technology that is called "eXtensible Stylesheet Language for
Transformations" is able to "generate" non-styled XML content without
performing any transformation, this should tell you something.
And the fact that the XSL WG doesn't even seem to care about this,
doesn't clearly advocate for its use in "real" open environments when we
can avoid it.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: C2 XSP SQL taglib
Posted by Steve Muench <sm...@us.oracle.com>.
Ricardo, Stefano,
| We may also consider XSLT's own use of <xsl:element> where attribute
| name can take a dynamic XPath expression:
|
| <xsl:element name="{@tagname}">...</xsl:element>
|
| Since XSP doesn't support XSLT's {...} idiom inside attributes, we
| may need to do something like...
Did you guys give up on the idea of thinking of XSP's
as simple-form XSLT stylesheets that use the XSLT extension
element mechanism? The archives are down at the moment or
I would have dug up the mail trail from months ago where
I thought Stefano had come around to this way of thinking...
Whenever it seems that there's a need to invent a facility
already provided by XSLT, then this idea pops back to the top
of my head.
______________________________________________________________
Steve Muench, Lead XML Evangelist & Consulting Product Manager
BC4J & XSQL Servlet Development Teams, Oracle Rep to XSL WG
Author "Building Oracle XML Applications", O'Reilly
http://www.oreilly.com/catalog/orxmlapp/
Re: C2 XSP SQL taglib
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 18:51 -0500 01/09/00, Ricardo Rocha wrote:
>Since XSP doesn't support XSLT's {...} idiom inside attributes, we
>may need to do something like:
>
> <xsp:element namespace="http://localhost/foo">
> <xsp:name><xsp:expr>
> "new" + tagName
> </xsp:expr></xsp:name>
> </xsp:element>
or this? :
<xsp:element>
<xsp:name>
<xsp:expr>getTagName()</xsp:expr>
</xsp:name>
<xsp:value>
<xsp:expr>getTagValue()</xsp:expr>
<xsp:value>
</xsp:element>
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@sms.genie.co.uk>
C2 technology
Posted by Gerogi Danov <gd...@comsoft.bg>.
I am reading the document about cocoon2 available on xml.apache.org, and the
part about the "contracts" sounds little strange and obscured...
It's obvious that one html output can be produced in different ways using
cocoon, so will be there some sort of "well written" demo, that would guide
us to use Cocoon in the best way? :)
Re: question
Posted by Giacomo Pati <Gi...@pwr.ch>.
On Mon, Sep 04, 2000 at 11:13:20AM +0300, Gerogi Danov wrote:
> Hi guys,
> As I am reading the sources of the current release of cocoon (1.7.4) and
> wish to contribute some xdocs :), is there any timeline for cocoon2, because
> there is no need of docs for old versions
The need for docs in C2 is much higher that for C1. If you could contribute some docs for C2 that would be cool. The timeline for C2 is first beta release in October (ApacheCon) and first production release for the end of the year. I think the architecture is stable enough to be documented :)
Giacomo
--
PWR GmbH, Organisation & Entwicklung Tel: +41 (0)1 856 2202
Giacomo Pati, CTO/CEO Fax: +41 (0)1 856 2201
Hintereichenstrasse 7 Mobil: +41 (0)78 759 7703
CH-8166 Niederweningen Mailto:Giacomo.Pati@pwr.ch
Web: http://www.pwr.ch
question
Posted by Gerogi Danov <gd...@comsoft.bg>.
Hi guys,
As I am reading the sources of the current release of cocoon (1.7.4) and
wish to contribute some xdocs :), is there any timeline for cocoon2, because
there is no need of docs for old versions
Re: C2 XSP SQL taglib
Posted by Ricardo Rocha <ri...@apache.org>.
Donald Ball wrote:
>
> On Sat, 2 Sep 2000, Stefano Mazzocchi wrote:
>
> > > or we could bite the bullet and add {} expression processing to the
> > > attributes of certain xsp elements. that would cut down on the number of
> > > elements we need to add to the language.
> >
> > Good point.
> >
> > Ricardo, how hard would be to implement such an addiction
{} expression processing inside XSP attributes is scripting
language-dependent.
How easy is it to implement? Fairly simple, I think: for C2,
it involves extending the ProgrammingLanguage interface to add
a string concatenation operator property and changing a couple
of lines in XSPMarkupLanguage to preprocess attributes containing
{} expressions.
> your choice of words betrays your bias. :)
Out of context, this statement looks appropriate for a signature :)
Re: C2 XSP SQL taglib
Posted by Stefano Mazzocchi <st...@apache.org>.
Donald Ball wrote:
>
> On Sat, 2 Sep 2000, Stefano Mazzocchi wrote:
>
> > > or we could bite the bullet and add {} expression processing to the
> > > attributes of certain xsp elements. that would cut down on the number of
> > > elements we need to add to the language.
> >
> > Good point.
> >
> > Ricardo, how hard would be to implement such an addiction?
>
> your choice of words betrays your bias. :)
Touchè, but this was only _one_ of the possible arguments.
If it is simple enough AND people ask for it, then we implement it right
away.... otherwise, we wait a little more to collect more feedback.
Of course, I'm biased toward laziness, what did you expect? :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: C2 XSP SQL taglib
Posted by Donald Ball <ba...@webslingerZ.com>.
On Sat, 2 Sep 2000, Stefano Mazzocchi wrote:
> > or we could bite the bullet and add {} expression processing to the
> > attributes of certain xsp elements. that would cut down on the number of
> > elements we need to add to the language.
>
> Good point.
>
> Ricardo, how hard would be to implement such an addiction?
your choice of words betrays your bias. :)
- donald
Re: C2 XSP SQL taglib
Posted by Stefano Mazzocchi <st...@apache.org>.
Donald Ball wrote:
>
> On Fri, 1 Sep 2000, Ricardo Rocha wrote:
>
> > We may also consider XSLT's own use of <xsl:element> where attribute
> > name can take a dynamic XPath expression:
> >
> > <xsl:element name="{@tagname}">...</xsl:element>
> >
> > Since XSP doesn't support XSLT's {...} idiom inside attributes, we
> > may need to do something like:
> >
> > <xsp:element namespace="http://localhost/foo">
> > <xsp:name><xsp:expr>
> > "new" + tagName
> > </xsp:expr></xsp:name>
> > </xsp:element>
>
> fearfully, i point to a possibility inadequacy here. suppose, just
> suppose, the namespace weren't known at compile time either. should we
> make it complete by adding:
>
> <xsp:element>
> <xsp:namespace>
> <xsp:expr>unknownNamespaceString</xsp:expr>
> </xsp:namespace>
> <xsp:name><xsp:expr>
> "new" + tagName
> </xsp:expr></xsp:name>
> </xsp:element>
>
> i can assure you, i'll never actually _want_ to use this construct, but
> you _know_ someone will. right?
>
> or we could bite the bullet and add {} expression processing to the
> attributes of certain xsp elements. that would cut down on the number of
> elements we need to add to the language.
Good point.
Ricardo, how hard would be to implement such an addiction?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: C2 XSP SQL taglib
Posted by Donald Ball <ba...@webslingerZ.com>.
On Fri, 1 Sep 2000, Ricardo Rocha wrote:
> We may also consider XSLT's own use of <xsl:element> where attribute
> name can take a dynamic XPath expression:
>
> <xsl:element name="{@tagname}">...</xsl:element>
>
> Since XSP doesn't support XSLT's {...} idiom inside attributes, we
> may need to do something like:
>
> <xsp:element namespace="http://localhost/foo">
> <xsp:name><xsp:expr>
> "new" + tagName
> </xsp:expr></xsp:name>
> </xsp:element>
fearfully, i point to a possibility inadequacy here. suppose, just
suppose, the namespace weren't known at compile time either. should we
make it complete by adding:
<xsp:element>
<xsp:namespace>
<xsp:expr>unknownNamespaceString</xsp:expr>
</xsp:namespace>
<xsp:name><xsp:expr>
"new" + tagName
</xsp:expr></xsp:name>
</xsp:element>
i can assure you, i'll never actually _want_ to use this construct, but
you _know_ someone will. right?
or we could bite the bullet and add {} expression processing to the
attributes of certain xsp elements. that would cut down on the number of
elements we need to add to the language.
- donald
Re: C2 XSP SQL taglib
Posted by Ricardo Rocha <ri...@apache.org>.
Stefano Mazzocchi wrote:
> All right. So this means that you have
>
> <xsp:element>
> <xsp:element-name><xsp:expr>someMethod()</xsp:expr></xsp:element-name>
> <xsp:attribute>
>
> <xsp:attribute-name><xsp:expr>someAttMethod()</xsp:expr></xsp:attribute-name>
> <xsp:expr>someOtherAttMethod()</xsp:expr>
> </xsp:attribute>
> <xsp:expr>someOtherMethod()</xsp:expr>
> </xsp:element>
>
> if you have both name and content of both element and attribute dynamic.
>
> Is this correct?
>
> Ricardo, please speak up on this since I understand it but still don't
> like it at all, it's all but elegant. :/
I definitely think XSP should allow for this level of dynamism!
There are many scenarios where you may legitimatelly need to choose a
tagname dynamically at request time.
There are valid cases where a namespaces and tagnames themselves may
be parameters to some XSP dynamic tag. Let's consider, for example,
Donald's SQL logicsheet and processor, where the user specifies what
namespace and tagname he wants to use to wrap his database stuff.
We may also consider XSLT's own use of <xsl:element> where attribute
name can take a dynamic XPath expression:
<xsl:element name="{@tagname}">...</xsl:element>
Since XSP doesn't support XSLT's {...} idiom inside attributes, we
may need to do something like:
<xsp:element namespace="http://localhost/foo">
<xsp:name><xsp:expr>
"new" + tagName
</xsp:expr></xsp:name>
</xsp:element>
==========================================================================
Stefano Mazzocchi wrote:
>
> Donald Ball wrote:
> >
> > On Fri, 1 Sep 2000, Stefano Mazzocchi wrote:
> >
> > > This is the interesting concept and, admittedly, I've been blinded by a
> > > "every contract is a schema" anti-pattern.
> > >
> > > Ok, I'm convinced... now we can talk about how to implement this in XSP.
> >
> > normal syntax is:
> >
> > <xsp:element name="foo"/>
> >
> > but we want the name to be possibly chosen at runtime. this could work:
> >
> > <xsp:element>
> > <xsp:element-name>...</xsp:element-name>
> > </xsp:element>
> >
> > e.g.
> >
> > <xsp:element>
> > <xsp:element-name><xsp:expr>rs.getString(1)</xsp:expr></xsp:element-name>
> > </xsp:element>
> >
> > yeah, it's ugly, but then again, this isn't a feature we're going to be
> > encouraging people to use (i think we can all agree on that).
>
> All right. So this means that you have
>
> <xsp:element>
> <xsp:element-name><xsp:expr>someMethod()</xsp:expr></xsp:element-name>
> <xsp:attribute>
>
> <xsp:attribute-name><xsp:expr>someAttMethod()</xsp:expr></xsp:attribute-name>
> <xsp:expr>someOtherAttMethod()</xsp:expr>
> </xsp:attribute>
> <xsp:expr>someOtherMethod()</xsp:expr>
> </xsp:element>
>
> if you have both name and content of both element and attribute dynamic.
>
> Is this correct?
>
> Ricardo, please speak up on this since I understand it but still don't
> like it at all, it's all but elegant. :/
Re: C2 XSP SQL taglib
Posted by Stefano Mazzocchi <st...@apache.org>.
Donald Ball wrote:
>
> On Fri, 1 Sep 2000, Stefano Mazzocchi wrote:
>
> > This is the interesting concept and, admittedly, I've been blinded by a
> > "every contract is a schema" anti-pattern.
> >
> > Ok, I'm convinced... now we can talk about how to implement this in XSP.
>
> normal syntax is:
>
> <xsp:element name="foo"/>
>
> but we want the name to be possibly chosen at runtime. this could work:
>
> <xsp:element>
> <xsp:element-name>...</xsp:element-name>
> </xsp:element>
>
> e.g.
>
> <xsp:element>
> <xsp:element-name><xsp:expr>rs.getString(1)</xsp:expr></xsp:element-name>
> </xsp:element>
>
> yeah, it's ugly, but then again, this isn't a feature we're going to be
> encouraging people to use (i think we can all agree on that).
All right. So this means that you have
<xsp:element>
<xsp:element-name><xsp:expr>someMethod()</xsp:expr></xsp:element-name>
<xsp:attribute>
<xsp:attribute-name><xsp:expr>someAttMethod()</xsp:expr></xsp:attribute-name>
<xsp:expr>someOtherAttMethod()</xsp:expr>
</xsp:attribute>
<xsp:expr>someOtherMethod()</xsp:expr>
</xsp:element>
if you have both name and content of both element and attribute dynamic.
Is this correct?
Ricardo, please speak up on this since I understand it but still don't
like it at all, it's all but elegant. :/
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: C2 XSP SQL taglib
Posted by Donald Ball <ba...@webslingerZ.com>.
On Fri, 1 Sep 2000, Stefano Mazzocchi wrote:
> This is the interesting concept and, admittedly, I've been blinded by a
> "every contract is a schema" anti-pattern.
>
> Ok, I'm convinced... now we can talk about how to implement this in XSP.
normal syntax is:
<xsp:element name="foo"/>
but we want the name to be possibly chosen at runtime. this could work:
<xsp:element>
<xsp:element-name>...</xsp:element-name>
</xsp:element>
e.g.
<xsp:element>
<xsp:element-name><xsp:expr>rs.getString(1)</xsp:expr></xsp:element-name>
</xsp:element>
yeah, it's ugly, but then again, this isn't a feature we're going to be
encouraging people to use (i think we can all agree on that).
- donald