Sylvain Wallez wrote:
2/ Resources inheritance
Resources are nothing more than untyped virtual components (yeah
Stefano, I know, they should be serializers). So if a resource isn't
defined in a sitemap, we go up to the parent sitemap's component manager
and lookup the resource there.
Bertrand Delacretaz wrote:
Antonio Gallardo a écrit :
...I would prefer ogg because MP3 has copyright issues.
Ok, I have prepared an ogg version of the example, please test on your
platforms:
http://www.codeconsult.ch/clients/gt2003/00-introduction.ogg
I've tested it on macosx with
Joerg Heinicke wrote:
The result of this thread: let's care only about white spaces.
It's my opinion too. But the editor should do this automatically, not by
running a task by hand.
Agreed. I am adding it to my requirements list, in the search for
a new editor.
IDEA does it pretty good:
Bertrand Delacretaz dijo:
Le Mardi, 11 nov 2003, à 12:31 Europe/Zurich, Antonio Gallardo a écrit :
...I would prefer ogg because MP3 has copyright issues.
Ok, I have prepared an ogg version of the example, please test on your
platforms:
Carsten Ziegeler dijo:
Sylvain Wallez wrote:
Conclusion
--
I'm wondering if we should write this new sitemap engine in the 2.2
branch or if it should go in the 2.1. Fortress isn't a requirement to
implement this, and it will allow us to provide views and resource
inheritance before
On Sat, 08 Nov 2003 18:22:08 +0100
Torsten Curdt [EMAIL PROTECTED] wrote:
...I was wondering - is this a bug of the component that produces the
SAX events or the XMLByteStreamCompiler? I mean: now it's ok - but
should we
silently ignore the problem?
Torsten, I don't understand
-Original Message-
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
Sent: dinsdag 11 november 2003 21:48
To: [EMAIL PROTECTED]
Hi all,
Here's a RT about Unico's proposal of flattening the
sitemap for the migration to Fortress. Please read carefully,
this has a lot of
We could also increasing the max length of a stored
character event in general. ...but that would waste
2 bytes per event. Hm...
What do you think?
--
Torsten
Hi,
why should we handle the UTFDataFormat exception, at all?. The last solution ignores this exception, doesn't it?
Where is the
On Tue, 2003-11-11 at 15:15, Vadim Gritsenko wrote:
Hey guys,
Has anybody have any suggestions on how to make @required=true,
wi:styling list-type=radio/, widget make less ugly? Currently it
looks like:
( ) Label for the first radio button
( o ) Second
( ) Third *
Where *
From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]
snip/
I'm wondering if we should write this new sitemap engine in the 2.2
branch or if it should go in the 2.1. Fortress isn't a
requirement to
implement this, and it will allow us to provide views and resource
inheritance before the
On Wednesday 12 November 2003 11:37, Torsten Curdt wrote:
We could also increasing the max length of a stored
character event in general. ...but that would waste
2 bytes per event. Hm...
What do you think?
--
Torsten
Hi,
why should we handle the UTFDataFormat exception, at all?.
IDEA does it pretty good: Removes trailing
spaces when saving a file, replaces existing tabs with spaces on save,
when using the key TAB it adds spaces to the file. But unfortunately
IDEA is not for free.
Ah, others keep mentioning IDEA too.
Hm... just wondering if they might give away a
On 11 Nov 2003, at 19:49, Joerg Heinicke wrote:
On 11.11.2003 12:38, Stefano Mazzocchi wrote:
Carsten, what is the status of the component proxy? If we have such a
big memory leak, I think we should get it solved before doing the
release.
Torsten Curdt wrote:
Well, that true ...but the current length is hold
as 15-bit integer. The highest bit decides whether
it's an index in a HashMap or not.
As I said we could increase the length to 31-bit
but that gives 2 additional bytes per character
event.
...
Let's not discuss this to
Let's not discuss this to death. I'll fix it :)
Minor suggestion. 32k events do not happen everyday, but 32k events
do, a lot. So, instead of adding size to the 32k events, it's better to
add some size to 32k events.
What I mean is:
1) Leave length as it is, 2 bytes.
2) Have one value
-Original Message-
From: Unico Hommes
Sent: maandag 10 november 2003 12:11
To: [EMAIL PROTECTED]
snip/
Sylvain Wallez wrote:
Furthermore, I would like this feature to be defined at the
environment level and not only in the flowscript. Methods of
the
cocoon object
Unico Hommes wrote:
snip/
1/ Virtual components
Virtual components are sitemap snippets that can be used in place of regular components. I
many languages, these are called macros. With sitemap statements as components, virtual
components are a breeze to implement: just lookup the component,
On 11 Nov 2003, at 15:48, Geoff Howard wrote:
I'm the same. In fact, I think that flow in some cases needlessly
complicates the composition of a pipeline. Now I have to have two
pipelines where I used to need one.
wait wait wait. hold it.
There are different issues on the table here:
1)
On 11 Nov 2003, at 23:05, Joerg Heinicke wrote:
On 11.11.2003 22:31, Carsten Ziegeler wrote:
The only question is: do we stick to the release date of thursday?
*I* can do the release on thursday or on friday. Due to the ApacheCon
and some holidays :) I won't be able to do it in the following
From: Stefano Mazzocchi
Ah, Carsten, do we have instructions on how to do the
release? I can't
stop feeling uncomfortable in having you a bottleneck of this
process.
[not a critic on your great work, but just a thought]
http://wiki.cocoondev.org/Wiki.jsp?page=CocoonReleaseHowTo
--
Stefano Mazzocchi dijo:
I've started to evaluate IDEA as well because eclipse on mach-o is
simply not usable if you don't have several GBs of RAM (and I don't)
lol. We are using Eclipse and in fact I need to upgrade our 3 machines to
512, 768 and 1024 of RAM respectively. :-D
It looks like
If noone comes up with an issue or a good reason to not release
tomorrow, I will do the release tomorrow in the morning (CET).
So, no need to reply if you're +1 for releasing tomorrow :)
Thanks
Carsten
Stefano Mazzocchi wrote:
As a general feeling, I like what I see.
A few comments inside.
On 12 Nov 2003, at 14:34, Sylvain Wallez wrote:
Unico Hommes wrote:
snip/
1/ Virtual components
Virtual components are sitemap snippets that can be used in place
of regular components. I many languages,
Bruno Dumon wrote:
On Wed, 2003-11-12 at 12:19, Berin Loritsch wrote:
Instead I would highly encourage you to provide a way to set the base
URL where relative URLs would be resolved to.
Work *with* the contract instead of extending it in non-intuitive ways.
See my rant in another email.
Again
Joerg Heinicke wrote:
On 11.11.2003 15:15, Vadim Gritsenko wrote:
BTW, is anybody against replacing xsl:template
name=woody-field-common/ with xsl:template match=wi:*
mode=common ? It's not possible to override in the including
stylesheet named templates, but you can override match=
Reinhard Poetz wrote:
From: Antonio Gallardo
Stefano Mazzocchi dijo:
I've started to evaluate IDEA as well because eclipse on mach-o is
simply not usable if you don't have several GBs of RAM (and I don't)
lol. We are using Eclipse and in fact I need to upgrade our 3
machines to
(changing the subject also in this branch of the thread to distinguish
from other ComponentizedProcessor issues)
Berin Loritsch wrote:
snip/
Wild idea: context:/ identifies the current context, context://
identifies the root sitemap? Like in cocoon: protocol?
*shudder*
PLEASE, read this
D:\cocoon-2.1build docs
Using Java from D:\jdk1.4.2_01
Buildfile: build.xml
prepare:
...
Total time: 1 minutes 50 seconds
--
Static site generated at:
D:\cocoon-2.1/build/cocoon-2.1.3-dev/site
Please check the file
On 12.11.2003 17:50, Sylvain Wallez wrote:
Joerg Heinicke wrote:
On 11.11.2003 15:15, Vadim Gritsenko wrote:
BTW, is anybody against replacing xsl:template
name=woody-field-common/ with xsl:template match=wi:*
mode=common ? It's not possible to override in the including
stylesheet named
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=24647.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
On Wed, 2003-11-12 at 12:50, Berin Loritsch wrote:
Bruno Dumon wrote:
On Wed, 2003-11-12 at 12:19, Berin Loritsch wrote:
Instead I would highly encourage you to provide a way to set the base
URL where relative URLs would be resolved to.
Work *with* the contract instead of extending it
Antonio Gallardo wrote:
Sylvain Wallez dijo:
So since we _need_ to be able to specify URLs relative to the current
sitemap, what do you suggest? A subprotocol like what we have for
cocoon:raw, another protocol like current-sitemap:?
Just like Bruno, I'm happy with the cocoon:/ and cocoon:// we
Sorry Andrzej, but the community has decided with a vote.
So it goes. I'll write an action to replace the flowscriptand that will
be that. No big deal.
I do vote +1 on the idea of a flowscript action...so you can inject
javascript logic easily into a Cocoon implementation, without 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=24647.
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=24647.
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=24647.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
On 12.11.2003 18:14, Andrzej Jan Taramina wrote:
Stefano:
As a rule, we should restrict everything that we can't come up with a
reason to make it possible, then keep listening for people that could come up
with those reasons.
Everything that is not explicitly allowed is disallowed?
Exactly.
On 12 Nov 2003, at 18:14, Andrzej Jan Taramina wrote:
Stefano:
As a rule, we should restrict everything that we can't come up with a
reason to make it possible, then keep listening for people that could
come up
with those reasons.
Everything that is not explicitly allowed is disallowed?
That
Andrzej Jan Taramina wrote:
Stefano:
As a rule, we should restrict everything that we can't come up with a
reason to make it possible, then keep listening for people that could come up
with those reasons.
Everything that is not explicitly allowed is disallowed?
That sucks and, IMNSHO, will be
Hi,
I agree with Stefano's observation that there is a need for a good content repository.
I've looked into Slide's code before and I can't help but wonder if it is a good idea
for Slide to be implemented using Avalon.
The server core can be broken down into 3 blocks
1. Content repository
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=24389.
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=24389.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
From: Vadim Gritsenko
Reinhard Poetz wrote:
From: Antonio Gallardo
Stefano Mazzocchi dijo:
I've started to evaluate IDEA as well because eclipse on mach-o is
simply not usable if you don't have several GBs of RAM
(and I don't)
lol. We are using Eclipse and in
Reinhard Poetz dijo:
From: Vadim Gritsenko
Reinhard Poetz wrote:
From: Antonio Gallardo
Stefano Mazzocchi dijo:
I've started to evaluate IDEA as well because eclipse on mach-o is
simply not usable if you don't have several GBs of RAM
(and I don't)
lol. We are using Eclipse
On 12 Nov 2003, at 19:49, Joerg Heinicke wrote:
Only a random thought: why there is no FlowScriptSelector calling the
flow script and evaluating the String return type? This would remove
the sitemap calls flow script calls sitemap and is more like a
function call. You will have only one
Stefano Mazzocchi wrote:
On 12 Nov 2003, at 19:49, Joerg Heinicke wrote:
Only a random thought: why there is no FlowScriptSelector calling the
flow script and evaluating the String return type? This would remove
the sitemap calls flow script calls sitemap and is more like a
function call.
Tim Olson wrote:
map:match action=*/profile/edit
map:call function=dumpUserData/
map:call function=dumpOrderData/
map:call function=dumpNewsItems/
map:generate src=cocoon://generate/
map:transform src=homePage.xsl/
map:serialize/
/map:match
map:match
Tim Olson wrote:
map:match pattern=view
map:generate src=cocoon://generate/
map:transform src=homePage.xsl/
map:serialize/
/map:match
i thought the original intention was to make the flow clearer? now we have
three blocks of code to follow instead of one...
Well, almost, you can reuse
Ugo suggested:
map:match pattern=*/profile/edit
map:call function=dumpData/
/map:match
map:match pattern=view
map:generate src=cocoon://generate/
map:transform src=homePage.xsl/
map:serialize/
/map:match
function dumpData() {
dumpUserData();
I've updated my ResourceLoadAction so that it optionally will save the
resource stream data (as a string) in your session/request with a given
attribute name.
The optional write-to and attribute-name parameters, if specified, will cause
the ResourceLoadAction do the save. write-to can be
I found the thread:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg03337.html
I think it is a bigger problem with xalan But I am clueless :)
JD
-Original Message-
From: JD Daniels [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 12, 2003 1:54 PM
To: Cocoon Users
Subject: Xalan
I cannot agree more with Stefano's comment regarding the big-O order of search and
access opertions. We need constant time lookup and queries of information regarding
the artifacts (the meta data) as well as constant time access to an artifact's content
stream regardless of how many artifacts
52 matches
Mail list logo
