Hi:
I found that FOP block depends on batik-block. FOP will not render nothig
if yu does not include the Batik block. Even if you does not have any SVG
graphics in your generated PDF.
I thinking about that and maybe we can improve the current block building
by creating a common repository for
On Wed, 20 Aug 2003, Jeremy Quinn wrote:
I cannot get this to work, I get:
org.apache.commons.jxpath.JXPathException: Invalid XPath:
'$parameters.getParameter(\publishedJobServer\)'. Syntax error after:
'$p'
If I try :
${$parameters.getParameter('publishedJobServer')}
Use:
Sylvain Wallez wrote:
I think this is something the internal processing should handle, which
means, if the reader sets such a header it should simply be ignored
instead of being passed on.
Now, I guess this is very easy as we could create a response wrapper
for internal requests (we already
cziegeler2003/08/20 23:41:19
Modified:src/blocks/portal/java/org/apache/cocoon/portal/impl
PortalServiceImpl.java
src/blocks/portal/java/org/apache/cocoon/portal/profile/impl
MapProfileLS.java
cziegeler2003/08/20 23:41:13
cocoon-2.1/src/blocks/portal/java/org/apache/cocoon/components/persistence - New
directory
On Wed, 20 Aug 2003, Chris Clark wrote:
Based on the samples, I've been looking at checkboxes in JXForms and have a few
questions...
Given the following snippet from an xform definition:
xf:select ref=validchecks appearance=full
xf:labelCheck if field is Present amp;
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
I think this is something the internal processing should handle, which
means, if the reader sets such a header it should simply be ignored
instead of being passed on.
Now, I guess this is very easy as we could create a response wrapper
for internal
Steven Noels wrote:
Leszek Gawron wrote:
I do not think it's a thing to be put into bugzilla so it goes here:
while the standard woody form example is fully functional the flow
version
does not allow you to add or remove a contact.
We've debugged this offline already (Marc and myself during
Hi All,
For my current client, I have implemented a JobManager and I am
wondering if it is general enough to be of interest to anyone else (ie.
commit it to Cocoon as a Block). It is not a proper avalon component
yet, so I would have to do this first.
The problem I needed to solve was this:
On Thursday, August 21, 2003, at 02:10 AM, Christopher Oliver wrote:
This is how you do it:
#{$parameters.getParameter(publishedJobServer)}
results in :
org.apache.commons.jxpath.JXPathException: Invalid XPath:
'$parameters.getParameter(\publishedJobServer\)'. Syntax error after:
'$p'
sylvain 2003/08/21 03:06:41
Modified:src/blocks/woody/java/org/apache/cocoon/woody/flow/javascript
woody.js
Log:
Fix the use of validator functions for event handling.
It's now called either if there's an actionCommand or if the validation succeeded.
On Thursday, August 21, 2003, at 10:27 AM, Unico Hommes wrote:
What build are you using. This wasn't working a few weeks ago but has
been fixed.
2.1.1-dev, a couple of days old.
regards Jeremy
Hugo Burm wrote:
I am trying to use the Woody sample that uses a Java bean for its binding
(form2bean.flow).
I want to store the contacts in this example in a map instead of in a list,
hm, the biggest problem I see with this 'storing in Map' is:
using which key?
Maybe you should elaborate on
oops!
considering:
myBean
address
hugostreet/city//hugo
marcstreet/city//marc
brunostreet/city//bruno
/address
/myBean
this:
and I'm not sure but probably
$myBean/* -- would give you the iteration of the 3 address nodes
should have been $myBean/address/* I guess (warning:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
One thing missing is passing information from the pipeline to the
components.
For example if you write this pipeline:
map:generate type=filteredFile src=afile.xml
map:parameter name=a parameter value=a value/
...
I assume that the src info and the
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
Phil Shafer wrote:
Vadim Gritsenko writes:
Try the suggestion above.
Will do. Thanks for the help. Is there a PR open for this? Should
I open one?
I think there is no bug open for this. Also, I'd ping Carsten to
Vadim Gritsenko wrote:
It could be convinient if it would work. But it does not.
map:generator name=filteredFile
map:aggregate
map:part src=a/
map:part src=b/
map:part src=c/
/map:aggregate
map:transform type=xslt src=a.xsl/
map:transform type=xslt
Sylvain Wallez wrote:
Steven Noels wrote:
Leszek Gawron wrote:
I do not think it's a thing to be put into bugzilla so it goes here:
while the standard woody form example is fully functional the flow
version
does not allow you to add or remove a contact.
We've debugged this offline already
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
Phil Shafer wrote:
Vadim Gritsenko writes:
Try the suggestion above.
Will do. Thanks for the help. Is there a PR open for this? Should
I open one?
I think there is no bug open for this.
cziegeler2003/08/21 05:44:18
Added: src/scratchpad/lib cornerstone-scheduler-api-20030821.jar
cornerstone-threads-impl-20030821.jar
excalibur-thread-1.1.1.jar
cornerstone-scheduler-impl-20030821.jar
I think there may be a bug then...
When I try to use a String array in my Java class, I get the following error:
Exception trying to set value with xpath validchecks; Cannot modify property:
elrsproto.FormBean.validchecks; Cannot convert value of class java.lang.String to type
class
On 21.Aug.2003 -- 02:50 PM, Steven Noels wrote:
Hi peeps,
Other than hacking too much infrastructural stuff into my little
flowapp, I wanted to reuse the SendMail Action from my script. It seems
however that this would require legacy.js to be finished. So I went to
check whether the
Timothy Larson wrote:
In woody.js [1] there was a change in version 1.6 that stopped calling:
cocoon.request.setAttribute(this.attrName, this.form);
and did this instead:
var bizData = { woody-form: this.form };
indeed, this lines up more with how flow is expected to be working
This will
Marc Portier wrote:
in terms of best practice I would probably be advocating the use of
jxtemplate in combinaion with flow rather then xsp
+1
JXTemplate is massive but works nice and dandy.
/Steven
--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source,
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
snip/
Now, I guess this is very easy as we could create a response wrapper
for internal requests (we already have a request wrapper) and filter
the headers.
This reminds me some random thoughts I had
I noticed in the Woody form1 sample that the drinks are
not marked required=true, but they act like they are
required because of their validation rule:
wd:validation
wd:value-count exact=2/
/wd:validation
It seems that if the field is not required and no drinks
are selected, then this
Hello Marc,
Ok. Let me explain. Maps are sometimes much more convenient than Lists
(let's skip a discussion on that one). So I have two classes:
public class HContact {
private String id;
private String firstName;
private String lastName;
private String phone;
private String
Sorry, my bad, the JXPath version should be this:
#{getParameter($parameters, 'publishedJobServer')}
and the Jexl version:
${parameters.getParameter('publishedJobServer')}
These do work (at least for me). The fact that you got no output from
the Jexl version would seem to indicate that the
IMO the change to use woody-form is very poor choice because its not a
valid Jexl identifier. This means that if you want to access it in
JXTemplate you have to use this syntax:
${flowContext['woody-form'].someWidget}
If you change it to say 'woodyForm' you can access it directly:
Steven Noels wrote:
... so basically I have two possible outcomes of my try{} block, each
calling another pipeline. I'm worried that the flowscript only
executes upto that sendPage, never reaching the conn.close() in the
finally{} block. Or does it?
/Steven
No, you're fine because
Why not use xf:itemset in this case instead of jx:forEach?
Giacomo Pati wrote:
On Thu, 21 Aug 2003, Chris Clark wrote:
I think there may be a bug then...
When I try to use a String array in my Java class, I get the following error:
Exception trying to set value with xpath validchecks;
Upayavira wrote:
Vadim has just fixed a bug with the persistent cache not shutting down
properly. This means that the CLI has access to the Cocoon cache.
For a largely static site, should now be possible to have the CLI
crawl a site, purely with the intention of building up the cache,
which
Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
It could be convinient if it would work. But it does not.
map:generator name=filteredFile
map:aggregate
map:part src=a/
map:part src=b/
map:part src=c/
/map:aggregate
map:transform type=xslt src=a.xsl/
map:transform
I'm using xf:itemset at the moment. Never seen the jx:ForEach before which gets back
to one of my original questions:
Are there any docs for jxForms yet? If so, where?
Regardless of whether I use the itemset or not, I can get my checkboxes to display
correctly on the screen.
The problem comes
Hi all,
How long will it takes to provide JXForms with a ActionFramework?
I red some posts about it. Will it be realized in next time?
Björn
Thanks for the help.
So far, this is the only way I have gotten this to work.
In the flow change:
cocoon.sendPage(success-pipeline);
to:
cocoon.sendPage(success-pipeline, {woody:form.getModel()});
and in a JXTemplate file use this syntax to get the value of the
name widget:
h3Name:
Jeremy Quinn wrote:
On Thursday, August 21, 2003, at 10:27 AM, Unico Hommes wrote:
What build are you using. This wasn't working a few weeks ago but has
been fixed.
2.1.1-dev, a couple of days old.
... and I'm running into the same problem, with HEAD from this afternoon.
sitemap:
Christian Haul wrote:
On 21.Aug.2003 -- 01:40 PM, Carsten Ziegeler wrote:
But, if you write
map:generate type=filteredFile src=something
then you can access it automatically as {src} rather than
writing
map:generate type=filteredFile
map:parameter name=src value=something/
We *will*
Oh, you're talking about cocoon.sendPage(). Well, yeah you have to pass
the object then. The way you did it is correct. Of course, you could
have simply passed the form widget itself:
cocoon.sendPage(success-pipeline, form.getModel());
h3${name}/h3
Most of this _is_ documented:
Hi:
Add a note about dependency on Batik
+note
+FOP block requires Batik block to be present for
generating PDF with embedded images. +/note
Sorry, but this is not correct:
FOP block requieres ALWAYS the batik block regardless of generating images
inside PDF
Timothy Larson dijo:
I noticed in the Woody form1 sample that the drinks are
not marked required=true, but they act like they are
required because of their validation rule:
wd:validation
wd:value-count exact=2/
/wd:validation
It seems that if the field is not required and no drinks
Joerg Heinicke dijo:
Vadim Gritsenko wrote:
[EMAIL PROTECTED] wrote:
joerg 2003/08/12 00:52:20
Modified:src/blocks/fop/lib fop-0.20.5.jar
Log:
rebuilt the jar with Cocoon's versions of Batik, XML apis, Avalon
framework
Revision ChangesPath
1.2 +4332
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
snip/
Actually it depends not on header type alone but on usage of the
resource. If it is aggregated to be part of the output - then I
agree with some of your thoughts below. But if it is, say, called
from the flow - none
43 matches
Mail list logo
