Current CVS does not compile here, looks like the PageLocalScopeHolder
class source code is missing:
src/java/org/apache/cocoon/components/flow/javascript/fom/
FOM_Cocoon.java:238: cannot resolve symbol
symbol : class PageLocalScopeHolder
location: class
Sorry, my bad. Should be fixed now.
Bertrand Delacretaz wrote:
Current CVS does not compile here, looks like the
PageLocalScopeHolder class source code is missing:
src/java/org/apache/cocoon/components/flow/javascript/fom/
FOM_Cocoon.java:238: cannot resolve symbol
symbol : class
Darn. Meant for this to go to the list, not to you directly.
-Original Message-
From: Ralph Goers
To: 'Joerg Heinicke '
Sent: 1/27/2004 9:06 PM
Subject: RE: [proposal] Cleaning up our component library
I realise I am fairly new to Cocoon and my opinion probably doesn't
carry as much
Sorry, my bad. Should be fixed now.
it is - thanks!
-Bertrand
Le Mercredi, 28 jan 2004, à 02:40 Europe/Zurich, Joerg Heinicke a écrit
:
One problem often mentioned is that Cocoon provides to many
possibilities to achieve some goals. Cocoon's flexibility ends where
it is more confusing than helpful. Therefore I want to propose to
remove/deprecate the
On Wed, 2004-01-28 at 08:43, Ralph Goers wrote:
snip/
We'd love to use Woody (aka Cocoon Forms), but if it can be used without
FlowScript it isn't obvious. So we will be using the
SimpleFormTransformer etc., for the forseeable future.
Woody doesn't require flowscript. While flowscript
Sylvain Wallez wrote:
Two suggestions regarding sourceResolver and redirector:
SourceResolver (the Cocoon one) is a legacy requirement because we can't
change the interface of actions, generators, etc, and is used by the
Processor (for Actions) and the pipelines (for
On Jan 28, 2004, at 8:43 AM, Ralph Goers wrote:
We'd love to use Woody (aka Cocoon Forms), but if it can be used
without
FlowScript it isn't obvious.
Woody and FlowScript should be totally independent from each other.
Much of the fun stuff lately has been done in the JS utility library,
but
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Two suggestions regarding sourceResolver and redirector:
SourceResolver (the Cocoon one) is a legacy requirement because we
can't change the interface of actions, generators, etc, and
is used by
the Processor (for Actions) and the
Joerg Heinicke wrote:
On 27.01.2004 17:08, [EMAIL PROTECTED] wrote:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25356
[Slide block] Revamping of Slide integration
[EMAIL PROTECTED] changed:
What|Removed |Added
Lars,
Can you tell me what software you use to run your tests? Is that Siege from
http://joedog.org/siege/index.php? I would like to run the same configuration to see
how my settings perform.
If more people could run the same test we could make a nice graph of what platform /
config runs
Unico Hommes wrote:
The Processor currently is already available to a ProcessingNode from
the Context so a ProcessingNode implementing Contextualizable will be
able to get to the EnvironmentHelper via that route.
Ah, ok, so what do you think of using that then?
I just noticed that the key
Carsten Ziegeler wrote:
Unico Hommes wrote:
The Processor currently is already available to a
ProcessingNode from
the Context so a ProcessingNode implementing
Contextualizable will be
able to get to the EnvironmentHelper via that route.
Ah, ok, so what do you think of using
Hello,
Is there a way to test the cocoon component without the need to do HTTP
requests?
--
Leszek Gawron
Unico Hommes wrote:
Ah, ok, so what do you think of using that then?
I just noticed that the key for the processor is just
treeprocessor, what do you think of using a more qualified
name like org.apache.cocoon.Processor or the name of the
implementation?
Yes, that was still a TODO
Bertrand Delacretaz wrote:
Le Mercredi, 28 jan 2004, à 02:40 Europe/Zurich, Joerg Heinicke a écrit :
[...]
...I propose to deprecate those components in 2.1 and to remove them
in 2.2...
In cases where this just needs sitemap changes, no problem. But if
deprecation requires code changes to
Hi!
We have some strange effects here.
It seems that the lastmodified header set by the ResourceReader only
sometimes
reflects the actual Last-Modified Timestamp from the file system.
Most of the time the last modified header is set to the current time.
Which has the effect that the browsers
On 28.01.2004 10:55, Andreas Hartmann wrote:
b) maybe add an option to throw an exception when such components are
used (strict deprecation)
This sounds very useful. There are some non-IDE users in
our community who aren't that much aware of deprecation.
Could it be switched on/off globally?
On 28.01.2004 07:52, Bertrand Delacretaz wrote:
One problem often mentioned is that Cocoon provides to many
possibilities to achieve some goals. Cocoon's flexibility ends where
it is more confusing than helpful. Therefore I want to propose to
remove/deprecate the components that are no longer
Leszek Gawron wrote:
Hello,
Is there a way to test the cocoon component without the need to do HTTP
requests?
Of course. Look into src/test and specifically
o.a.c.SitemapComponentTestCase.
Ugo
Hi Arje,
you're right. We use the tool from http://joedog.org/siege/index.php. I have
updated the Scenario 1 page in the Wiki on how to use it and attached the
awk script that generates the ... pages delivered in interval ... as well.
Best regards
Lars
-Ursprüngliche Nachricht-
From: Joerg Heinicke
One problem often mentioned is that Cocoon provides to many
possibilities to achieve some goals. Cocoon's flexibility
ends where it
is more confusing than helpful. Therefore I want to propose to
remove/deprecate the components that are no longer the correct way to
snip/
For Eclipse really EVERYTHING seems to be available :) I prefer the
integration into the browser, not the IDE.
I use Newsmonster (http://www.newsmonster.org/) which is a Mozilla
plugin. It isn't free of bugs (maybe using a newer Firebird or Mozilla
version or the use of the commercial
This error ocurr frecuently but in list mailing
what i visited isn't the definitive solution.
Only i found to copy jasper-compiler.jar in
/WEB-INF/lib/ but it don't succeed.
Any idea?
Thanks
Best desires
-- Elvira Nieto
Carretero Isotrol, S.A.
Joerg Heinicke wrote:
So alltogether:
a) Components that are just renamed or replaced with only sitemap
changes (FileGenerator = XMLGenerator, DirectoryGenerator =
TraversableGenerator (or however it is called ;-) ), StreamGenerator =
XMLGenerator + ModuleSource) are deprecated in 2.1
I have a little problem when setting a value of a Woody widget which is type
integer in the FlowScript:
Tried to set value of output widget repeater.offset with an object of an
incorrect type: expected class java.lang.Integer, received class
java.lang.Double.
The JavaScript code is simple:
Carsten Ziegeler wrote:
Joerg Heinicke wrote:
So alltogether:
a) Components that are just renamed or replaced with only sitemap
changes (FileGenerator = XMLGenerator, DirectoryGenerator =
TraversableGenerator (or however it is called ;-) ), StreamGenerator =
XMLGenerator + ModuleSource)
Which scheme implementation was used for the original implementation of
flow, or did somebody create their own?
Is it still available?
Thanks!
-Brian
Harald Wehr wrote:
Hi Vadim,
sorry for writing directly to you, but I did not get an answer to my
posting to the developer list.
Well, you have to have a bit more patience.
I generally agree that image input handling should be present in this
way or another in the Woody, but I currently do
Gernot Koller wrote:
Hi!
We have some strange effects here.
It seems that the lastmodified header set by the ResourceReader only
sometimes
reflects the actual Last-Modified Timestamp from the file system.
...
This is Cocoon Version 2.1-M2-dev running on IBM Websphere 4.0 under zOS
Any
(Stephan asked to post this
in the dev maillist)
I've tried to
just call the function (like your suggestion), but when I havean apple
and call it, it gives an error because it looks for a
_javascript_:org.apache.cocoon.ResourceNotFoundException:
Function"_javascript_:Package.MyClass()"I'm
Brian McCallister wrote:
Which scheme implementation was used for the original implementation
of flow, or did somebody create their own?
Is it still available?
It was removed. You can get it from the Attic:
From: Brian McCallister
Which scheme implementation was used for the original
implementation of
flow, or did somebody create their own?
Is it still available?
IIRC it was SISC (http://sisc.sourceforge.net/)
--
Reinhard
SISC http://sisc.sourceforge.net
Brian McCallister wrote:
Which scheme implementation was used for the original implementation
of flow, or did somebody create their own?
Is it still available?
Thanks!
-Brian
In Samples Cocoon is a example about to use JSP
with JSPGenerator and it happens somthing similar but with
JSPReader:
http://localhost:8080/cocoon/samples/jsp/
I modified my code using JSPGenerator and JSPReader
(equal what the sample cocoon) and i obtain "ServletException in
Ralph Goers [EMAIL PROTECTED] writes:
Our
environment has special security concerns that just won't
allow a scripting language - or even JSPs or XSPs for that
matter.
Ok, I'll bite; why single out scripting languages and dynamically
produced pages? What about dynamically compiled Java?
Jan Hoskens wrote:
(Stephan asked to post this in the dev maillist)
Jan,
JFYI: Dev does not read HTML mails. Please set your Microsoft Outlook
Express 6.00.2800.1158 to produce plain text email. Thanks ;-)
Vadim
PS Evidence:
--=_NextPart_000_0161_01C3E5A0.1C5841E0
Content-Type:
Vadim Gritsenko wrote:
Carsten Ziegeler wrote:
Joerg Heinicke wrote:
So alltogether:
a) Components that are just renamed or replaced with only sitemap
changes (FileGenerator = XMLGenerator, DirectoryGenerator =
TraversableGenerator (or however it is called ;-) ), StreamGenerator
=
Bruno Dumon wrote:
On Wed, 2004-01-28 at 08:43, Ralph Goers wrote:
snip/
We'd love to use Woody (aka Cocoon Forms), but if it can be used without
FlowScript it isn't obvious. So we will be using the
SimpleFormTransformer etc., for the forseeable future.
Woody doesn't require flowscript.
Erik Hofstra wrote:
Hi,
The data from a form is bound to a XML data model (with Woody). Now i want
to show this XML-document
After the form is submitted, right?
(with some kind of stylesheet) without having to
write it to a file first or with another (static) file: dynamically.
I think you
From: Carsten Ziegeler
Joerg Heinicke wrote:
So alltogether:
a) Components that are just renamed or replaced with only sitemap
changes (FileGenerator = XMLGenerator, DirectoryGenerator =
TraversableGenerator (or however it is called ;-) ),
StreamGenerator =
XMLGenerator +
I totally agree with this. I have focused totally on 2.1 in building our
system. For things to suddenly be deprecated now would be most irritating.
If 2.2 manages to make the process of building one's webapp easier with
real blocks, a lot of folks like me will want to switch to it just for
that.
Geoff Howard wrote:
Vadim Gritsenko wrote:
And we should only move things into the deprecated part if there is a
usable alternative. IMHO, using flow instead of a transformer isn't
really
an alternative as the overhead is way to much (just my opinion here).
-1 to replacing of
I thought actions were performed before generators and transformers? If so,
how could an action copy data from a generator or transformer?
Ralph
-Original Message-
From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 28, 2004 8:11 AM
To: [EMAIL PROTECTED]
Subject:
Hi Joerg,
i am think this is related with the datatype of Woody and Java
the datatype in woody integer is converter in java.lang.Integer
and the datatype in woody decimal is converter in java.math.BigDecimal
Joerg Heinicke Escribio :-)
I have a little problem when setting a value of a
Joerg Heinicke [EMAIL PROTECTED] proposes:
snip on discussion about components to be deprecated/
I propose to
deprecate
those components in 2.1 and to remove them in 2.2.
Yes please! As Cocoon grows it gets harder and harder to see the real
direction it is heading as long as it continues
Hi!
We have some strange effects here.
It seems that the lastmodified header set by the ResourceReader only
sometimes
reflects the actual Last-Modified Timestamp from the file system.
Most of the time the last modified header is set to the current time.
Which has the effect that the browsers
Christopher Oliver wrote:
Ok, I just committed changes that implement createWebContinuation().
The support for continuation local variables is also included.
It works! At least it seem to ;-)
Vadim
I'll admit that I didn't do the work evaluating Woody. My colleague
indicated he had problems figuring out how to get Woody bindings to work
without flow. If there are samples of that let me know and I'll have him
look at it again.
Thanks,
Ralph
-Original Message-
From: Steven Noels
Le Mercredi, 28 jan 2004, à 11:52 Europe/Zurich, Joerg Heinicke a écrit
:
...With our deprecated block we have another mean to lead the user to
the new components. When it's excluded the application will just not
work. But I don't know if this is true for 2.2 and real blocks too...
hmm...I
How hard would it be to make the CompilingClassLoader work for classes
within Cocoon, such as when working directly on the cforms classes?
Of course this would only be for use during development to shorten the
edit-compile-restart-test cycle.
--Tim Larson
I've just checked in some experimental improvements to the Woody
Flowscript API and an associated sample. Because the changes are not
backward compatible I've placed the files in a new package.
The idea is to try to remove the duplication present in the current API
in two places:
1) The
I tried to reproduce the error but the samples are running fine on my machine. Could
you provide more details about your environment? Cocoon version, Java version. Also
the stacktrace in the logs and on the console if any...
Unico
Elvira Nieto Carretero wrote:
In Samples Cocoon is a
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26460.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Leszek Gawron wrote:
Is there a way to test the cocoon component without the need to do HTTP
requests?
If you are talking about action, generator, serializer, etc. unit tests
take a look at src/test and SitemapComponentTestCase:
Ugo Cei wrote:
Of course. Look into src/test and specifically
o.a.c.SitemapComponentTestCase.
BTW: Can anybody interested in unit tests look at my post:
http://article.gmane.org/gmane.text.xml.cocoon.devel/29889
and answer the questions.
--
Wojciech Gdela
Vadim Gritsenko wrote:
Harald Wehr wrote:
Hi Vadim,
sorry for writing directly to you, but I did not get an answer to my
posting to the developer list.
Well, you have to have a bit more patience.
I generally agree that image input handling should be present in this
way or another in the
Carsten Ziegeler wrote:
Unico Hommes wrote:
Ah, ok, so what do you think of using that then?
I just noticed that the key for the processor is just
treeprocessor, what do you think of using a more qualified
name like org.apache.cocoon.Processor or the name of the
implementation?
Yes,
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23269.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
On 28.01.2004 16:44, Geoff Howard wrote:
So alltogether:
a) Components that are just renamed or replaced with only sitemap
changes (FileGenerator = XMLGenerator, DirectoryGenerator =
TraversableGenerator (or however it is called ;-) ), StreamGenerator
= XMLGenerator + ModuleSource) are
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26450.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26376.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
62 matches
Mail list logo
