Hi,
after another day of debuging, I was able to track down the main problem:
the JavaInterpreter fetches the WebContinuation and uses this to create
a new cocoon-flow-context each time it is executed.
The FormInstance is bound to this object and is used for executing the
display pipeline.
Hi,
For th last two weeks I was dealing with the problem, that
SuggestionLists didn't work with JavaFlow anymore. In addition to this,
also my Pipelines for saving form-data stopped workling.
I could track both of them down to the problem, that the JavaInterpreter
class constructs a
Vadim Gritsenko napisał(a):
Grzegorz Kossakowski wrote:
IIUC, generally this will not work. Suppose that you are calling this
simple sitemap:
map:generate src=file.xml/
map:act type=authenticate
map:act type=delete
map:transform src=file.xsl/
map:serialize
I'm trying to use the TreeWidget. Looking at the code I get the
impression that it's not implemented to the end (e.g. Tree binding is
not yet done, ValidationError is not implemented).
Are there any plans howto go on with the TreeWidget or does a
replacement exists?
What I need is a MS-Explorer
Maybe a solution is to state the content type in the *calling* sitemap. I
cannot imagine a situation where your postable source could result in
different content types. You want control over that, because you probably
continue processing the returned data in the calling sitemap and there you
Steven Noels schrieb:
I gave you editor and commit access on Daisy.
Thanks!
I added the document to daisy and also reworked the old stuff (now Further
information):
http://cocoon.zones.apache.org/daisy/cdocs-site-main/g3/1367/1366.html
I added it under Getting Better - How-Tos (the latter
Vadim Gritsenko skrev:
Grzegorz Kossakowski wrote:
Given that mime type (and other http header informations) are
calculated during setup phase of service's pipeline setup phase it's
guaranteed that this information can be properly determined without
providing any content (in service call,
PropertySettings does not support run-mode (but documents that it does)
---
Key: COCOON-2064
URL: https://issues.apache.org/jira/browse/COCOON-2064
Project: Cocoon
Issue
Grzegorz Kossakowski skrev:
Daniel Fagerstrom pisze:
Grzegorz Kossakowski skrev:
Looking at the AbstractProcessingPipeline the getMimeType method of
the serializer is called from the setMimeTypeForSerializer method
that in turn is called in the beginning of the processXMLPipeline
method
[
https://issues.apache.org/jira/browse/COCOON-2064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12495057
]
Ralph Goers commented on COCOON-2064:
-
I apologize. You are correct that running mode is not implemented. The
[
https://issues.apache.org/jira/browse/COCOON-2064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralph Goers reassigned COCOON-2064:
---
Assignee: Ralph Goers
PropertySettings does not support run-mode (but documents that it
Alexander Klimetschek skrev:
Maybe a solution is to state the content type in the *calling* sitemap. I
cannot imagine a situation where your postable source could result in
different content types. You want control over that, because you probably
continue processing the returned data in the
Daniel Fagerstrom napisał(a):
Grzegorz Kossakowski skrev:
Yes, I agree with idea and would like to violate its independence and
that's why I seek for other solution.
After sleeping with a problem in mind I guess that situation is not
such dramatic and you can be probably right that
Daniel Fagerstrom napisał(a):
Alexander Klimetschek skrev:
Maybe a solution is to state the content type in the *calling* sitemap. I
cannot imagine a situation where your postable source could result in
different content types. You want control over that, because you probably
continue
Daniel Fagerstrom napisał(a):
Exactly, an implicit, automatic HTTP HEAD handling would work for
sitemap rules that are idempotent (i.e. calling any number of times
gives the same result as calling once, which GET is supposed to be even
if that not always is the case). But for any sitemap with
[EMAIL PROTECTED] said the following on 11/5/07 16:59:
requireMavenVersion
- version[2.0.5,)/version
+ version[2.0.6,)/version
Looks odd: starting and ending brackets are different. Is this correct?
Bye, Helma
hepabolu napisał(a):
[EMAIL PROTECTED] said the following on 11/5/07 16:59:
requireMavenVersion
- version[2.0.5,)/version
+ version[2.0.6,)/version
Looks odd: starting and ending brackets are different. Is this correct?
Yes, that means
On 11.05.2007 19:34, hepabolu wrote:
[EMAIL PROTECTED] said the following on 11/5/07 16:59:
requireMavenVersion
- version[2.0.5,)/version
+ version[2.0.6,)/version
Looks odd: starting and ending brackets are different. Is this correct?
Yes:
Grzegorz Kossakowski wrote:
map:serialize type=servletService
map:parameter name=service value=servlet:forms:/renderForms/
/map:serialize
Just a nitpick, but I think this syntax would be sweeter:
map:serialize type=service src=servlet:forms:/renderForms/
Vadim
Grzegorz Kossakowski wrote:
Daniel Fagerstrom napisał(a):
Exactly, an implicit, automatic HTTP HEAD handling would work for
sitemap rules that are idempotent (i.e. calling any number of times
gives the same result as calling once, which GET is supposed to be
even if that not always is the
20 matches
Mail list logo
