You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xsp-dev@xml.apache.org by Matt Sergeant <ma...@sergeant.org> on 2000/11/06 21:01:47 UTC
XSP Spec
OK, shall we get started?
I want to get together a full specification for XSP... I figure mostly
what we need to know is a list of tags, and what they are supposed to
do. Some operate differently in different contexts (e.g. <xsp:expr>
sometimes fires a character event, and sometimes creates a string, at
least thats the way I've interpreted it...), so we need to document that
too.
Here's my first attempt:
Below I list the tag, followed by any attributes (and possible options),
then a few subsections: reason is the "raison d'etre" for that tag,
context is the XPath context that tag is valid in (we could possibly
generate a schematron validator out of those), then results is the type of
code we're generating from that tag. For the code I'm just going to focus
in SAX - it should be possible to convert to DOM node creation should that
be required...
xsp:page (language => '(Java|Perl)', indent-result => '(Yes|No)')
reason: doesn't really do anything, except maybe set a few flags
context: /xsp:page
results: class framework
xsp:structure
I'd like someone else to fill this in.
xsp:dtd
I'd like someone else to fill this in.
xsp:include
reason: To "include" external modules
context: /xsp:page/
results: language dependant
xsp:content
xsp:logic
reason: provides a placeholder for class level code
context: /xsp:page/xsp:structure
results: probably nothing - code gets output verbatim (after processing)
xsp:element (name => element_name)
reason: generate an element
context: ???
results: ??? - need more info on what Cocoon does here, obviously it may
have to wait until we have a name and all attributes...
xsp:attribute (name => attribute_name)
reason: generate an attribute
context: xsp:element/xsp:attribute
results: ??? ditto above
xsp:pi
reason: generate a processing instruction
context: anywhere?
results: a processing_instruction event - need more details
regarding the target/data in the PI here...
xsp:comment
reason: generate a comment
context: anywhere?
results: a comment event - need more details regarding the contents of
the comment here...
xsp:text
reason: generate a text node
context: xsp:element/xsp:text ???
results: a characters event - need more details regarding the value of
the characters for the event.
xsp:expr
reason: generate a string using code
context: ???
results: A string or a text event depending on context?
Obviously there are huge holes here, so Ricardo and others, please help me
fill in the wholes and expand this...
Thanks,
--
<Matt/>
/|| ** Director and CTO **
//|| ** AxKit.com Ltd ** ** XML Application Serving **
// || ** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** Personal Web Site: http://sergeant.org/ **
\\//
//\\
// \\
Re: XSP Spec
Posted by Matt Sergeant <ma...@sergeant.org>.
On Wed, 8 Nov 2000, Ricardo Rocha wrote:
>
> Matt Sergeant wrote:
>
> > xsp:page (language => '(Java|Perl)', indent-result => '(Yes|No)')
> > reason: doesn't really do anything, except maybe set a few flags
> > context: /xsp:page
> > results: class framework
>
> Imo, this tag should be deprecated, as explained in a separate post.
> I agree completely with Matt: it does nothing. Its flag-setting role
> can be easily achieved by [root-level] attributes in the xsp namespace.
Deprecated but still implemented, or deprecated and removed?
> The reason why I propose enclosing <xsp:logic> inside <xsp:structure>
> is because the previous mechanism to define class-level logic was,
> simply, to place the corresponding <xsp:logic> element(s) right below
> the (now deprecated) <xsp:page> element. In absence of an XSP
> root element (and given that <xsp:structure> is a _top-level_ tag),
> it seems only right to use <xsp:structure> for this purpose. What do
> you guys think?
I'm not sure... Seems like it could be implcit by the presence of
xsp:logic (or other tags) to me... But then Java is funny about where you
can define functions and things, unlike Perl, so it might make it harder
to process without it.
> > xsp:include
> > reason: To "include" external modules
> > context: /xsp:page/
> > results: language dependant
>
> Note, in the previous example, that here we're replacing <xsp:include> by
> <xsp:import>.
Yes... Replace or add xsp:import as well?
> The "import" directive has a external module _reference_ semantics, not
> generation-time inclusion semantics. Note that JSP uses the <%include%>
> directive with generation-time inclusion semantics.
>
> An open question: should XSP provide a generation-time inclusion
> mechanism? Things to consider: XInclude, external entities and
> logicsheets...
No. What we have will do just fine IMO.
> >
> > xsp:content
>
> This tag provides a way of inlining XML content inside <xsp:logic> without
> closing and reopening the logic block. It has been repeatedly suggested we
> should deprecated, but I feel it has a rightful place under the sun. The only
>
> limitation: it's vali _only_ inside an <xsp:logic> element.
Why is it needed? Surely if you start seeing XML elements inside
<xsp:logic> they just fire off SAX events (or call out to whatever they
are supposed to do if they implement some logic)?
> >
> > xsp:logic
> > reason: provides a placeholder for class level code
> > context: /xsp:page/xsp:structure
> > results: probably nothing - code gets output verbatim (after processing)
>
> According to my proposal, <xsp:logic> does not provide a placeholder for
> _class-level_ code but for "regular" inlined code.
OK, so the context above is incorrect.
> Implicit in XSP's code generation mechanism (for Java and other OO languages,
> at least) is the notion that the input document is to be translated into XML
> generation
> code _inside a method body_ only. <xsp:logic> blocks augment this method
> body.
Yup.
> > xsp:element (name => element_name)
> > reason: generate an element
> > context: ???
> > results: ??? - need more info on what Cocoon does here, obviously it may
> > have to wait until we have a name and all attributes...
>
> <xsp:element> has semantics similar to that of XSLT's <xsl:element> tag:
> it's meant to dynamically build an element whose tag name and/or attribute
> name/values are not know at generation time.
>
> This tag has been the object of a debate because it appears to be redundant
> and overlapping with respect to XSLT. Note, however, that XSP is a
> _code generation_ language, not a transformation one. Where <xsl:element>
> says "insert an element here", XSP says "generate code to dynamically
> build an element here".
>
> Currently, <xsp:page> lacks namespace support and this must be fixed asap.
> In the DOM version, this problem can be easily solved by concatenating the
> namespace _prefix_ and the tag name, so nobody has complained so far.
>
> A more rigurous definition calls the explicit and separate definition of the
> tag name and the namespace's _uri_ (as opposed to its prefix):
>
> <xsp:element>
> <xsp:name>. . .>/xsp:name>
> <xsp:namespace-uri>. . .</xsp:namespace>
> . . .
> </xsp:element>
I'd rather not go that way - can't we just work like XSLT - where
namespaces have to be defined in the document (and yet are valid inside of
XPath too) ? I can't see any use for <xsp:namespace> - dynamically
declaring a namespace seems bad to me...
> > xsp:attribute (name => attribute_name)
> > reason: generate an attribute
> > context: xsp:element/xsp:attribute
> > results: ??? ditto above
>
> Same as above: <xsp:attribute> provides a means to dynamically build
> an attribute when its name and/or value are not known at generation
> time.
>
> Btw, both <xsp:element> and <xsp:attribute> names can be defined
> by means of a "name" attribute or a nested <xsp:name> element:
>
> <xsp:element name="constant-name">. . .</xsp:element>
>
> <xsp:element>
> <xsp:name><xsp:expr>myTagName</xsp:expr></xsp:name>
> . . .
> </xsp:element>
OK, so how does this work with SAX then? What do you wait for, before
firing the start_element SAX event (because obviously you need the element
name and all attributes to pass to the event)? Bear in mind that AxKit's
XSP->Perl processor is not XSLT based, it is SAX based, so it can't just
do tree logic like forward looks (well, it could, but I'd rather not, as
that is a lot of work).
> > xsp:pi
> > reason: generate a processing instruction
> > context: anywhere?
> > results: a processing_instruction event - need more details
> > regarding the target/data in the PI here...
>
> Consistency with related languages (XSLT in this case) would require
> that we rename this element to <xsp:processing-instruction>.
Ugh... :-)
Do we have to be consistent? Or maybe provide both...
> Target and data are specified in the usual way: as either attributes
> to the XSP tag when their value is known at generation time or as
> nested elements when their value is to be computed at request time.
That seems consistent with <xsp:element>, but could you share what the
tags and attributes are please :-)
> > xsp:comment
> > reason: generate a comment
> > context: anywhere?
> > results: a comment event - need more details regarding the contents of
> > the comment here...
>
> I feel the current definition is appropriate...
>
> >
> > xsp:text
> > reason: generate a text node
> > context: xsp:element/xsp:text ???
> > results: a characters event - need more details regarding the value of
> > the characters for the event.
>
> <xsp:text> has never been part of the "official" XSP language definition.
> It's a hack used internally by Cocoon's XSP processor to enclose strings
> escaped according to the rules of the target progamming language.
Could you go into a little more detail here?
> Its semantics are _totally_ unrelated to those of XSLT's <xsl:text>
> tag.
>
> The current string enconding mechanism should _not_ use the XSP
> namespace.
OK, so we remove it from the spec?
> > xsp:expr
> > reason: generate a string using code
> > context: ???
> > results: A string or a text event depending on context?
>
> <xsp:expr> produces either an [object] _expression_ (not necessarily a
> String)
> or a character event depending on context..
Isn't it coerced into a string regardless though?
> When <xsp:expr> is enclosed in another XSP tag (except <xsp:content>), it's
> replaced by the code it contains. Otherwise it should be treated as a text
> node
> and, therefore, coerced to String to be output through a characters SAX
> event.
OK...
I'm thinking of setting up a Wiki to make editing this spec easier for
us. Any thoughts on that?
--
<Matt/>
/|| ** Director and CTO **
//|| ** AxKit.com Ltd ** ** XML Application Serving **
// || ** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** Personal Web Site: http://sergeant.org/ **
\\//
//\\
// \\
Re: XSP Spec
Posted by Ricardo Rocha <ri...@apache.org>.
Matt Sergeant wrote:
> xsp:page (language => '(Java|Perl)', indent-result => '(Yes|No)')
> reason: doesn't really do anything, except maybe set a few flags
> context: /xsp:page
> results: class framework
Imo, this tag should be deprecated, as explained in a separate post.
I agree completely with Matt: it does nothing. Its flag-setting role
can be easily achieved by [root-level] attributes in the xsp namespace.
>
> xsp:structure
> I'd like someone else to fill this in.
So far, this top-level element has been used only to enclose <xsp:include>
(e.g. Java import) directives. As explained in the post proposing <xsp:page>
deprecation, this element could be redefined to enclose both import
directives and class-level logic. Example:
<page xmlns:xsp="http://apache.org/xsp">
<xsp:structure>
<xsp:import>java.text.SimpleDateFormat</xsp:import>
<xsp:logic>
private static String systemDate(String mask) {
return new SimpleDateFormat(mask).format(new Date());
}
</xsp:logic>
</xsp:structure>
</page>
The reason why I propose enclosing <xsp:logic> inside <xsp:structure>
is because the previous mechanism to define class-level logic was,
simply, to place the corresponding <xsp:logic> element(s) right below
the (now deprecated) <xsp:page> element. In absence of an XSP
root element (and given that <xsp:structure> is a _top-level_ tag),
it seems only right to use <xsp:structure> for this purpose. What do
you guys think?
> xsp:include
> reason: To "include" external modules
> context: /xsp:page/
> results: language dependant
Note, in the previous example, that here we're replacing <xsp:include> by
<xsp:import>.
The "import" directive has a external module _reference_ semantics, not
generation-time inclusion semantics. Note that JSP uses the <%include%>
directive with generation-time inclusion semantics.
An open question: should XSP provide a generation-time inclusion
mechanism? Things to consider: XInclude, external entities and
logicsheets...
>
> xsp:content
This tag provides a way of inlining XML content inside <xsp:logic> without
closing and reopening the logic block. It has been repeatedly suggested we
should deprecated, but I feel it has a rightful place under the sun. The only
limitation: it's vali _only_ inside an <xsp:logic> element.
>
> xsp:logic
> reason: provides a placeholder for class level code
> context: /xsp:page/xsp:structure
> results: probably nothing - code gets output verbatim (after processing)
According to my proposal, <xsp:logic> does not provide a placeholder for
_class-level_ code but for "regular" inlined code.
Implicit in XSP's code generation mechanism (for Java and other OO languages,
at least) is the notion that the input document is to be translated into XML
generation
code _inside a method body_ only. <xsp:logic> blocks augment this method
body.
>
> xsp:element (name => element_name)
> reason: generate an element
> context: ???
> results: ??? - need more info on what Cocoon does here, obviously it may
> have to wait until we have a name and all attributes...
<xsp:element> has semantics similar to that of XSLT's <xsl:element> tag:
it's meant to dynamically build an element whose tag name and/or attribute
name/values are not know at generation time.
This tag has been the object of a debate because it appears to be redundant
and overlapping with respect to XSLT. Note, however, that XSP is a
_code generation_ language, not a transformation one. Where <xsl:element>
says "insert an element here", XSP says "generate code to dynamically
build an element here".
Currently, <xsp:page> lacks namespace support and this must be fixed asap.
In the DOM version, this problem can be easily solved by concatenating the
namespace _prefix_ and the tag name, so nobody has complained so far.
A more rigurous definition calls the explicit and separate definition of the
tag name and the namespace's _uri_ (as opposed to its prefix):
<xsp:element>
<xsp:name>. . .>/xsp:name>
<xsp:namespace-uri>. . .</xsp:namespace>
. . .
</xsp:element>
>
> xsp:attribute (name => attribute_name)
> reason: generate an attribute
> context: xsp:element/xsp:attribute
> results: ??? ditto above
Same as above: <xsp:attribute> provides a means to dynamically build
an attribute when its name and/or value are not known at generation
time.
Btw, both <xsp:element> and <xsp:attribute> names can be defined
by means of a "name" attribute or a nested <xsp:name> element:
<xsp:element name="constant-name">. . .</xsp:element>
<xsp:element>
<xsp:name><xsp:expr>myTagName</xsp:expr></xsp:name>
. . .
</xsp:element>
>
> xsp:pi
> reason: generate a processing instruction
> context: anywhere?
> results: a processing_instruction event - need more details
> regarding the target/data in the PI here...
Consistency with related languages (XSLT in this case) would require
that we rename this element to <xsp:processing-instruction>.
Target and data are specified in the usual way: as either attributes
to the XSP tag when their value is known at generation time or as
nested elements when their value is to be computed at request time.
>
> xsp:comment
> reason: generate a comment
> context: anywhere?
> results: a comment event - need more details regarding the contents of
> the comment here...
I feel the current definition is appropriate...
>
> xsp:text
> reason: generate a text node
> context: xsp:element/xsp:text ???
> results: a characters event - need more details regarding the value of
> the characters for the event.
<xsp:text> has never been part of the "official" XSP language definition.
It's a hack used internally by Cocoon's XSP processor to enclose strings
escaped according to the rules of the target progamming language.
Its semantics are _totally_ unrelated to those of XSLT's <xsl:text>
tag.
The current string enconding mechanism should _not_ use the XSP
namespace.
>
> xsp:expr
> reason: generate a string using code
> context: ???
> results: A string or a text event depending on context?
<xsp:expr> produces either an [object] _expression_ (not necessarily a
String)
or a character event depending on context..
When <xsp:expr> is enclosed in another XSP tag (except <xsp:content>), it's
replaced by the code it contains. Otherwise it should be treated as a text
node
and, therefore, coerced to String to be output through a characters SAX
event.
Re: XSP Spec
Posted by Ricardo Rocha <ri...@apache.org>.
Kevin Sonney wrote:
> Correct. I'd also like to propose the following :
>
> xsp:variable
> reason: to create a variable definitions
> context: /xsp:structure/xsp:logic/
> results: language dependant
>
> Now, this *COULD* be a thread safety issue in Java, so it would be best to
> document this for "global flags" or something. I would be using it so that
> this :
>
> <xsp:variable name="debug_trace_info" type="boolean">true</xsp:variable>
>
> would result in this java code :
>
> private static boolean debug_trace_info = true;
>
While I see the need for a tag-based variable declaration mechanism (especially
to avoid name clashes inadvertedly introduced by independent logicsheets) I
don't
think this should be part of the XSP language tagset: we can always declare
variables
inside <xsp:logic> blocks (whether call or method-level).
Imo, the appropriate context for this is at the logicsheet level. A logicsheet
language
(like SLL) could provide directives for declaring and referencing variables so
that
they're properly name-expanded in code to avoid clashes. Example:
<sll:declare-variable name="foo" type="MyClass">
new MyClass(<request:parameter name="foo" default="123"/>)
</sll:declare-variable>
. . .
<xsp:logic>
. . .
if (<sll:variable name="foo"/>.getValue().equals("123")) {
. . .
}
. . .
</xsp:logic>
where variable names in declarations and references would be expanded by
means of prefixes/suffixes (based on the logicsheet's own namespace
prefix) to ensure that no 2 variables with the same name (and in different
logicsheets) would generate the same identifier.
Hmmm... this example looks ugly, I know. More thought is required.
What I'd like to emphasize is that is should be dealt with at a higher level
than
the core XSP tagset.
Re: XSP Spec
Posted by Donald Ball <ba...@webslingerZ.com>.
On Tue, 7 Nov 2000, Matt Sergeant wrote:
> On Mon, 6 Nov 2000, Kevin Sonney wrote:
>
> > On Mon, 6 Nov 2000, Matt Sergeant wrote:
> > > OK, shall we get started?
> >
> > Please! Before I get into it, though, this is *ALL* based on my cocon
> > experience. I probably mention it several time below.
> >
> > Donald will be much better, I think, at explaining some of the constructs
> > as they satnd, but hetre's my best shot. Appologies in advance for any
> > misconceptions I might have.
> >
> > > xsp:structure
> > > I'd like someone else to fill this in.
> >
> > xsp:structure defines, as I understand it, global structers for the
> > class. It's the parent element for xsp:include
>
> Since we're moving forwards, is it really required?
ricardo had suggestion that we might move class-level variable
declarations to xsp:structure, e.g.
<xsp:structure>
<xsp:logic>
Hashtable cache_table = new Hashtable();
</xsp:logic>
</xsp:structure>
> > Correct. I'd also like to propose the following :
> >
> > xsp:variable
> > reason: to create a variable definitions
> > context: /xsp:structure/xsp:logic/
> > results: language dependant
> >
> > Now, this *COULD* be a thread safety issue in Java, so it would be best to
> > document this for "global flags" or something. I would be using it so that
> > this :
> >
> > <xsp:variable name="debug_trace_info" type="boolean">true</xsp:variable>
> >
> > would result in this java code :
> >
> > private static boolean debug_trace_info = true;
>
> Personally I'd rather see you just type this in the logic section - it
> haw no analogy in Perl, and I don't think it does in anything other than
> C++...
i concur. variable declaration and definition syntax and semantics are
highly language dependent.
> I thought XSP 1.1 was going to extend this though, to allow a child tag to
> define the element name...
yeah, ricardo had suggested some syntax, can't recall what it was. i guess
we can make one up since he still hasn't chimed in yet (though he is
subscribed, no fear).
> What I really mean here, is we've got <xsp:comment>comment
> text</xsp:comment>, do we also
> allow: <xsp:comment><xsp:expr>...</xsp:expr></xsp:comment> ???
sure.
- donald
Re: XSP Spec
Posted by Kevin Sonney <ke...@webslingerz.com>.
On Tue, 7 Nov 2000, Matt Sergeant wrote:
> We could simply output warnings in AxKit, no big deal, or we can use
> xsp:structure - remember when I'm talking here that the AxKit XSP
> implementation is BROKEN. Thats why I'm here - because I couldn't do a
> proper implementation because there's no spec :-)
Oh, that's a good point.... *grin*
> Almost, but no cigar... Remember that globals under mod_perl retain their
> value upon subsequent invocations of the same httpd process, so it can
> become a scary nightmare. And if you make it a my() variable, it becomes
> a closure (because the whole thing is a sub). I honestly don't see the
> value there. Maybe a more concrete proposal, along with a better value
> judgement would persuade better?
This is similar to how Cocoon/JServ handles it. Until the page is changed
(forcing a class reload) or the Servlet engine is restarted, any globals
will retain their last values. This *CAN* cause thread safety issues,
which is why I'd only recomend it for flags, and not for vars that would
be better re-initialized on each call to the page.
*Thoughtful Noise* Anyone else want to weigh in on this? Donald? Ricardo?
> [OT] Aren't you rather upset that Cocoon2 has dropped this model then?
Yes, yes I am. Although I'm not using C2 yet, and don't anticipate doing
so for a while *grin*
> Its a very simple context switch... We simply need to specify that
> context in all cases, the default being string. There are only a few
> places where an implied text node context needs to be in place. I think
> :-)
Agreed. I'll echo your query : Ricardo?
--
+-------------------------------------------+
| Kevin Sonney kevin@webslingerZ.com |
| Systems Programmer www.webslingerZ.com |
+-------------------------------------------+
"The weakest link in any civil rights case is always the
defendant. Imagine being a lawyer and getting a call from me. That's why I
try to, uh, behave myself." - Hunter S. Thompson
Re: XSP Spec
Posted by Matt Sergeant <ma...@sergeant.org>.
On Tue, 7 Nov 2000, Kevin Sonney wrote:
> Matt -
>
> I should mention, before I begin, that I haven't gotten AxKit to play nice
> on my testbed yet, so I don't ahve practical experience on how it parses
> xsp. Correct me where I'm wrong, and feel free to kick me if I'm *WAAAY*
> off base.
>
> On Tue, 7 Nov 2000, Matt Sergeant wrote:
> > > xsp:structure defines, as I understand it, global structers for the
> > > class. It's the parent element for xsp:include
> >
> > Since we're moving forwards, is it really required?
>
> I think so. In cocoon, xsp:structure is used for class-wide declairations,
> and this helps to keep that straight, not only in their head, but in
> implementors' heads. *grin*
>
> > AxKit's parser is very DWIMY (Do What I Mean), much like Perl. It tries
> > not to bite you if you make this sort of mistake. Same for ommitting the
> > root xsp:page element.
>
> Hrm. This would be an issue in cross platform compatibility, though,
> wouldn't it? What about parsers that are strict validators?
We could simply output warnings in AxKit, no big deal, or we can use
xsp:structure - remember when I'm talking here that the AxKit XSP
implementation is BROKEN. Thats why I'm here - because I couldn't do a
proper implementation because there's no spec :-)
> It's partially a philosophical issue, but I'd rather enforce the rule than
> make it optional and have things break later on.
Sure.
> > Personally I'd rather see you just type this in the logic section - it
> > haw no analogy in Perl, and I don't think it does in anything other than
> > C++...
>
> It depends on how you implement it. If, for example, AxKit were to create
> a sub for the page creation, the following xsp :
>
> <xsp:page>
> <xsp:structure>
> <xsp:include>Apache::File</xsp:include>
> <xsp:variable name="bobo" type="number">1</xsp:variable>
> </xsp:structure>
> <page>
> ...
>
> would result in :
>
> #!/usr/bin/perl
>
> use Apache::File;
>
> $bobo = 1;
>
> sub CreatePage {
> ......
Almost, but no cigar... Remember that globals under mod_perl retain their
value upon subsequent invocations of the same httpd process, so it can
become a scary nightmare. And if you make it a my() variable, it becomes
a closure (because the whole thing is a sub). I honestly don't see the
value there. Maybe a more concrete proposal, along with a better value
judgement would persuade better?
> > I thought XSP 1.1 was going to extend this though, to allow a child tag to
> > define the element name...
>
> I'll have to re-read the spec. Again, this is mostly based on my *USE* of
> XSP in Cocoon 1.x - more of a "how it works now" versus a "how it should
> work in the next implementation."
>
> Now, I *LIKE* the idea of allowing a child to define tjhe element
> name. It could be very useful.
Yes, we need these details filled in...
> > How does this work with SAX? Do you suspend sending the start_element
> > event until you see the first non-xsp element child? I'm thinking that
> > start_element needs to see the attributes, so you can't process the
> > element immediately, right?
>
> I'm not sure how this would/should be implemented in SAX. I would think
> that what you've said is true. I think individual implementors are going
> to have to watch how they do it, though.
>
> > Well I think the people here are well aware that this is a bit of a broken
> > model, and can be done better other ways... But xsp:pi stays, I guess, if
> > only for generating other PI's.
>
> Yeah, it probably can be done in better ways, but as a user, it's darn
> nice to have in a toolkit..
[OT] Aren't you rather upset that Cocoon2 has dropped this model then?
> > What I really mean here, is we've got <xsp:comment>comment
> > text</xsp:comment>, do we also
> > allow: <xsp:comment><xsp:expr>...</xsp:expr></xsp:comment> ???
>
> IMHO, Yes. I'd find this useful to dump important info to the end dos,
> that probably aught not be passed to the end document :
>
> <xsp:comment>Just so you know, the actual value of MyVar is
> <xsp:expr>MyVar</xsp:expr>, but it gets processed below </xsp:comment>
OK, so we need details on how that might work then. Under perl, I can see
it being something like:
<xsp:comment> => $handler->comment(''
MyVar is : => . "MyVar is : "
<xsp:expr>$myvar</xsp:expr> => . do{ $myvar }
More text => . "More text"
</xsp:comment> => );
where the lhs of => there is perl code.
However that processing of xsp:expr isn't always like that, is it? For
example:
<xsp:element name="foo"><xsp:expr>4 + 4</xsp:expr></xsp:element>
Which results in:
<foo>8</foo>
Which means there has to be an implicit text node context there:
$handler->start_element('foo');
$handler->characters(''
. do{ 4 + 4 }
);
$handler->end_element();
(all of this should be trivially translatable to Java)
Now what introduces that text node context? What triggers it? Ricardo?
> > This still needs filling in as to what is the context when generating a
> > stirng or a text event.
>
> I *USE* it as a String. I think it'd probably be more useful to
> the user if it generates a string rather than a text event. Otherwise it
> gets nasty when nesting in other xsp built code (like Donald's esql logic
> sheet). For example, if xsp:expr fires a text event, what does it do to
> the following :
>
> <esql:query>select * from myTable where myId in (<xsp:expr>getIdInfo()</xsp:expr>) </esql:query>
Its a very simple context switch... We simply need to specify that
context in all cases, the default being string. There are only a few
places where an implied text node context needs to be in place. I think
:-)
--
<Matt/>
/|| ** Director and CTO **
//|| ** AxKit.com Ltd ** ** XML Application Serving **
// || ** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** Personal Web Site: http://sergeant.org/ **
\\//
//\\
// \\
Re: XSP Spec
Posted by Kevin Sonney <ke...@webslingerz.com>.
Matt -
I should mention, before I begin, that I haven't gotten AxKit to play nice
on my testbed yet, so I don't ahve practical experience on how it parses
xsp. Correct me where I'm wrong, and feel free to kick me if I'm *WAAAY*
off base.
On Tue, 7 Nov 2000, Matt Sergeant wrote:
> > xsp:structure defines, as I understand it, global structers for the
> > class. It's the parent element for xsp:include
>
> Since we're moving forwards, is it really required?
I think so. In cocoon, xsp:structure is used for class-wide declairations,
and this helps to keep that straight, not only in their head, but in
implementors' heads. *grin*
> AxKit's parser is very DWIMY (Do What I Mean), much like Perl. It tries
> not to bite you if you make this sort of mistake. Same for ommitting the
> root xsp:page element.
Hrm. This would be an issue in cross platform compatibility, though,
wouldn't it? What about parsers that are strict validators?
It's partially a philosophical issue, but I'd rather enforce the rule than
make it optional and have things break later on.
> Personally I'd rather see you just type this in the logic section - it
> haw no analogy in Perl, and I don't think it does in anything other than
> C++...
It depends on how you implement it. If, for example, AxKit were to create
a sub for the page creation, the following xsp :
<xsp:page>
<xsp:structure>
<xsp:include>Apache::File</xsp:include>
<xsp:variable name="bobo" type="number">1</xsp:variable>
</xsp:structure>
<page>
...
would result in :
#!/usr/bin/perl
use Apache::File;
$bobo = 1;
sub CreatePage {
......
> I thought XSP 1.1 was going to extend this though, to allow a child tag to
> define the element name...
I'll have to re-read the spec. Again, this is mostly based on my *USE* of
XSP in Cocoon 1.x - more of a "how it works now" versus a "how it should
work in the next implementation."
Now, I *LIKE* the idea of allowing a child to define tjhe element
name. It could be very useful.
> How does this work with SAX? Do you suspend sending the start_element
> event until you see the first non-xsp element child? I'm thinking that
> start_element needs to see the attributes, so you can't process the
> element immediately, right?
I'm not sure how this would/should be implemented in SAX. I would think
that what you've said is true. I think individual implementors are going
to have to watch how they do it, though.
> Well I think the people here are well aware that this is a bit of a broken
> model, and can be done better other ways... But xsp:pi stays, I guess, if
> only for generating other PI's.
Yeah, it probably can be done in better ways, but as a user, it's darn
nice to have in a toolkit..
> What I really mean here, is we've got <xsp:comment>comment
> text</xsp:comment>, do we also
> allow: <xsp:comment><xsp:expr>...</xsp:expr></xsp:comment> ???
IMHO, Yes. I'd find this useful to dump important info to the end dos,
that probably aught not be passed to the end document :
<xsp:comment>Just so you know, the actual value of MyVar is
<xsp:expr>MyVar</xsp:expr>, but it gets processed below </xsp:comment>
> This still needs filling in as to what is the context when generating a
> stirng or a text event.
I *USE* it as a String. I think it'd probably be more useful to
the user if it generates a string rather than a text event. Otherwise it
gets nasty when nesting in other xsp built code (like Donald's esql logic
sheet). For example, if xsp:expr fires a text event, what does it do to
the following :
<esql:query>select * from myTable where myId in (<xsp:expr>getIdInfo()</xsp:expr>) </esql:query>
--
+-------------------------------------------+
| Kevin Sonney kevin@webslingerZ.com |
| Systems Programmer www.webslingerZ.com |
+-------------------------------------------+
"The weakest link in any civil rights case is always the
defendant. Imagine being a lawyer and getting a call from me. That's why I
try to, uh, behave myself." - Hunter S. Thompson
Re: XSP Spec
Posted by Matt Sergeant <ma...@sergeant.org>.
On Mon, 6 Nov 2000, Kevin Sonney wrote:
> On Mon, 6 Nov 2000, Matt Sergeant wrote:
> > OK, shall we get started?
>
> Please! Before I get into it, though, this is *ALL* based on my cocon
> experience. I probably mention it several time below.
>
> Donald will be much better, I think, at explaining some of the constructs
> as they satnd, but hetre's my best shot. Appologies in advance for any
> misconceptions I might have.
>
> > xsp:structure
> > I'd like someone else to fill this in.
>
> xsp:structure defines, as I understand it, global structers for the
> class. It's the parent element for xsp:include
Since we're moving forwards, is it really required?
If so, here's the spec:
xsp:structure
reason: wraps multiple xsp:include's together
context: /xsp:page/xsp:structure
results: nothing
> > xsp:include
> > reason: To "include" external modules
> > context: /xsp:page/xsp:structure/xsp:include
# added xsp:structure to the above context
> > results: language dependant
>
> I was under the impression that xsp:include had to be inside an
> xsp:structure elemnt (at least that's how cocoon does it - I haven't been
> able to play with xsp in AxKit. yet)
AxKit's parser is very DWIMY (Do What I Mean), much like Perl. It tries
not to bite you if you make this sort of mistake. Same for ommitting the
root xsp:page element.
> Correct. I'd also like to propose the following :
>
> xsp:variable
> reason: to create a variable definitions
> context: /xsp:structure/xsp:logic/
> results: language dependant
>
> Now, this *COULD* be a thread safety issue in Java, so it would be best to
> document this for "global flags" or something. I would be using it so that
> this :
>
> <xsp:variable name="debug_trace_info" type="boolean">true</xsp:variable>
>
> would result in this java code :
>
> private static boolean debug_trace_info = true;
Personally I'd rather see you just type this in the logic section - it
haw no analogy in Perl, and I don't think it does in anything other than
C++...
> > xsp:logic
> > reason: provides a placeholder for class level code
> > context: /xsp:page/xsp:structure
> > results: probably nothing - code gets output verbatim (after processing)
>
> Correct. You shoudl be careful, though. You should only use xsp:logic
> inside xsp:structure, IMHO, to create class level functions and/or
> globals flags.
>
> > xsp:element (name => element_name)
> > reason: generate an element
> > context: ???
> > results: ??? - need more info on what Cocoon does here, obviously it may
> > have to wait until we have a name and all attributes...
>
> In my experience it's been pretty clear how this works. the following:
>
> <xsp:element name="element1">data</xsp:element>
>
> results in :
>
> <element>data</element>
>
> I haven't foudn it near as useful as xsp:attribute, though. I think this
> is meant to act like the xsl:element structures.
I thought XSP 1.1 was going to extend this though, to allow a child tag to
define the element name...
> > xsp:attribute (name => attribute_name)
> > reason: generate an attribute
> > context: xsp:element/xsp:attribute
> > results: ??? ditto above
>
> FWIW, This can be placed withing *ANY* element, under cocoon. So if you
> needed to construct an attribute value based on function call :
>
> <option>
> <xsp:attribute name="value">
> <xsp:expr>get_option_data()</xsp:expr>
> </xsp:attribute>
> </option>
>
> This makes life easier, because you just can't put an xsp:expr in an
> attribute value field. I think it has something to do with the XML spec
> *grin*
How does this work with SAX? Do you suspend sending the start_element
event until you see the first non-xsp element child? I'm thinking that
start_element needs to see the attributes, so you can't process the
element immediately, right?
> > xsp:pi
> > reason: generate a processing instruction
> > context: anywhere?
> > results: a processing_instruction event - need more details
> > regarding the target/data in the PI here...
>
> I've used it anywhere. It *ALWAYS* creates a PI in the root of the
> document. So this :
>
> <xsp:page>
> <page>
> <xsp:pi name="xsl-stylesheet">
> href="some_dynamic_name.xsl" type="text/xsl"
> </xsp:pi>
> Page Data
> </page>
> </xsp:page>
>
> Will result in the following :
>
> <page>
> Page Data
> </page>
> <?xsl-styelsheet href="some_dynamic_name.xsl" type="text/xsl"?>
>
> This is *REALLY* useful, I've found, when one data set may need to be
> presented in different ways, and *NOT* just on a per-browser context :
>
> if (state = PREVIEW) {
> // xsp:pi to create the a preview of the final doc here
> } else {
> // xsp:pi to create an edit form here
> }
Well I think the people here are well aware that this is a bit of a broken
model, and can be done better other ways... But xsp:pi stays, I guess, if
only for generating other PI's.
> > xsp:comment
> > reason: generate a comment
> > context: anywhere?
> > results: a comment event - need more details regarding the contents of
> > the comment here...
>
> AFAIK, Standard comment rules apply - whatever it is ahs to be represented
> as a string.
What I really mean here, is we've got <xsp:comment>comment
text</xsp:comment>, do we also
allow: <xsp:comment><xsp:expr>...</xsp:expr></xsp:comment> ???
> > xsp:expr
> > reason: generate a string using code
> > context: ???
> > results: A string or a text event depending on context?
>
> AFAIK, this is correct. I use it to generate node data as needed. See my
> xsp:attribute example above
This still needs filling in as to what is the context when generating a
stirng or a text event.
--
<Matt/>
/|| ** Director and CTO **
//|| ** AxKit.com Ltd ** ** XML Application Serving **
// || ** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** Personal Web Site: http://sergeant.org/ **
\\//
//\\
// \\
Re: XSP Spec
Posted by Kevin Sonney <ke...@webslingerz.com>.
On Mon, 6 Nov 2000, Matt Sergeant wrote:
> OK, shall we get started?
Please! Before I get into it, though, this is *ALL* based on my cocon
experience. I probably mention it several time below.
Donald will be much better, I think, at explaining some of the constructs
as they satnd, but hetre's my best shot. Appologies in advance for any
misconceptions I might have.
> xsp:structure
> I'd like someone else to fill this in.
xsp:structure defines, as I understand it, global structers for the
class. It's the parent element for xsp:include
> xsp:include
> reason: To "include" external modules
> context: /xsp:page/
> results: language dependant
I was under the impression that xsp:include had to be inside an
xsp:structure elemnt (at least that's how cocoon does it - I haven't been
able to play with xsp in AxKit. yet)
Correct. I'd also like to propose the following :
xsp:variable
reason: to create a variable definitions
context: /xsp:structure/xsp:logic/
results: language dependant
Now, this *COULD* be a thread safety issue in Java, so it would be best to
document this for "global flags" or something. I would be using it so that
this :
<xsp:variable name="debug_trace_info" type="boolean">true</xsp:variable>
would result in this java code :
private static boolean debug_trace_info = true;
> xsp:logic
> reason: provides a placeholder for class level code
> context: /xsp:page/xsp:structure
> results: probably nothing - code gets output verbatim (after processing)
Correct. You shoudl be careful, though. You should only use xsp:logic
inside xsp:structure, IMHO, to create class level functions and/or
globals flags.
> xsp:element (name => element_name)
> reason: generate an element
> context: ???
> results: ??? - need more info on what Cocoon does here, obviously it may
> have to wait until we have a name and all attributes...
In my experience it's been pretty clear how this works. the following:
<xsp:element name="element1">data</xsp:element>
results in :
<element>data</element>
I haven't foudn it near as useful as xsp:attribute, though. I think this
is meant to act like the xsl:element structures.
> xsp:attribute (name => attribute_name)
> reason: generate an attribute
> context: xsp:element/xsp:attribute
> results: ??? ditto above
FWIW, This can be placed withing *ANY* element, under cocoon. So if you
needed to construct an attribute value based on function call :
<option>
<xsp:attribute name="value">
<xsp:expr>get_option_data()</xsp:expr>
</xsp:attribute>
</option>
This makes life easier, because you just can't put an xsp:expr in an
attribute value field. I think it has something to do with the XML spec
*grin*
> xsp:pi
> reason: generate a processing instruction
> context: anywhere?
> results: a processing_instruction event - need more details
> regarding the target/data in the PI here...
I've used it anywhere. It *ALWAYS* creates a PI in the root of the
document. So this :
<xsp:page>
<page>
<xsp:pi name="xsl-stylesheet">
href="some_dynamic_name.xsl" type="text/xsl"
</xsp:pi>
Page Data
</page>
</xsp:page>
Will result in the following :
<page>
Page Data
</page>
<?xsl-styelsheet href="some_dynamic_name.xsl" type="text/xsl"?>
This is *REALLY* useful, I've found, when one data set may need to be
presented in different ways, and *NOT* just on a per-browser context :
if (state = PREVIEW) {
// xsp:pi to create the a preview of the final doc here
} else {
// xsp:pi to create an edit form here
}
> xsp:comment
> reason: generate a comment
> context: anywhere?
> results: a comment event - need more details regarding the contents of
> the comment here...
AFAIK, Standard comment rules apply - whatever it is ahs to be represented
as a string.
> xsp:expr
> reason: generate a string using code
> context: ???
> results: A string or a text event depending on context?
AFAIK, this is correct. I use it to generate node data as needed. See my
xsp:attribute example above
> Obviously there are huge holes here, so Ricardo and others, please help me
> fill in the wholes and expand this...
Well, I've done what I can. Anyone who knows better - CORRECT ME! Anyone
who things I've got it right, that's cool too *grin*.
--
+-------------------------------------------+
| Kevin Sonney kevin@webslingerZ.com |
| Systems Programmer www.webslingerZ.com |
+-------------------------------------------+
"The weakest link in any civil rights case is always the
defendant. Imagine being a lawyer and getting a call from me. That's why I
try to, uh, behave myself." - Hunter S. Thompson