Re: [SUMMARY] Complicated setup

[Jens Lorenz]

Jeremy Quinn wrote:

Hi,


Hi Leo

That was an excellent summary!


I can only agree and turned Leo's mail into a Wiki page by adding a 
small amount of Wiki markup.

http://outerthought.net/wiki/Wiki.jsp?page=CocoonAndApache




Best regards,


Jens

--

Jens Lorenz

interface:projects GmbH \\|//
Tolkewitzer Strasse 49  (o o)
01277 Dresden   oOOo~(_)~oOOo
Germany


-
Please check that your question  has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: Umlauts in cocoon 2.0.2

[Jens Lorenz]

- Original Message -
From: "Ugo Cei" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, September 18, 2002 2:43 PM
Subject: Re: Umlauts in cocoon 2.0.2


>
> Change the encoding of your HTML pages by setting the encoding property
> on the serializer:
>
>   mime-type="text/html" name="html" pool-grow="4" pool-max="32"
> pool-min="4" src="org.apache.cocoon.serialization.HTMLSerializer">
>1024
>iso-8859-1
>  
>
> The browser should recognize the encoding and send back data in
> ISO-8859-1. I don't know if what I've just written is entirely correct,
> but it sure saved my day when faced with a similar situation.

Setting the encoding of the generated HTML pages does not help. The URL
send back by the Browser is always UTF-8 encoded.

Request.setCharacterEncoding(), as suggested by Vadim, usually helps for
GET-Parameters.

Generally it's a good idea to avoid "unsafe" (see RFC) characters in URLs
and GET-Parameters.

> Ugo
>

Jens


-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: XSP Best Practise Question

[Jens Lorenz]

- Original Message -
From: "Hunsberger, Peter" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, August 22, 2002 4:47 PM
Subject: RE: XSP Best Practise Question


> > As you've noted a lot of examples, and suggested solutions to problems
> posted
> > to this list, use an alternate approach: the generators present data
to
> the
> > pipeline which uses Transformers and Actions to do often complex
> operations.
> > The data itself is often wrapped in a page markup language making it
> easier
> > to transform it to other forms (HTML/PDF/etc).
> >
> > This looks like its breaking MVC, and it probably is.
>
> Not necessarily (through it often seems to be true with XSP): Consider
the
> case where your MVC is implemented in XML and XSLT with Java just
providing
> a way to produce the XML.  In such a case you exploit the Cocoon
pipeline to
> separate things, with separate transformation passes (and separate XSLT)
> implementing each piece.  It's a little foggy on whether the XML or the
XSLT
> implements each piece, the paradigm is twisted enough that it doesn't
map
> completely cleanly.  However, you can still get good separation of
function
> if you don't mind the fact that it's a combination of rules specified in
XML
> and implemented in XSLT that end up implementing the complete MVC
pattern
> (as opposed to a single Java or JSP file).
>
> > It's at this point that you're starting to treat the sitemap as a
> programming
> > language rather than a declarative means of gluing together
components.
> >
> > (Aside: anyone notice how close the Sitemap is becoming to a source
file?
> > Imports: map:components; Instance Variables: component/global params
> > added in 2.1; Methods: pipelines. There's a danger there in making
this
> > environment too programmer oriented).
>
> Yes, that's a good observation.  In particular, the sitemap matching
> capabilities begin to become a rule processor.  It strikes me that a
more
> generalized version of the site map would allow XPath traversal of the
> current "pipeline" contents, to match to a template which produces a
"map".
> In other words; the pipeline would just fire off an XSLT that has the
> current Cocoon contexts available to it as parameters or document
sources.
> It would be able to parse these as it needed and directly invoke other
> Cocoon components.  Cocoon's pipeline processing becomes the equivalent
of
> running a transform on a series of XML files which specify what matching
> rules are to be fired. (The results of the transform could be fed to a
> filter that implements the current Cocoon pipeline capabilities.)  The
> default transform would be the identity transform to handle something
> isomorphic to the current version of the sitemap, but one could then
just
> plug in your own XSLT to customize the flow (you'd map various
applications
> with different XML inputs).  This way not only does Cocoon provide a way
of
> running transformations, but the rule engine for determining what
transforms
> to run is just another transform.  Perhaps, this is where flowmaps are
> headed?  I haven't had a chance to look at anything in 2.1 yet

lost you here. Flow is about letting sitemap do what sitemap is meant
for (mapping resources to urls) and defining the application logic
independantly of sitemap. Currently this is procedural JavaScript code.

> > So my general advice is: if the logic is reusable, then make it a
> transformer/action
> > so you'll have the most reuse. If its not, hide it away.
>
> My advice would be more like; stop thinking in procedural terms and stop
> thinking of using Java to implement everything.  Use XML and XSLT and
> exploit their capabilities!
>

XSLT is definitely the wrong place for business logic. You're missing
database access, transactions and other important things for business
logic.


Jens

--

jens.lorenz at interface-projects dot de

interface:projects GmbH \\|//
Tolkewitzer Strasse 49  (o o)
01277 Dresden   oOOo~(_)~oOOo
Germany


-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: cocoon:/ not using current sitemap

[Jens Lorenz]

- Original Message -
From: "David Trammell" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, July 24, 2002 5:58 PM
Subject: cocoon:/ not using current sitemap


> I cannot get the cocoon:/ protocol to work when using it from a sitemap
> that was mounted from another internal request using the cocoon:/
> protocol.  I have included snippets of my two sitemaps that duplicates
> this.
>
> Have I misunderstood how the cocoon:/ protocol works, or is this a bug?
> It works if I do not use cocoon:/ within the second sitemap and generate
> the xhtml directly.  It also works if I do not use cocoon:/ in the first
> one and directly mount the style sitemap.

AFAIR this behavior is known as bug #9736.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9736


> The requested URL is something like http://localhost/test/admin/users
>
> sitemap.xmap :
> ---
> 
> 
> 
>  uri-prefix="{1}/getstyle"/>
> 
> 
>
> 
> 
> 
> 
>
> 
> 
>
> style.xmap :
> ---
> 
> 
> 
> 
> 
> 
> 
>
> 
> 
> 
> 
>
>  
>
>
> Thanks
> David


Jens

--

jens.lorenz at interface-projects dot de

interface:projects GmbH \\|//
Tolkewitzer Strasse 49  (o o)
01277 Dresden   oOOo~(_)~oOOo
Germany


-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: language variable, date formatting

[Jens Lorenz]

- Original Message -
From: "Barbara Post" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, July 24, 2002 5:03 PM
Subject: Re: language variable, date formatting


> Hi, I used something that worked in a simple java class but here there
are
> errors:
>
> 
> import java.util.*;
> import java.text.DateFormat;
> 
> (DateFormat.getDateInstance(DateFormat.FULL, new
> Locale("FR"))).format(Calendar.getInstance().getTime());
>  
> 
>
>
> description org.apache.cocoon.ProcessingException: Language Exception:
> org.apache.cocoon.components.language.LanguageException: Error compiling
> date_xsp: Line 121, column 0: illegal start of expression Line 122,
column
> 0: illegal start of expression Line 126, column 104: ')' expected Line
127,
> column 1: illegal start of expression Line 126, column 71: variable
Calendar
> not found in class org.apache.cocoon.www.xsp.date_xsp Line 126, column
28:
> variable DateFormat not found in class
org.apache.cocoon.www.xsp.date_xsp
> Line 126, column 49: class Locale not found in class
> org.apache.cocoon.www.xsp.date_xsp Line 126, column 1: variable
DateFormat
> not found in class org.apache.cocoon.www.xsp.date_xsp Line 0, column 0:
8
> errors
>
> What's wrong ? Thanks
>
> Barbara

Just a guess: Do you remember that import's a re not allowed within
xsp:logic ? They go into xsp:structure ...

See here:
http://xml.apache.org/cocoon/userdocs/xsp/logicsheet.html
(search for structure, it nearly at the end of the page)


Jens

--

jens.lorenz at interface-projects dot de

interface:projects GmbH \\|//
Tolkewitzer Strasse 49  (o o)
01277 Dresden   oOOo~(_)~oOOo
Germany


-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: language variable, date formatting

[Jens Lorenz]

- Original Message -
From: "Barbara Post" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, July 24, 2002 4:26 PM
Subject: language variable, date formatting


> Hello,

Hi,

> My xsl stylesheet needs to format a date using a locale or a language
> variable that is stored in session (using SunRise portal).
>
> I wonder how I can do this.
>
> If I use an xsp to produce the portion of xml I need (date formatted
> according to a specific locale), how can the xsp get the session
attribute
> since it is stored in sunRise context (or another one if I need to do
so) ?

It probably much easier to produce this via Java, than re-inventing
Locale-specific Date formatting in XSLT.

> My problem is : how to access the session attributes when using sunRise,
to
> use it in sitemap or xsp ? If I use getxml I would have to use DOM then,
> right ?
>
> I was surprised that the raw new Date() does not use
my
> computer locale... (FR) but English one.

Assuming you are using the XSP with Java, this gets translated into
String.valueOf(new Date()) which in turn does nothing more than
(new Date()).toString().
If you want this to be a localized String you have to call
SimpleDateFormat.format(new Date()). This way you can also have
a different Locale for each User (which is probably what you want).


> Thanks for any clue.
>
> Barbara
>



Jens

--

jens.lorenz at interface-projects dot de

interface:projects GmbH \\|//
Tolkewitzer Strasse 49  (o o)
01277 Dresden   oOOo~(_)~oOOo
Germany


-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: Excel generator

[Jens Lorenz]

- Original Message -
From: "Andrew C. Oliver" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, July 23, 2002 8:06 PM
Subject: Re: Excel generator


> Sorry if it sounds like I'm hounding on this issue, but its very
helpful.
>
> And you find the gnumeric format preferrable to striving for Excel 2000
> XML format compatibility?
> (with the understanding that If I did do the generator in Excel format
> I'd probably rewrite the serializer to that as well)
>
> -Andy
>


The rewrite of the serializer is enough of a reason, not to change the
format. (IMHO) Why change something, if it works, as long as there is
no strong reason ? (and Excel format compatibility is no strong reason
for me)

Gnumeric XML is powerful enough and well documented. The latter is the
most important for me. This pdf describing every single tag and
attribute is a huge help, when having to generate a spreadsheet
programmatically.



Jens

--

jens.lorenz at interface-projects dot de

interface:projects GmbH \\|//
Tolkewitzer Strasse 49  (o o)
01277 Dresden   oOOo~(_)~oOOo
Germany


-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: Excel generator

[Jens Lorenz]

- Original Message - 
From: "Andrew C. Oliver" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, July 23, 2002 3:56 PM
Subject: Re: Excel generator


> But the more important part of my answer was "What do you want on your 
> generator, and
> what do you wish you had on your serializer  --  would you like fries 
> too?"  Meaning I need ideas!  
> I'm on the fence,  I want some input.
> 
> -Andy
> 


I think the gnumeric XML format is the way to go. Why bothering with
Excel XML format if it's going to change anyway (if it's just a
translation of the binary format, it is most likely to change). And
Excel still can read and write the old binary formats.
This way you could also use other serializers to produce OpenOffice.org
spreadsheets or any other spreadsheet application.

So, my wish would be a Gnumeric XML generator and serializer. Served
with backed potatoes and some garnish ... ;)



Jens

-- 

jens.lorenz at interface-projects dot de

interface:projects GmbH \\|//
Tolkewitzer Strasse 49  (o o)
01277 Dresden   oOOo~(_)~oOOo
Germany


-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: [Q] Avalon Composer interface - WHERE IS IT?

[Jens Lorenz]

- Original Message -
From: "Ivan Luzyanin" <[EMAIL PROTECTED]>
To: "cocoon-users" <[EMAIL PROTECTED]>
Sent: Thursday, July 18, 2002 11:30 AM
Subject: [Q] Avalon Composer interface - WHERE IS IT?


> Hi!
>
> I want to create cocoon component to access a datasource. I have found
> in cocoon documentation (cocoon-2.0.3/docs/developing/datasources.html)
> a string:
> "... your class needs to implement the Avalon Composer interface."
> and an example that shows implementation of "compose" method.
> BUT the problem is - where (what package) is "Avalon Composer
> interface"???
>
>

Look here. You need to understand Avalon first.

http://jakarta.apache.org/avalon/developing/index.html


Then have a look at the Avalon JavaDocs. In your case

http://jakarta.apache.org/avalon/api/org/apache/avalon/framework/component
/Composable.html



Regards,


Jens

--

jens.lorenz at interface-projects dot de

interface:projects GmbH \\|//
Tolkewitzer Strasse 49  (o o)
01277 Dresden   oOOo~(_)~oOOo
Germany


-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: encoding problem with xslt

[Jens Lorenz]

- Original Message -
From: "Joerg Heinicke" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, July 12, 2002 5:23 PM
Subject: Re: encoding problem with xslt


> Hmm, I didn't test it a long time and didn't find a correlating bug by a
> short view on Xalan bug list. It was a bug in our application that "mü"
was
> "transformed" to "mü".
> (For people with different encoding: u umlaut ==> A+~ and 1/4.)
> I had in mind (and written in our bugzilla) that it was a Xalan bug,
maybe
> that's wrong. It sounds a bit like the description of the original post
on
> this thread. At least we solved it with POST form.
>
> Joerg
>


Thank you very much Joerg. This smells a lot like UTF-8 encoding.




  String s = new String("mü");
  byte[] data = s.getBytes("ISO-8859-1");
  String decoded = new String(data,"UTF-8");

  System.out.println(decoded);



gives mü. So Xalan encoded your string UTF-8. This is the
recommend encoding for URIs (see RFC 2718). So this is no
bug of Xalan.
And this leads to the real problem. URL being encoding
UTF-8 and servlet container encoding being ISO-8859-1.

Solution: ?



Jens

--

jens.lorenz at interface-projects dot de

interface:projects GmbH \\|//
Tolkewitzer Strasse 49  (o o)
01277 Dresden   oOOo~(_)~oOOo
Germany


-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: encoding problem with xslt

[Jens Lorenz]

- Original Message - 
From: "Vadim Gritsenko" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, July 12, 2002 5:05 PM
Subject: RE: encoding problem with xslt




> > Thanks for you input Vadim. But do not only think of web sites. But
> > also of web applications. Think of a web cms for maintaining html
> > content.
> > Avoiding non-ISO characters ist
>   ^^^
> :)

Ooops. This happens when somebody near you forces you to think
in two languages at once (one written, one spoken) ... sorry.
But now you know the german equivalent for "is" (if you didn't
know yet).

> > impossible for non-english web sites.
> > 
> > Fortunately POST method is immune to such issues. So the only option
> > is to carry these characters via POST back to Cocoon.
> 
> It is also the safest way and compatible among all browsers/platforms
> (if platform supports this encoding, of course).
> 
> 
> Take care,
> 
> Vadim
> 

Jens

-- 

jens.lorenz at interface-projects dot de

interface:projects GmbH \\|//
Tolkewitzer Strasse 49  (o o)
01277 Dresden   oOOo~(_)~oOOo
Germany


-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: encoding problem with xslt

[Jens Lorenz]

- Original Message -
From: "Joerg Heinicke" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, July 12, 2002 4:45 PM
Subject: Re: encoding problem with xslt


> > If anyone has some more ideas on this topic (non-ISO-8859-1 characters
> > within URIs), I would greatly appreciate some more input.
> > Conclusion for me is to avoid such characters in URIs. But this does
> > not get easily into the heads of our customers and users. (e.g. file
> > names)
>
> According to the old Xalan bug, we used forms with javascript. But this
> doesn't solve the problem generally, only our special use case.
>
> Joerg
>


Joerg,


which Xalan bug are you referring to ? I browsed the list of open bugs,
but only found related bugs.
IMHO this is not a bug, but a lack of specification. W3C has a draft
about an IRI (internationalized URI), but until this gets adopted
and implemented we'll have to deal with the mess.



Jens

--

jens.lorenz at interface-projects dot de

interface:projects GmbH \\|//
Tolkewitzer Strasse 49  (o o)
01277 Dresden   oOOo~(_)~oOOo
Germany


-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: encoding problem with xslt

[Jens Lorenz]

- Original Message -
From: "Vadim Gritsenko" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, July 12, 2002 4:36 PM
Subject: RE: encoding problem with xslt


> > From: Jens Lorenz [mailto:[EMAIL PROTECTED]]
> >
> ...
> > If anyone has some more ideas on this topic (non-ISO-8859-1 characters
> > within URIs), I would greatly appreciate some more input.
>
> IMHO, non-ascii characters in URIs should be avoided by all means
> possible.
>
>
> Less issues for you *and* for visitors of your site. Issues with
> non-ascii characters in URIs are endless (I bet you have not thought
> about visitors of your site exchanging bookmarks/URIs, and their systems
> have different encodings)
>
>
> Vadim


Thanks for you input Vadim. But do not only think of web sites. But
also of web applications. Think of a web cms for maintaining html
content.
Avoiding non-ISO characters ist impossible for non-english web sites.

Fortunately POST method is immune to such issues. So the only option
is to carry these characters via POST back to Cocoon.


Jens

--

jens.lorenz at interface-projects dot de

interface:projects GmbH \\|//
Tolkewitzer Strasse 49  (o o)
01277 Dresden   oOOo~(_)~oOOo
Germany


-
Please check that your question  has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: encoding problem with xslt

[Jens Lorenz]

- Original Message -
From: "thorsten schmid" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, July 12, 2002 2:17 PM
Subject: encoding problem with xslt


Hi Thorsten,



> 
> output:
> 
> Integrationsämter
>.
> 
>


This output is certainly correct. URIs generated via HTML output
method of Xalan or Saxon are UTF-8 encoded. (and äöü are 2 bytes wide
when using UTF-8) This is recommended by RFC 2718.

The problem is not Cocoon, but the Servlet-Spec. Tomcats default
encoding is ISO-8859-1. So your URI ist decoded with ISO-8859-1.
This obviously breaks your Cocoon servlet later.
Since HTTP protocol does not send encoding with the URI, there is
also no chance for Tomcat to detect the encoding of the URI. And
even worse Request.setEncoding() affects only parameters (GET request,
POST is immune, since during a POST the encoding is send by the browser)


You have three options:

Set encoding of your servlet container to UTF-8. For Tomcat you do this
by setting CATALINA_OPTS to "-Dfile.encoding=UTF-8". But beware, that
this might break your existing plain text files, which are most probably
ISO-8859-1 encoded. With XML files this is no problem, as long as you
specify their encoding correctly.

Second option is to manually recode the URI within Cocoon via some
custom code. But this is somewhat "hacky".

Third option and probably best, is to use a Servlet filter in front
of Cocoon which does the transformation of character encodings for
you. This way, you don't have to break text files read and written
by the Tomcat JVM, and you can still use full UTF-8 within your URIs.



If anyone has some more ideas on this topic (non-ISO-8859-1 characters
within URIs), I would greatly appreciate some more input.
Conclusion for me is to avoid such characters in URIs. But this does
not get easily into the heads of our customers and users. (e.g. file
names)



Best Regards,


Jens

--

jens.lorenz at interface-projects dot de

interface:projects GmbH \\|//
Tolkewitzer Strasse 49  (o o)
01277 Dresden   oOOo~(_)~oOOo
Germany


-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: SQLTransformer, multiple execute-query siblings?

[Jens Lorenz]

- Original Message -
From: "Jens Lorenz" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, June 21, 2002 4:40 PM
Subject: Re: SQLTransformer, multiple execute-query siblings?


> From: "Argyn Kuketayev" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, June 21, 2002 4:27 PM
> Subject: RE: SQLTransformer, multiple execute-query siblings?
>
>
> > it doesn't support two nested queries on the same level of nesting, as
> far
> > as I remember after looking at C2.0.1 sources. I don't think it's
fixed.
> >
> > Workaround is:
> > 1. modify source codes
>
> The problem is, that it's not that easy. Transformer gets fed
> SAX events and according to this spits out SAX events.
>
> If you want to reference the produced output you would have to
> remember the output somehow which would make this beast far
> more complex than it already is.
>
> If you really wanna do this, go ahead, but expect some work
> ahead (SQLTransformer is kind of an orphaned anyway).
> Otherwise go for XSP/ESQL.
>

I've to correct me on this one. My short looks into the source
were obviously not enough ...

This example is taken from
http://xml.apache.org/cocoon/userdocs/transformers/sql-transformer.html



  http://apache.org/cocoon/SQL/2.0";>
http://apache.org/cocoon/SQL/2.0";>
 
  select id,name from department_table
 
 
  
   select id,name from employee_table where department_id =
 
  
 

  



So according to the user docs this *is* possible. (Haven't testet it
though)


Regards,


Jens

--

jens.lorenz at interface-projects dot de

interface:projects GmbH \\|//
Tolkewitzer Strasse 49  (o o)
01277 Dresden   oOOo~(_)~oOOo
Germany


-
Please check that your question  has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: SQLTransformer, multiple execute-query siblings?

[Jens Lorenz]

- Original Message -
From: "Argyn Kuketayev" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, June 21, 2002 4:27 PM
Subject: RE: SQLTransformer, multiple execute-query siblings?


> it doesn't support two nested queries on the same level of nesting, as
far
> as I remember after looking at C2.0.1 sources. I don't think it's fixed.
>
> Workaround is:
> 1. modify source codes

The problem is, that it's not that easy. Transformer gets fed
SAX events and according to this spits out SAX events.

If you want to reference the produced output you would have to
remember the output somehow which would make this beast far
more complex than it already is.

If you really wanna do this, go ahead, but expect some work
ahead (SQLTransformer is kind of an orphaned anyway).
Otherwise go for XSP/ESQL.

> 2. use XSP
>
> I use XSP with ESQL
>
> > Can someone confirm this, and is there a workaround other
> > than chaining
> > multiple SQLTransformers with XSLT to generate sub-queries?

Regards,


Jens

--

jens.lorenz at interface-projects dot de

interface:projects GmbH \\|//
Tolkewitzer Strasse 49  (o o)
01277 Dresden   oOOo~(_)~oOOo
Germany


-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: RequestParmAction does not work with blanks in form input fie ld

[Jens Lorenz]

RE: RequestParmAction does not work with blanks in form input field
- Original Message -
From: Sternath Elmar
To: '[EMAIL PROTECTED]'
Sent: Tuesday, June 11, 2002 3:27 PM
Subject: AW: RequestParmAction does not work with blanks in form input fie
ld


... Ooops. Pressed  to quickly ...

> You're right, the exception does not have to do anything with the
blanks. What I
> want to do is the following: I try to get request params using
RequestParmAction.
> Then I add these request parms to a http get request string in my
sitemap:
> http://scw_de:[EMAIL PROTECTED]:/BOLServlet/
>
{IdType}Service.uploadDocument?Id={Id}&Title={Title}&DocType={DocT
ype}
>
&Language={Language}&Publisher={Publisher}&Description={Descri
ption}
> &SalesChannel={../1}"/

> Unfortunately, as soon as the request params contain characters which
must be
> escaped (like blanks) this http get request fails. I already tried to
use
> requestQuery instead of single params, but this does not work for
browser http post
> which I need
> because of doing file upload. Any ideas how to solve this problem?
>
> Thanks,
> Elmar

For these cases I have this Action (which is IMHO missing in Cocoon) ...


public class EncodeParameterAction extends AbstractAction implements
ThreadSafe
{
 public Map act( Redirector redirector, SourceResolver resolver, Map
objectModel, String src,
   Parameters parameters ) throws Exception
 {
  Logger logger = getLogger();

  String value = parameters.getParameter( "value" );
  String destkey = parameters.getParameter( "destkey" );

  Map resultMap = new HashMap();

  String encodedValue = URLEncoder.encode( value );
  resultMap.put( destkey, encodedValue );

  return resultMap;
 }
}


Regards,


Jens

--

jens.lorenz at interface-projects dot de

interface:projects GmbH \\|//
Tolkewitzer Strasse 49  (o o)
01277 Dresden   oOOo~(_)~oOOo
Germany


-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: RequestParmAction does not work with blanks in form input fie ld

[Jens Lorenz]

Title: RE: RequestParmAction does not work with blanks in form input field




  - Original Message - 
  From: 
  Sternath Elmar 
  To: '[EMAIL PROTECTED]' 
  
  Sent: Tuesday, June 11, 2002 3:27 
PM
  Subject: AW: RequestParmAction does not 
  work with blanks in form input fie ld
  
  You're right, the exception does not have to do anything with the 
  blanks. What I want to do is the following: I try to get request params using 
  RequestParmAction. Then I add these request parms to a http get request string 
  in my sitemap: http://scw_de:[EMAIL PROTECTED]:/BOLServlet/{IdType}Service.uploadDocument?Id={Id}&Title={Title}&DocType={DocType}&Language={Language}&Publisher={Publisher}&Description={Description}&SalesChannel={../1}"/
  Unfortunately, as soon as the request params contain characters which 
  must be escaped (like blanks) this http get request fails. I already tried to 
  use requestQuery instead of single params, but this does not work for browser 
  http post which I need because of doing file upload. Any ideas how to solve 
  this problem?
   
  Thanks,
  Elmar
   
   
  -Ursprüngliche Nachricht-Von: Naquin, Beth 
  [mailto:[EMAIL PROTECTED]]Gesendet: Montag, 10. Juni 2002 
  18:58An: '[EMAIL PROTECTED]'Betreff: RE: 
  RequestParmAction does not work with blanks in form input fie 
  ld
  
This is just a guess, but are you putting blanks in form 
fields that you are trying to use in the pipeline below?  If so, are 
the fields values really blank or are they 'null'?  Maybe it will help 
to default your textboxes to "" in case the user doesn't enter anything in 
that input?
I use this in my xsp page for a form:  
      
Also, the error about 'HR should be followed by '=' sign': 
does that have something to do with a blank being entered in a form field or 
is that a separate error?
-Original Message- From: 
Sternath Elmar [mailto:[EMAIL PROTECTED]] 
Sent: Monday, June 10, 2002 9:03 AM To: [EMAIL PROTECTED] Subject: 
RequestParmAction does not work with blanks in form input field 

Hello, 
as soon as I put some blanks into an INPUT text/textarea 
field, I get the following output in my browser 
(cocoon2.0.1/tomcat4.0.1)
My pipeline looks as follows (works fine without 
blanks):  
     
    
     
    
    
     
    
    
         
    
    
     
    
    
    
    
     
    
    
    
    
         
    
    
    
    
     
    
    
    
    
    
     
    
    
    
    
    
    
    
    
    
    
    
    
    
    http://scw_de:[EMAIL PROTECTED]:/BOLServlet/{IdType}Service.uploadDocument?Id={Id}&Title={Title}&DocType={DocType}&Language={Language}&Publisher={Publisher}&Description={Description}&SalesChannel={../1}"/>  
    
    
    
    
    
    
    
    
    
    
    
    
    
    
     
    
    
    
    
    
     
    
    
    
    
    
     
    
    
    
    
    
    
    
     
    
    
    
     
    
    
     
    
    
     
    
    
    
    http://139.21.207.160:8080/SCW/testLogin.html"/>   

    
    
     
    
     
         
Thanks in advance, Elmar 
Browser output: 
Cocoon 2 - Internal server error 
type fatal message null 
description java.lang.NullPointerException 
sender 
org.apache.cocoon.servlet.CocoonServlet source 
Cocoon servlet request-uri /BOLServlet/ProductService.uploadDocument path-info ProductService.uploadDocument 
Cocoon 2 - Internal server error 
type fatal message Failed to execute 
pipeline. description 
org.apache.cocoon.ProcessingException: Failed to execute pipeline.: 
org.xml.sax.SAXParseException: Attribute name "HR" must be followed by the 
'=' character.
sender org.apache.cocoon.servlet.CocoonServlet 
source Cocoon servlet request-uri /cocoon/scworkflow/SCW/addNewFileOK path-info scworkflow/SCW/addNewFileOK 
scworkflow/SCW/addNewFileOK 
- 
Please check that your question  has not already been 
answered in the FAQ before 
posting. 

Re: no way to get content-type?

[Jens Lorenz]

- Original Message -
From: "Andreas Vallen" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: "Jens Lorenz" <[EMAIL PROTECTED]>
Sent: Monday, May 13, 2002 10:42 PM
Subject: Re: no way to get content-type?


> Hello,

Hello,

> thanks Jens, that answer was exactly what I was looking for.
>
> Now if Vadim finds some interest in the problem . . .  ;-)
>
> I'll investigate further wether a simple change in URLSource is
possible. I
> too think the other solution with its two request is suboptimal.
>
> But given that I'm not well aquaintained with the cocoon architecture I
might
> as well go for the quick solution.
>
> I'll let you know of any results.

I would really appreciate this ...

> BTW: I hope my reposting of our messages was ok?!

As long as it helps triggering the Vadim-Bot . . .  ;-)

> Cheers,
> Andreas
>


Cheers,


Jens

--

jens.lorenz at interface-projects dot de

interface:projects GmbH \\|//
Tolkewitzer Strasse 49  (o o)
01277 Dresden   oOOo~(_)~oOOo
Germany


-
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>

Re: no way to get content-type?

[Jens Lorenz]

- Original Message -
From: "Andreas Vallen" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, May 13, 2002 5:55 PM
Subject: no way to get content-type?


> Hello cocoon-users,
>
> Is there really no way to determine the content type of a resource
> requested with a generator?
> I've spent some time since my last mail looking at the sources and it
seems
> as if cocoon in its current form can't handle this seemingly simple
task.
>
> Am I overlooking something?

Well, you just think the wrong way around ...

map:generate creates a stream of sax events. No MIME content type can
be applied to this. The content type of the URLSource is actually
determined by the Web-Server according to the extension of the file
it sends.

Looking at your sitemap example, might it be the case that you don't
want to determine the contenttype but the (XML) doctype of the
SAX stream ?

> Look at the following sitemap fragment for an example of what I want to
> achieve:
>
> 
> 
>
>  
>  
>
> 
>   
>   
> 
>
> 
>   
>   
> 
>
> 
>   
>   
> 
>
>

What's wrong with the following ?



  
  



  
  



  
  



... appropriate matchers ommited.

> I would hope that something along this way is easily implementable.
> To me it seems though as if I would have to dig deep into cocoon's
> classes ( URLSource.java came to my mind ) - something I'd like to
> avoid.
>
> thanks,
> Andreas Vallen
>

Regards,


Jens

--

jens.lorenz at interface-projects dot de

interface:projects GmbH \\|//
Tolkewitzer Strasse 49  (o o)
01277 Dresden   oOOo~(_)~oOOo
Germany


-
Please check that your question has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>

Re: Problems with XSP

[Jens Lorenz]

From: "Torsten Curdt" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, April 26, 2002 7:32 PM
Subject: Re: Problems with XSP


> > One could, of course,
> > first run the XSP through a transformer that adds line number
> >comments that are kept 'til the java file is generated,
> >
> > find the enclosing line number comments (well, one would suffice)
> >
> > output the XSP with the line highlighted that translates to the
> > faulty java code
> >
> > Would be kind of overhead outside development but then, a deployed
> > application wouldn't compile XSPs too often.
>
> hm.. you mean this way?
>
>   ...
>   
>  int a = 5;
>   
>  
>   
>  b = a;
>  c = x;
>   
>  ...
>
> transform it once to add the line numbers. (it would be cool if the XSP
> logicsheet could already provide this. but I fear that's not possible
with
> XSLT)
>   ...
>   
>  /* line:4 */ int a = 5;
>   
>  
>   
>  /* line:8 */ b = a;
>  /* line:9 */ c = x;
>   
>   
>
> Then apply the logicsheets which might insert or remove lines from the
> original code:
>
>   ...
>  /* line:4 */ int a = 5;
>
>  .
>
>  /* line:8 */ b = a;
>  /* line:9 */ c = x;
>   
>
> Now the exception provides information about the final class line
numbers.
> We still would need to obtaint the information as described. but we
could
> then also parse the comment to get the original line number an present
> that one in a nice exception. the malicious line highlighted with +/- 5
> lines. if there is no line number in comments we know it was introduced
by
> a logicsheet and might not be very helpful to display this way.
>
> But as I said... quite some hours of work...
>
> question is: do people think this is helpful?
>
> people? comments please...
> --
> Torsten


Yes. This would be definitely helpful. When I used lex/yacc their line
directives had me always pointing to the problem in my source.
When the logic sheets are matured, it's also unlikely, that the error
is in the logic sheet but not in your xsp.

I had a short look into this and there are two bugreports on this at Sun
which lead to a JSR. So this is definitely a problem, and having comments
in the generated code, which point me to the line and file the code
was generated from, would already help a lot.

http://developer.java.sun.com/developer/bugParade/bugs/4026902.html

http://developer.java.sun.com/developer/bugParade/bugs/4090367.html

http://jcp.org/jsr/detail/045.jsp



Jens

--

jens.lorenz at interface-projects dot de

interface:projects GmbH \\|//
Tolkewitzer Strasse 49  (o o)
01277 Dresden   oOOo~(_)~oOOo
Germany


-
Please check that your question has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>

map:redirect-to uri and parameters (maybe bug)

[Jens Lorenz]

Hi,


I've got problems using .
It seems that correctly quoted ampersands (%26) within value get
mysteriously unquoted when using RequestMatcher and redirect.

I'm using Cocoon-2.0.2 with Tomcat-4.0.1 on Win32. This has been
verified with IE, Mozilla and Opera.

I've prepared a sitemap to be dropped into cocoon/mount/redirect_debug.
It's attached to this mail.

If you call the pipeline "works" you get the complete parameter value
from the RequestGenerator with the ampersand. If you call the
pipeline "worksnot" the ampersand gets unquoted during the redirect
and the RequestGenerator accordingly cuts off the value.


Speaking sitemap terms ...

This redirect



produces these parameter


  
value&value
  


while these two redirects




  

  


produce these parameter


  
value
  



Here is a transcript with the important parts, from a TcpMonitor:

Listen Port: 
Target Port: 8080
 Request 
GET /cocoon/mount/redirect_debug/works HTTP/1.1
 Response 
HTTP/1.1 302 Moved Temporarily
Location:
http://localhost:/cocoon/mount/redirect_debug/showreq?param=value%26valu
e
 Request 
GET /cocoon/mount/redirect_debug/showreq?param=value%26value HTTP/1.1
 Response 

HTTP/1.1 200 OK
Content-Type: text/html
X-Cocoon-Version: 2.0.2


So far the correct one. Now the incorrect.


 Request 
GET /cocoon/mount/redirect_debug/worksnot HTTP/1.1
 Response 
HTTP/1.1 302 Moved Temporarily
Location: http://localhost:/cocoon/mount/redirect_debug/first
 Request 
GET /cocoon/mount/redirect_debug/first HTTP/1.1
 Response 

HTTP/1.1 302 Moved Temporarily
Location:
http://localhost:/cocoon/mount/redirect_debug/second?param=value%26value
 Request 
GET /cocoon/mount/redirect_debug/second?param=value%26value HTTP/1.1
 Response 

HTTP/1.1 302 Moved Temporarily
Location:
http://localhost:/cocoon/mount/redirect_debug/showreq?param=value&value
 Request 
GET /cocoon/mount/redirect_debug/showreq?param=value&value HTTP/1.1
 Response 

HTTP/1.1 200 OK
Content-Type: text/html
X-Cocoon-Version: 2.0.2



As you can see, the redirect after the RequestMatcher unquotes the quoted
ampersand.


I've had a short look into the Cocoon-Sources, but were unable to see
anything (because my knowledge of cocoon internals is limited). Maybe
it's also an Tomcat issue ...



Does anyone got an idea ?



Regards,


Jens

--

jens.lorenz at interface-projects dot de

interface:projects GmbH \\|//
Tolkewitzer Strasse 49  (o o)
01277 Dresden   oOOo~(_)~oOOo
Germany



sitemap.xmap
Description: Binary data

-
Please check that your question has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>