RE: Woody textareas?
-Original Message- From: Simon Price [mailto:[EMAIL PROTECTED] Sent: Montag, 30. Juni 2003 20:04 ... Cocoon's form handling is (imho) it's weakest area at present although it is rapidly improving with the interplay between flow and xmlform. ... Simon Luke Penca wrote: Are textareas implemented in Woody yet? I cannot find anything in the (oh so sparse) documentation. Furthermore, has anyone used Woody extensively yet? (I know, I know, it's alpha at this point but I need some serious forms handling.) Should I be considering Xforms instead? Who got some experience getting their hands bloodied with forms in Cocoon? I'm ever anxious to find out. ... Luke. I've just started prototyping with Woody and I think it is a diamond in the raw. Finally a form handling package that does not require you to write a bean class or Cocoon action for every little form! Coming to the original question: There is no special textarea widget but you can emulate it easily by a field widget with styling: wt:widget id=question xhtml:textarea rows=5 cols=30 wrap=physical/ /wt:widget which is then transformed into HTML as: xsl:template match=wi:field[wi:styling/xhtml:textarea] xhtml:textarea name=[EMAIL PROTECTED] xsl:apply-templates select=wi:styling/xhtml:textarea/@*/ xsl:choose xsl:when test=wi:value != '' xsl:value-of select=wi:value/ /xsl:when xsl:otherwise xsl:value-of select='#160;'/ /xsl:otherwise /xsl:choose /xhtml:textarea /xsl:template HTH, ALfred. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The senders company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the senders company. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Cocoon 2.1 migration problem with sub-sitemap
Did you add map:pipes to the map:components section in the root sitemap? -Original Message- From: Peter Klotz [mailto:[EMAIL PROTECTED] Sent: Mittwoch, 18. Juni 2003 11:48 To: [EMAIL PROTECTED] Subject: Cocoon 2.1 migration problem with sub-sitemap Hi, I have migrated a sub-sitemap from Cocoon 2.0.4 to 2.1m3. With 2.0.4 everything worked fine, now with 2.1 I only get empty pages. The reason seems to be that the sub-sitemap in cocoon/sims is never really called. Whenever I call a URL with sims/something I get empty page with NO errors although in logkit.xconf I have set everything on DEBUG. I saw one big difference between 2.0.4 and 2.1 and that is that sub-sitemaps seem to be automatically mounted with a generic pipeline. The sub-sitemap example does not exist anymore, the only sub-sitemap available is samples. Does one have to declare now really ALL components in each sub-sitemap that it uses, because I get DEBUG messages that say that a Selector has not found component for hint [request] or [session] for example? But when I look into the samples sitemap then that does not declare any components although it definitely uses some? So what is different in 2.1? Please help, Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: retaining data from a partial pipeline for subsequent requests
-Original Message- From: Anoop Aryal [mailto:[EMAIL PROTECTED] ... Wishful/hopeful thinking: - something like this would be optimal: Generators:A B C | | | --- | Aggregation: D | Transformation: E - tee* -- | | --| ||| || Formatting: rtf xsl pdfhtml**| | | formatted as a png/jpg/svg and stored in cocoon cache using a unique key** for the subsiquent request *) tee as in make a copy and pass one copy to the html formatting step. and another to the image formatting step. **) the key would be predetermined so that the src element in the html would know which image url to put in. and another pipeline would deal with requests for images keyed off this way. I'd say Read/WriteDOMSessionTransformer is your missing tee-piece. http://cocoon.apache.org/2.1/userdocs/transformers/writedomsession-trans former.html In the HTML pipeline, you copy the data into the session context with WriteDOM and pick it up again in the GIF pipeline with ReadDOM. HTH, Alfred. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: extracting xml-code out of a relational database
-Original Message- From: [EMAIL PROTECTED] I'm using Cocoon 2.1m2. I tried to use a logicsheet with esql and its esql:get-xml but I'm getting only undefined errors when trying to access the data of the text field. esql:get-xml is broken in M2. You need to get esql.xsl from HEAD. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20658 Cheers, Alfred. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Basic authentication
This sort of thing is usually done by an upstream Apache or in the servlet engine (Tomcat) configuration. If you really want to do it in Cocoon, you can write an action checking the BA header and use it in the sitemap to either deliver the resource or the auth-required (403) response. HTH, Alfred. -Original Message- From: Peter Flynn [mailto:[EMAIL PROTECTED] Sent: Montag, 16. Juni 2003 22:40 To: [EMAIL PROTECTED] Subject: Basic authentication I have failed to find anything in the docs about implementing crude Apache-style authentication (eg equivalent to .htaccess). We don't have any global auth framework yet, so the more sophisticated methods won't be applicable. The user requirement is simply to restrict some directories to user/psw pairs like we did before :-) Can someone point me at what I must have missed? I guess I could fake it up (although I don't know how to call crypt() from within an XSLT script) but I felt there is probably a better way... ///Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Eclipse compiler and complex XSPs
I am currently trying M2 to prepare our Cocoon based websites for
2.1final and came across a problem with the Eclipse compiler.
Out most complex XSP+logicsheet fails with the message:
=
org.apache.cocoon.ProcessingException: Language Exception:
org.apache.cocoon.components.language.LanguageException: Error compiling
iblform_generator_xsp:
ERROR 1
(org/apache/cocoon/www/swx_cocoon/logic/ibl/iblform_generator_xsp.java):
...
/**
* Generate XML data.
*/
// start error (lines 103-103) The code of method generate() is
exceeding the 65535 bytes limit
public void generate() throws SAXException, IOException,
ProcessingException {
// end error
this.contentHandler.startDocument();
...
Line 103, column 0: The code of method generate() is exceeding the 65535
bytes limit
===
NB this is a standard Java limit. Each method has its own 16-bit
address space for the JVM bytecode.
We already had similar trouble with the Pizza compiler but always
managed to shrink the XSP generated Java and stay below the limit on the
method size.
Since Eclipse is now the proposed default XSP Java compiler, I
investigated and found that it is in the Eclipse design to produce
slightly larger bytecode:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=38637
As workaround, for the moment I am going to revert to Pizza in my
cocoon.xconf for 2.1final:
parameter name=compiler
value=org.apache.cocoon.components.language.programming.java.Pizza/
!--parameter name=compiler
value=org.apache.cocoon.components.language.programming.java.Jikes/--
!--parameter name=compiler
value=org.apache.cocoon.components.language.programming.java.EclipseJav
aCompiler/--
In the near future we need to extend the functionality of our XSP by
more than just a few percent. I have some ideas how to push the XSP
limit by an order of magnitude. But it means going into the guts of
Cocoon (xsp.xsl), and I wouldn't want to hold up 2.1final for it.
Anyone else experiencing the same problem?
Cheers, Alfred.
This message is for the named person's use only. It may contain
confidential, proprietary or legally privileged information. No
confidentiality or privilege is waived or lost by any mistransmission.
If you receive this message in error, please notify the sender urgently
and then immediately delete the message and any copies of it from your
system. Please also immediately destroy any hardcopies of the message.
You must not, directly or indirectly, use, disclose, distribute, print,
or copy any part of this message if you are not the intended recipient.
The sender's company reserves the right to monitor all e-mail
communications through their networks. Any views expressed in this
message are those of the individual sender, except where the message
states otherwise and the sender is authorised to state them to be the
views of the sender's company.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: conditional cincludes?
Or cinclude another pipeline match to return a XML dummy file
cinclude src=cocoon:/maybeexists/foo.xml/
map:match pattern=maybeexists/**
map:act type=resource-exists src={1}
map:generate type=file src={../1}/
map:serialize type=xml/
/map:act
map:generate type=file src=notfound.xml/
map:serialize type=xml/
/map:match
HTH, Alfred (preferring cinclude over xinclude).
-Original Message-
From: Joerg Heinicke [mailto:[EMAIL PROTECTED]
Sent: Dienstag, 10. Juni 2003 22:23
To: [EMAIL PROTECTED]
Subject: Re: conditional cincludes?
Hello Luke,
you can either use the DirectoryGenerator or the new
implementation of
XInclude in Cocoon 2.1 having a fallback element.
Joerg
Luke Penca wrote:
How do I check for the instance of a file before attempting
to cinclude
it? Basically, I don't want the pipeline to die if the
file isn't found.
Thanks,
Luke.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message is for the named person's use only. It may contain
confidential, proprietary or legally privileged information. No
confidentiality or privilege is waived or lost by any mistransmission.
If you receive this message in error, please notify the sender urgently
and then immediately delete the message and any copies of it from your
system. Please also immediately destroy any hardcopies of the message.
You must not, directly or indirectly, use, disclose, distribute, print,
or copy any part of this message if you are not the intended recipient.
The sender's company reserves the right to monitor all e-mail
communications through their networks. Any views expressed in this
message are those of the individual sender, except where the message
states otherwise and the sender is authorised to state them to be the
views of the sender's company.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: pass parameters to internal pipeline
Try this:
map:match pattern=test/ParamToAgg.xml
map:generate src=cocoon:/test/getParam.xml/paramTest=a param value
9876/
map:serialize type=xml/
/map:match
map:match pattern=test/getParam.xml/*=*
map:generate src=myDev/test/dummy.xml/
map:transform src=myDev/xsl/getParam.xsl
map:parameter name={1} value={2}/
/map:transform
map:serialize type=xml/
/map:match
HTH, Alfred.
-Original Message-
From: I-Lin Kuo [mailto:[EMAIL PROTECTED]
Sent: Sonntag, 2. März 2003 13:18
To: [EMAIL PROTECTED]
Subject: pass parameters to internal pipeline
Is it possible to pass parameters to an internal pipeline?
This doesn't work for me:
map:match pattern=test/ParamToAgg.xml
map:generate src=cocoon:/test/getParam.xml
map:parameter name=paramTest value=a param value 9876/
/map:generate
map:serialize type=xml/
/map:match
map:match pattern=test/getParam.xml
map:generate src=myDev/test/dummy.xml/
map:transform src=myDev/xsl/getParam.xsl/
map:serialize type=xml/
/map:match
P.S. Just to be sure that I haven't made any dumb mistakes, I've checked
that I have a top-level xsl:param in my style sheet getParam.xsl which
picks
up the parameter from the following pipeline:
map:match pattern=test/getParam.xml
map:generate src=myDev/test/dummy.xml/
map:transform src=myDev/xsl/getParam.xsl
map:parameter name=paramTest value=1234/
/map:transform
map:serialize type=xml/
/map:match
I-Lin Kuo, Ann Arbor, MI
Macromedia Certified ColdFusion 5.0 Advanced Developer
Sun Certified Java 2 Programmer
Ann Arbor Java Users Group (http://www.aajug.org)
_
The new MSN 8: smart spam protection and 2 months FREE*
http://join.msn.com/?page=features/junkmail
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message is for the named person's use only. It may contain
confidential, proprietary or legally privileged information. No
confidentiality or privilege is waived or lost by any mistransmission.
If you receive this message in error, please notify the sender urgently
and then immediately delete the message and any copies of it from your
system. Please also immediately destroy any hardcopies of the message.
You must not, directly or indirectly, use, disclose, distribute, print,
or copy any part of this message if you are not the intended recipient.
The sender's company reserves the right to monitor all e-mail
communications through their networks. Any views expressed in this
message are those of the individual sender, except where the message
states otherwise and the sender is authorised to state them to be the
views of the sender's company.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: redirect's never return...
I think that you assume that cocoon:/directory/../_navigation.xml should
be
contracted to cocoon:/_navigation.xml and therefore match the first
pattern.
(Cocoon doesn't do this contraction for the good reason that /foo/bar/..
is not the same as /foo if /foo/bar is a symbolic link.)
So what is that the redirect-to matches the second pattern as
directory/../_navigation.xml, then as directory/../../_navigation.xml
in an infinite recursion.
What you need to do, is to have three patterns:
map:match pattern=_navigation.xml
map:generate src={defaults:content}/_null-navigation.xml/
map:serialize type=xml/
/map:match
map:match pattern=*/_navigation.xml
map:act type=resource-exists
map:parameter name=url
value={defaults:content}/{1}/_navigation.xml/
map:generate src={defaults:content}/{../1}/_navigation.xml/
map:transform src={defaults:design}/nav2xhtml.xsl/
map:serialize type=xml/
/map:act
map:redirect-to uri=cocoon:/_navigation.xml/
/map:match
map:match pattern=**/*/_navigation.xml
map:act type=resource-exists
map:parameter name=url
value={defaults:content}/{1}/{2}/_navigation.xml/
map:generate src={defaults:content}/{../1}/{../2}/_navigation.xml/
map:transform src={defaults:design}/nav2xhtml.xsl/
map:serialize type=xml/
/map:act
map:redirect-to uri=cocoon:/{1}/_navigation.xml/
/map:match
This duplication of code may make you shudder too much. I'm sure there
are
also more elegant solutions using a regexp matcher or map:call. But it
will hardly require less lines.
HTH, Alfred.
-Original Message-
From: Ben Young [mailto:[EMAIL PROTECTED]
Sent: Dienstag, 25. Februar 2003 19:49
To: [EMAIL PROTECTED]
Subject: map:redirect's never return...
I have built a looping matcher in my root sitemap.xmap.
map:match pattern=_navigation.xml
map:generate src={defaults:content}/_null-navigation.xml/
map:serialize type=xml/
/map:match
map:match pattern=**/_navigation.xml
map:act type=resource-exists
map:parameter name=url
value={defaults:content}/{1}/_navigation.xml/
map:generate src={defaults:content}/{../1}/_navigation.xml/
map:transform src={defaults:design}/nav2xhtml.xsl/
map:serialize type=xml/
/map:act
map:redirect-to uri=cocoon:/{1}/../_navigation.xml/
/map:match
These matchers let you select part of use the cocoon:// psuedo-protocol
to
select the nearest _navigation.xml file. This allows the page to
inherit
the navigation from one of it's predecessors.
This works fine so long as I request it from the root sitemap (e.g.,
cocoon:/). If I request the _navigation.xml from a sub-sitemap, I get
a
StackOverflow error. It's almost as if the lopping some how changes the
context to the point that it never returns to the sub-sitemap.
Requesting a
cocoon:/directory/_navigation.xml in a cinclude tag cause the same sort
of
error.
Thanks for your help in advance,
Ben
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message is for the named person's use only. It may contain
confidential, proprietary or legally privileged information. No
confidentiality or privilege is waived or lost by any mistransmission.
If you receive this message in error, please notify the sender urgently
and then immediately delete the message and any copies of it from your
system. Please also immediately destroy any hardcopies of the message.
You must not, directly or indirectly, use, disclose, distribute, print,
or copy any part of this message if you are not the intended recipient.
The sender's company reserves the right to monitor all e-mail
communications through their networks. Any views expressed in this
message are those of the individual sender, except where the message
states otherwise and the sender is authorised to state them to be the
views of the sender's company.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Pass custom parameters into an XSP
Actually, you don't need to override
setup().
The
base class ofthe XSP generated class already does that and provides
"protected Parameters parameters;"
You
can use directly in xsp:logic
String
entityType = this.parameters.getParameter("entityType");
including the other nice features of
Parameterssuch asdefaulting and converting to int, boolean, and so
on.
-Original Message-From: Collin VanDyck
[mailto:[EMAIL PROTECTED]]Sent: Donnerstag, 13. Februar 2003
00:04To: [EMAIL PROTECTED]Cc: David
CummingsSubject: Re: Pass custom parameters into an
XSP
Wow. I did not know you could use the XSP to
override the setup method. That is VERY helpful. Thanks!!
- Original Message -
From:
Marco Rolappe
To: [EMAIL PROTECTED]
Sent: Wednesday, February 12, 2003 5:59
PM
Subject: AW: Pass custom parameters
into an XSP
hi
collin,
with XSPs an easier alternative would be to pass your 'parameter' as
a request parameter.
then you would:
map:match pattern="edit.xml"
map:generate type="serverpages"
src=""/
map:serialize type="xml"/
/map:match
map:match pattern="edit/*"
map:generate
src=""/
...
/map:match
then you can get the request parameter from within your XSP via the
request logicsheet (xsp-request:get-parameter) or via embedded logic
(request.getParameter ()).
the other alternative; passing the parameter as a sitemap
parameter:
map:match pattern="edit/*"
map:generate type="serverpages"
src=""
map:parameter name="entityType"
value="{1}"/
/map:generate
...
/map:match
for this to work you have to embed the appropriate logic into your
XSP for retrieving that parameter; as your compiled XSP is a generator in
the end you accomplish this by overriding its setup() method and process the
parameter(s) there.
just as a hint (take a look at the respective
sources/docs):
xsp:page language="java" ...
xsp:logic !-- must occur before content
so that it doesn't become part of content/generate() method
--
public void setup (SourceResolver resolver, Map
objectModel, String src, Parameters params) throws ...
{
// process parameter(s)
here
...
super.setup (resolver, objectModel, src,
params);
}
/xsp:logic
!-- content here --
/xsp:page
HTH
-Ursprüngliche Nachricht-Von:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]Im
Auftrag von Collin VanDyckGesendet: Mittwoch, 12. Februar
2003 22:44An: [EMAIL PROTECTED]Betreff:
Pass custom parameters into an XSP
Hello,
I am trying to figure out how I can pass in
custom parameters into an already existing generator such as the
XSP/serverpages generator. Here's my scenario:
I receive a request for
/edit/page
Which matches /edit/*
So from this matcher, I have {1} == "page"..
I want to pass this off to let's say
/docs/xsp/edit/item.xsp as a parameter
named "entityType"
So that in the XSP I can access the
"entityType" variable.
I think I'm missing something obvious. If
someone could point me into the right direction, I'd really appreciate
it.
thanks,
Collin
This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
RE: Simple XSP Ordering Problem
-Original Message- From: Sonny Sukumar [mailto:[EMAIL PROTECTED]] Sent: Montag, 14. Oktober 2002 21:56 To: [EMAIL PROTECTED] Subject: Simple XSP Ordering Problem Product xsp:logic String productId = xsp-request:get-parameter name=productid default=/; /xsp:logic ... Try: xsp:logic String productId = request.getParameter(productid); if (productId == null ) productId = ; /xsp:logic Cheers, Alfred. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company. - 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]
