Nicola Ken Barozzi wrote:
I was browsing the Ant docs, and found this... so we can also keep
constants in java classes and use them in the Ant buildfile.
ClassConstants
This filters basic constants defined in a Java Class, and outputs them
in lines composed of the format name=value
Example:
Hi team,
I've been receiving a lot of interest in using DELI with Cocoon 2.04
recently. I've updated the version in the 2.04 cvs repository so that DELI
works correctly and to use the latest version of DELI.
Question: Are there any plans for further updates to the download version
(i.e. the
Stefano Mazzocchi wrote:
Good news, everyone!
For the first time in the history of Gump, we were able to run clean
last night.
Now we have a problem: the block builds expect a cocoon jar, but before
packaging we have to compile the blocks because they patch the role file
which is included
On Sonntag, März 16, 2003, at 05:32 Uhr, Christopher Oliver wrote:
leo leonid wrote:
On Freitag, März 14, 2003, at 07:45 Uhr, Christopher Oliver wrote:
the views are pretty much brain-dead: Velocity generating xhtml
directly. It would be neat if we could better show off Cocoon's view
Christopher Oliver wrote:
Found it:
http://bugs.eclipse.org/bugs/show_bug.cgi?id=34658#c28
ah, that also explains some random problems I'm experiencing with
Eclipse... it appears to be a problem with the JDK 1.4.1 macosx
implementation of InputStream.available() which is a native function.
Wow,
Butler, Mark wrote:
Hi team,
I've been receiving a lot of interest in using DELI with Cocoon 2.04
recently. I've updated the version in the 2.04 cvs repository so that DELI
works correctly and to use the latest version of DELI.
Good.
Question: Are there any plans for further updates to
Steven Noels wrote:
Sam Ruby wrote:
*If* there are people who might be predisposed to make changes to
/usr/serverlocal/gump, *then* I would like to be included as a member
of whatever group they might have as their primary group.
Ah. I'm pretty sure now we _do_ understand each other. :-)
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=18047.
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=18047.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
On Monday, March 17, 2003, at 07:33 AM, Carsten Ziegeler wrote:
Hi Jeremy,
can you please turn on debug logging and post what the new
resolver logs on startup?
Hi Carsten,
I made this change in web.xml :
init-param
param-namelog-level/param-name
param-valueWARN/param-value
David Crossley wrote:
David Crossley wrote:
David Crossley wrote:
Stefano Mazzocchi wrote:
snip/
try to do a clean checkout, maybe there is something wrong in
your local CVS metadata.
ah, no, wait, what settings are you using for cvs update?
cvs -q -z3 update -d -P cocoon-2.1
Okay, i will try
Jeremy Quinn wrote:
On Monday, March 17, 2003, at 07:33 AM, Carsten Ziegeler wrote:
Hi Jeremy,
can you please turn on debug logging and post what the new
resolver logs on startup?
Hi Carsten,
I made this change in web.xml :
init-param
Hi all!
Does anyone know the xerces version in j2sdk_1.4.1 ?
And also: can I set another xerces for using (if I use java1.4)?
Thanks for advice.
--
Best regards,
Yury Mikhienko.
IT engineer, ZAO Mobicom-Kavkaz
Christopher Oliver wrote:
Vadim Gritsenko wrote:
Christopher Oliver wrote:
That's not the case. All are equally crippled ;) For example, when
using Xsp, the idea is that the only logic sheet you will ever use
is the jpath logic sheet. This does not give you direct access to
session,
Stefano Mazzocchi wrote:
For 2.1 we have some additional points in our todo list in cvs
that have to be solved before a final release.
Bring them on.
From the todo.xml (perhaps some of them are obsolete; perhaps some are not
so
important):
action context=code assigned-to=CZ
Redesign
On Monday, March 17, 2003, at 01:38 PM, Carsten Ziegeler wrote:
Jeremy Quinn wrote:
On Monday, March 17, 2003, at 07:33 AM, Carsten Ziegeler wrote:
Hi Jeremy,
can you please turn on debug logging and post what the new
resolver logs on startup?
Hi Carsten,
I made this change in web.xml :
snip/
leo leonid wrote:
On Sonntag, März 16, 2003, at 05:32 Uhr, Christopher Oliver wrote:
leo leonid wrote:
On Freitag, März 14, 2003, at 07:45 Uhr, Christopher Oliver wrote:
the views are pretty much brain-dead: Velocity generating xhtml
directly. It would be neat if we could better show off
Jeremy Quinn wrote
Sorry, I was a little bit unprecise. You have to set the loglevel in
the
logkit.xconf - change the setting for core and for manager from ERROR
to DEBUG. You will find the messages in the core.log.
OK, hope this helps . no hits, just the startup.
Yes, that's
On Monday, March 17, 2003, at 02:22 PM, Carsten Ziegeler wrote:
Jeremy Quinn wrote
Sorry, I was a little bit unprecise. You have to set the loglevel in
the
logkit.xconf - change the setting for core and for manager from ERROR
to DEBUG. You will find the messages in the core.log.
OK, hope this
On 17/03/2003 14:06 Sam Ruby wrote:
I still don't think I am communicating. Let me try a specific example:
Yep, we weren't.
bruno is in cocoondev, but his primary group is ot. If he were to
create files in /usr/serverlocal/gump, by default, I couldn't change them.
Indeed.
I'd like bruno's
a problem
with my local repository and need to re-checkout.
You will find a excalibur-xmlutils jar with the date of today 20030317.
If you have this jar, then you're upto date.
I will do a fresh checkout and report back after lunch :)
Have a nice meal!
Carsten
leo leonid wrote:
I just put the first results on my server.
= http://proto2.leonid.de
The XSP/XSL view for browsing Categories, Products, Items, Search,
SignOn is already working. I'm now a bit stuck with the Cart, where I am
still unsuccessful in retrieving values from the flow layer via
Vadim Gritsenko wrote:
Christopher Oliver wrote:
You may discourage usage of these objects for the sake of perfectness of
the MVC in the documentation but I don't think you should insist on
disabling access to them (like in FlowVelocityGenerator).
Fair?
Vadim
I think you're right.
JSTL
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=17930.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
On Montag, März 17, 2003, at 04:37 Uhr, Christopher Oliver wrote:
leo leonid wrote:
I just put the first results on my server.
= http://proto2.leonid.de
The XSP/XSL view for browsing Categories, Products, Items, Search,
SignOn is already working. I'm now a bit stuck with the Cart, where I
am
leo leonid wrote:
excellent! so I can go on with checkout, order, shiping, etc...
Does Xsp have some way of doing number formatting? The numeric values
you receive from JavaScript are of type java.lang.Double.
Yes probably there is already a logicsheet for this, I try to avoid
xsp:logic/.
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=17930.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Carsten Ziegeler wrote:
Stefano Mazzocchi wrote:
SNIP/
So, perhaps Sylvain has a clever idea on how to implement this in the
treeprocessor.
I think that using xconftool is enough.
Yes, after thinking about it, for now we even don't need the xconftool
but a clever exception
o.a.c.components.parser.Parser is deprecated, and if you don't include
the deprecated block in the build, you won't get the class, as expected.
Unfortunately, the XSP logicsheet
(src/java/org/apache/cocoon/components/language/markup/xsp/java/xsp.xsl)
still has an import declaration for it, but
Ugo Cei wrote:
o.a.c.components.parser.Parser is deprecated, and if you don't include
the deprecated block in the build, you won't get the class, as expected.
Unfortunately, the XSP logicsheet
(src/java/org/apache/cocoon/components/language/markup/xsp/java/xsp.xsl)
still has an import
On Montag, März 17, 2003, at 06:36 Uhr, Christopher Oliver wrote:
leo leonid wrote:
excellent! so I can go on with checkout, order, shiping, etc...
Does Xsp have some way of doing number formatting? The numeric
values you receive from JavaScript are of type java.lang.Double.
Yes probably there
Vadim Gritsenko wrote:
Umm... XSPs should be compared to JSPs, and yes, we already have set of
built-in objects (see any XSP java source file, or see XSPGenerator.java):
/* Built-in parameters available for use */
// context- org.apache.cocoon.environment.Context
//
[EMAIL PROTECTED] wrote:
coliver 2003/03/17 10:41:20
Modified:lib jars.xml
Added: lib/core rhino1.5r4-continuations-20030317.jar
Removed: lib/core rhino1.5r4-continuations-20020816.jar
Log:
updated rhino to latest cocoondev.org version: needed for fix to line
Stefano Mazzocchi wrote, On 17/03/2003 20.31:
Vadim Gritsenko wrote:
...
The only thing which is missing is flow continuation and bean (new
kids), but these are provided by jpath logicsheet. And I can't built
them into core XSP because people want to separate flow into the block.
Between a
Sylvain Wallez wrote:
What I suggested in the mail linked above is to use the object model,
already used as a communication means between the environment and other
components to communicate flow results. This suggestion comes both from
the fact that the object model is the natural way for the
I am almost sure that it should be made all-the-way around: the client can
request a specific encoding to the server: See RFC 2616 section 14.2 page
102: the Accept-Charset header.
Or an _ordered_list_ of those as input. See also the Languages while you
are at it; and the Accept: type as
Pier Fumagalli wrote:
On 16/3/03 20:04, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
So, if you to put encoding into sitemap... You will have to disable
serializer configuration and request configuration and force sitemap
encoding onto request / response. Is this what you are proposing?
Pier Fumagalli wrote:
On 16/3/03 23:38, Vadim Gritsenko [EMAIL PROTECTED] wrote:
true. but you can't have chinese text in US-ASCII, right?
Even if you can not that anybody will be able to read it ;-)
So yes, right.
Unicode specifes (somewhere) that any character non representable by the
current
Pier Fumagalli wrote:
On 15/3/03 21:54, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
- flow
- provide a block-like method for extension of the object model
What about something similar to Mozilla's XPConnect?
http://www.mozilla.org/scriptable/
No, I don't think this is what we need. XPConnect
On Monday, March 17, 2003, at 08:02 PM, Stefano Mazzocchi wrote:
Sylvain Wallez wrote:
snip/
So, I would go for
global - contains global log methods, no properties
Why log methods? I don't understand what is so special about them, that
they need to be global?
cocoon.log.info(blah);
On 17/3/03 18:23, Dirk-Willem van Gulik [EMAIL PROTECTED] wrote:
I am almost sure that it should be made all-the-way around: the client can
request a specific encoding to the server: See RFC 2616 section 14.2 page
102: the Accept-Charset header.
Or an _ordered_list_ of those as input. See
On 17/3/03 0:16, Vadim Gritsenko [EMAIL PROTECTED] wrote:
- String getCharsetEncoding() [or getCharacterEncoding]:
Returns the default character encoding configured for the specified
AbstractTextSerializer (or the default one for the sitemap if none
was specified).
This can
On 17/3/03 20:15, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
On another thought... The cache should store unicode characters as is, not
bytes, as those might change for the same request URL depending on the
different headers in the request...
Uh, another good point.
Ok, in the light of
Sorry for the subject ... I was intended on another kind email, but when I
realized that I still had a couple of gray areas that I wanted to address, I
rewrote it forgetting the title...
Pier
Stefano Mazzocchi wrote:
Sylvain Wallez wrote:
What I suggested in the mail linked above is to use the object model,
already used as a communication means between the environment and
other components to communicate flow results. This suggestion comes
both from the fact that the object model
Christopher Oliver wrote:
Sylvain Wallez wrote:
A short explanation about the object model. Cocoon abstracts its
runtime environment through the Environment interface. An Environment
object gives access to a number of things that are relevant to the
pipeline/sitemap engine only and should not
On 17/3/03 20:02, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
I share your attach-a-method-to-an-object concern, which certainly
comes from our heavy Java background.
I'm sure it does, but after playing pretty hard with javascript for
DHTML, I can tell you that the hardest thing for me to
On 17/3/03 20:02, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
So, I would go for
global - contains global log methods, no properties
global doesn't have a meaning in IDL, therefore I created the Script
object, which will contain also the reference to the function called from
the sitemap...
Stefano Mazzocchi wrote:
David Crossley wrote:
snip/
Found it - there is extra whitespace at the end of these
three lines in block.properties, i.e. after the =true
Thank the lord, i am not going mad. Sounds like we
need normalize-space() whenever properties are read.
Call in the
Hi there,
I see that there is a problem with ContinuationsManagerImpl class. Also
it may seem that this is proper Avalon component, it's not. It is used
directly from two places:
* WebContinuation.java
* JSCocoon.java
And first one AFAIU is publicly accessible object. Which means that one
Pier Fumagalli wrote:
snip/
But there is a problem... Proxies and caches...
AFAIK (took a look at spec too ;):
If, for example, in my corporation there are two guys, one using Windows in
jp and one using Linux in en_US, if the first guy requests
http://www.vnunet.com/;, I'll deliver the page
Pier Fumagalli wrote:
On 17/3/03 0:16, Vadim Gritsenko [EMAIL PROTECTED] wrote:
snip/
It (?xml? instruction) done via
format.put(OutputKeys.ENCODING,encoding.getValue()) in abstract
serializer itself.
That gets the value out of the serializer configuration itself... So, per
se, we cannot
Pier Fumagalli wrote:
On 17/3/03 20:15, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
snip/
What about adding a 'content encoding' attribute to the 'pipeline' instead?
'transfer encoding' attribute would make sense, but content encoding...
Currently pipeline does not alter content, does
Sylvain Wallez wrote:
Stefano Mazzocchi wrote:
Sylvain Wallez wrote:
So we need two more values in the object model Map : one for the
value dictionary, and one for the continuation.
How does it sound ?
I love it, but, as Carsten correctly pointed out, this will make it
harder to separate
On Tuesday 18 March 2003 05:25, Pier Fumagalli wrote:
If, for example, in my corporation there are two guys, one using Windows in
jp and one using Linux in en_US, if the first guy requests
http://www.vnunet.com/;, I'll deliver the page the first time in jp,
encoded in shift_jis (let's not
---
This mail is generated automatically using
Jakarta Ant. Contents are automatically
downloaded from Apache's Bugzilla.
---
Please do not reply to
Carsten Ziegeler wrote:
snip/
For 2.1 we have some additional points in our todo list in cvs
that have to be solved before a final release.
There is also the document at:
http://xml.apache.org/cocoon/plan/release.html
snip/
Version 2.1 Beta 1
* apply patches
* test
I went to try to resurrect the Lucene search sample today.
However, i cannot find it anywhere in CVS. Was it deliberately
removed or this is an accidental victim of the refactoring?
--David
David Crossley wrote, On 18/03/2003 3.37:
Stefano Mazzocchi wrote:
David Crossley wrote:
snip/
Found it - there is extra whitespace at the end of these
three lines in block.properties, i.e. after the =true
Thank the lord, i am not going mad. Sounds like we
need normalize-space() whenever
Vadim Gritsenko wrote, On 18/03/2003 3.52:
Pier Fumagalli wrote:
...
That gets the value out of the serializer configuration itself... So, per
se, we cannot have a per-pipeline text serializer with different
encodings
per different sitemaps...
That's why we have to allow local serializer
Folks,
we are pleased to introduce you the FINS Project (aka ChartTransformer).
The aim of this project is to equip the Cocoon community with a set of
sitemap components able to generate professional charts in different formats
(SVG, PNG, JPEG) using the JFreeChart library.
The long-term goal is
61 matches
Mail list logo
