Il giorno 27/gen/06, alle ore 21:10, Leszek Gawron ha scritto:
One more thing: this construct
${java.util.StringTokenizer(items, delims)}
will work only when .jx is invoked from flow. This is due to the
fact that neither JEXL nor JXPath is able to reference packages/
create java objects.
Daniel Fagerstrom wrote:
Carsten Ziegeler skrev:
Daniel Fagerstrom wrote:
I suggested that we should ditch our environment abstraction and
replace it with the javax.servlet.http set of interfaces, as one step
in simplifying Cocoon in
http://marc.theaimsgroup.com/?t=11343238821r=1w=2.
Tim Williams wrote:
I want the image reader to accept a variant name (e.g. thumb,
small) and then write the newly created image variant to disk before
sending the output. In other words, so that a given image
IMG001.jpg might be read with a variant thumb and on disk would
now be:
IMG001.jpg
Trying it again ;)
When exactly is the EnterSitemapEventListener in
Cocoon 2.2 notified I hope with every request before Actions are
invoked?
Can I somehow emulate that concept in Cocoon 2.1.8,
or is there no chance?
I just need a notification with every request before
the
Upayavira wrote:
Daniel Fagerstrom wrote:
Carsten Ziegeler skrev:
...
First, I'm still not sure if this should go into the current 2.2 code
base, but apart from that I now think we should even be more radical in
this area and remove the whole environment abstraction completly and
make
Hello,
I upgraded two webapps from Coccon 2.1.7 to 2.1.8 lately...
And I found this thread intriguing, so I have added the following to one
of my existing JX templates (which is run through a JX generator pipeline,
invoked by flowscript):
p
jx:set var=items value=alpha,beta,gamma/
Failed to execute pipeline: java.util.NoSuchElementException
Key: COCOON-1743
URL: http://issues.apache.org/jira/browse/COCOON-1743
Project: Cocoon
Type: Bug
Components: Blocks: Portal
Reporter:
Daniel Fagerstrom wrote:
Upayavira wrote:
Daniel Fagerstrom wrote:
Carsten Ziegeler skrev:
...
First, I'm still not sure if this should go into the current 2.2 code
base, but apart from that I now think we should even be more radical in
this area and remove the whole
Ugo Cei wrote:
Our docs [1] state that something like:
jx:forEach var=${var}
items=${java.util.StringTokenizer(items, delims)}
/jx:forEach
should work. However, that doesn't seem to be the case, at least in
2.1.8 while it apparently worked before. I did a few more tests and
On Monday 30 January 2006 18:00, Upayavira wrote:
Well, sounds like you're trying to achieve something similar to caching.
I wonder if the caching system might be an alternative approach to
achieving the same thing.
There is an ImageOpReader sitting in JIRA[1] as a contribution, which didn't
On 1/30/06, Upayavira [EMAIL PROTECTED] wrote:
Tim Williams wrote:
I want the image reader to accept a variant name (e.g. thumb,
small) and then write the newly created image variant to disk before
sending the output. In other words, so that a given image
IMG001.jpg might be read with a
Tim Williams wrote:
On 1/30/06, Upayavira [EMAIL PROTECTED] wrote:
Tim Williams wrote:
I want the image reader to accept a variant name (e.g. thumb,
small) and then write the newly created image variant to disk before
sending the output. In other words, so that a given image
IMG001.jpg might
NullPointerException in template block
--
Key: COCOON-1744
URL: http://issues.apache.org/jira/browse/COCOON-1744
Project: Cocoon
Type: Bug
Components: Blocks: Templating
Versions: 2.2-dev (Current SVN)
Reporter:
Hello everybody,
One of my coworkers recently commented that Cocoon's sitemap files
were really programs in the xmap language, rather than documents,
and that as a language xmap is awkward and not very expressive. He
suggested that the sitemaps should instead be written in a general
purpose
Bob Harner wrote:
Hello everybody,
One of my coworkers recently commented that Cocoon's sitemap files
were really programs in the xmap language, rather than documents,
and that as a language xmap is awkward and not very expressive.
That's right: sitemap is programming language specialized in
Sylvain Wallez wrote:
Sorry, what do you mean by web framework? Isn't it already one? Or do
you mean servlet?
Cocoon is currently a mixture. It's mostly used as a web framework
through a servlet, but for example if you're using the cli you don't
have a web framework or a web server or
Daniel Fagerstrom wrote:
Agree, but as people (you included) had valid reasons for not going that
far in 2.2, I suggest something less radical this time, as I want to get
rid of the problem of calling servlets from within Cocoon already in 2.2.
Yes, true, I had reasons against doing radical
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Sorry, what do you mean by web framework? Isn't it already one? Or do
you mean servlet?
Cocoon is currently a mixture. It's mostly used as a web framework
through a servlet, but for example if you're using the cli you don't
have a web
Sylvain Wallez wrote:
Hmm... Not sure if I misunderstood or not. I'm ok to have a CLI-based
implementation of the servlet API, but having the Cocoon CLI launching
an internal Jetty for this really seems wrong to me. Forrest is already
a large beast, now if you say that generating a site
On 1/30/06, Carsten Ziegeler [EMAIL PROTECTED] wrote:
Now, if I'm the only one thinking that removing the whole env
abstraction makes sense, I'll shut up for now.
Nope. Makes perfect sense to me, please continue on this crusade.
--
Peter Hunsberger
[
http://issues.apache.org/jira/browse/COCOON-1049?page=comments#action_12364504
]
Christopher Schultz commented on COCOON-1049:
-
It turns out that there's a workaround for this problem (see below).
I had assumed that with a serializer such
Sylvain Wallez wrote:
Ugo Cei wrote:
Our docs [1] state that something like:
jx:forEach var=${var}
items=${java.util.StringTokenizer(items, delims)}
/jx:forEach
should work. However, that doesn't seem to be the case, at least in
2.1.8 while it apparently worked before. I did a
Upayavira skrev:
Daniel Fagerstrom wrote:
Upayavira wrote:
...
It starts to look like a 3.0 rather than a 2.2 and my personal goal is
to implement the whole blocks design including OSGi. OTH I try to not
hinder the possibility for a 2.2 release, given that someone is prepared
to spearhead it.
Carsten Ziegeler skrev:
Daniel Fagerstrom wrote:
Agree, but as people (you included) had valid reasons for not going that
far in 2.2, I suggest something less radical this time, as I want to get
rid of the problem of calling servlets from within Cocoon already in 2.2.
Yes, true, I had
Sylvain Wallez skrev:
...
Now Cocoon is much more than a web framework, as we discussed in the
necessary mutation thread:
- a servlet
- a component container
- a controller
- a pipeline engine
- many blocks built on top of one of the above.
The CocoonBean used by the CLI is actually parallel
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Hmm... Not sure if I misunderstood or not. I'm ok to have a CLI-based
implementation of the servlet API, but having the Cocoon CLI launching
an internal Jetty for this really seems wrong to me. Forrest is already
a large beast, now if you say
Carsten Ziegeler skrev:
Sylvain Wallez wrote:
Hmm... Not sure if I misunderstood or not. I'm ok to have a CLI-based
implementation of the servlet API, but having the Cocoon CLI launching
an internal Jetty for this really seems wrong to me. Forrest is already
a large beast, now if you say that
27 matches
Mail list logo
