Title: RE: [RT] Getting rid of the table-based layout
YES! Please!
The current layout is not flexible at all and I for one would welcome a simple, CSS-based design.
I would do it myself if it wasn't for the time, or the lack thereof... ;-)
Koen
-Original Message-
From: Tony
Koen Pellegrims wrote:
YES! Please!
The current layout is not flexible at all and I for one would welcome a
simple, CSS-based design.
I would do it myself if it wasn't for the time, or the lack thereof... ;-)
Soon we'll use http://xml.apache.org/forrest/
It's not only CSS because some
Yes, I did.
I am using the extractor tranformation to extract the definition of the
chart from the xml source file, and wrote a reader to generate a jfreechart
png from the extracted fragment. Almost identical to the svg example.
The whole thing is not finished yet. It is working for bars and
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=13668.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
From: Antonio Gallardo Rivera
Hi,
I just write to tell that in the mod-db example. We must
change the name of
the first table from user to users or something similar.
In PostgreSQL the word user is a keyword.
Can't this be solved by changing the sql like this:
select * from user ?
I think no, because we need to avoid the use of keywords.
I will try to make it work and send here the example changed.
Antonio Gallardo.
El Miércoles, 16 de Octubre de 2002 02:24, Piroumian Konstantin escribió:
From: Antonio Gallardo Rivera
Hi,
I just write to tell that in the
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=13685.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Stefano Mazzocchi wrote:
Unfortunately, though, I won't be able to make it at the Cocoon
Gettogether in Belgium since I'll probably be in the US for the ApacheCON.
Just for everybody's info:
58 people are expected to come so far. This is much more than we
expected (and really, really
Hi all,
Several cocoon users (including me) have reported a caching problem when
using cocoon: pseudo protocol with ServerPagesGenerator. Here's an example
pipeline:
map:pipeline type=noncaching
map:match pattern=foo
map:generate type=serverpages src=cocoon:/bar/
map:serialize
We have written a basic JFreeSerializer. Just enough functionality for
producing time series charts in png from datapoints sent down the
pipeline from an XSP generator.
Cheers, Alfred.
-Original Message-
From: Hugo Burm [mailto:[EMAIL PROTECTED]]
Sent: Mittwoch, 16. Oktober 2002 09:13
Quoting Nathaniel Alfred [EMAIL PROTECTED]:
We have written a basic JFreeSerializer. Just enough functionality for
producing time series charts in png from datapoints sent down the
pipeline from an XSP generator.
...mind to contribute it as new block? :-)
cheers
--
Torsten
Stefano Mazzocchi wrote:
I'm personally happy if somebody ports Cocoon in other languages (people
already did twice, for Perl and PHP)
I was referring to Axkit as the Cocoon's port in Perl but it's a
mistake: even if they offer similar functionalities and use similar
technologies, AxKit and
We have written a basic JFreeSerializer. Just enough
functionality for
producing time series charts in png from datapoints sent down the
pipeline from an XSP generator.
...mind to contribute it as new block? :-)
Sure, if there is interest for it.
But it will take me some time to figure
There are patches in the queue that bring a basic
level of flexibility and security (of a sort) to
multipart file upload behavior.
Here are a few follow up issues from the initial
discussion. Some are remaining action points, some
are just updates:
1) There is the idea that choosing
On Wed, 16 Oct 2002, Nicola Ken Barozzi wrote:
Koen Pellegrims wrote:
YES! Please!
The current layout is not flexible at all and I for one would welcome a
simple, CSS-based design.
I would do it myself if it wasn't for the time, or the lack thereof... ;-)
Soon we'll use
In /cocoon/samples/sub/welcome, section Obtaining XSL Source,
all the examples except for the first fail with a NullPointerException
in AbstractCachingProcessingPipeline.java at line 564. So it would
appear cachedPipelineKey must be null.
If this is not a known problem, with someone working on
Vadim == Vadim Gritsenko [EMAIL PROTECTED] writes:
Vadim Python script should work, what you experience is the
Vadim problem with refactored samples: seems that refactoring is
Vadim not complete yet. You can help here by ensuring that all
Vadim samples have all the needed
Hi,
I´ve having troubles calling an Action from the flow layer.
It used to work just fine, but I think some of the changes made lately
may have broken the implementation.
Row 290 in JSCocoon is the villain, it creates a NPE at the row below.
The call:
ComponentManager sitemapManager=
Okay,
the error is at row 153 in CallFunctionNode.
the line:
manager = manager;
should be
this.manager = manager;
/Mats
Mats Norén wrote:
Hi,
I´ve having troubles calling an Action from the flow layer.
It used to work just fine, but I think some of the changes made lately
may have
A long long time ago Carsten Ziegeler wrote:
Nearly all generators could be rewritten as sources, for
example the RequestGenerator could be written as a request:
protocol. But does this make sense - I would say: No. I
think a protocol makes sense if several, different sources
(documents,
I could see uses for it - very similar to what you suggest. However I was instead
looking into
achiving the same thing with the Request Generator, the Fragment Extractor and internal
pipelines...
A long long time ago Carsten Ziegeler wrote:
Nearly all generators could be rewritten as sources,
Ugo Cei wrote:
A long long time ago Carsten Ziegeler wrote:
Nearly all generators could be rewritten as sources, for
example the RequestGenerator could be written as a request:
protocol. But does this make sense - I would say: No. I think a
protocol makes sense if several, different
ovidiu 2002/10/16 19:27:57
Modified:src/java/org/apache/cocoon/components/treeprocessor/sitemap
CallFunctionNode.java
Log:
compose: Fix assignment to this.manager. Found by Mats Norn [EMAIL PROTECTED].
Revision ChangesPath
1.8 +1 -1
Thanks for catching this, I committed it.
Regards,
Ovidiu
On Wednesday, October 16, 2002, at 11:51 AM, Mats Norén wrote:
Okay,
the error is at row 153 in CallFunctionNode.
the line:
manager = manager;
should be
this.manager = manager;
/Mats
Mats Norén wrote:
Hi,
I´ve having
On Wednesday, October 16, 2002, at 08:10 AM, Nathaniel Alfred wrote:
We have written a basic JFreeSerializer. Just enough
functionality for
producing time series charts in png from datapoints sent down the
pipeline from an XSP generator.
...mind to contribute it as new block? :-)
On Wednesday, October 16, 2002, at 08:10 AM, Nathaniel Alfred wrote:
We have written a basic JFreeSerializer. Just enough
functionality for
producing time series charts in png from datapoints sent down the
pipeline from an XSP generator.
...mind to contribute it as new block? :-)
ovidiu 2002/10/16 20:02:12
Modified:src/java/org/apache/cocoon/components/flow/javascript
JSCocoon.java
Log:
Export the Avalon ComponentManager to JavaScript scripts. Request from
Reinhard Poetz [EMAIL PROTECTED] and Maciek Kaminski
[EMAIL PROTECTED].
27 matches
Mail list logo
