"Stefano Mazzocchi" <[EMAIL PROTECTED]> wrote:
> on 6/23/03 8:29 PM Pier Fumagalli wrote:
>
>> SetAttribute vs Well-formedness:
>>
>> [...]
>>
>> #if {something}
>>
>> #else
>>
>
fine a basic event model for the flow (basically, what events are
> generated and when).
As they are future additions (and therefore don't modify the signature of
the FOM), I'd prefer to comment them out, and re-add them when ready.
Pier
On 24/6/03 23:58, "Joerg Heinicke" <[EMAIL PROTECTED]> wrote:
> Pier Fumagalli wrote:
>>
>> SetAttribute vs Well-formedness:
>>
>>
>>
>> #if {something}
>> [EMAIL PROTECTED]"myClass"}
>
't thought about the archives. I thought
>> that the archives would be somehow moved as well. Hmm, does anyone
>> know more about this?
>
> Geoff and i both asked that question the last time this issue arose,
> Asking Pier if he was sure that there were no side effects. P
And rejoice... I just found my next roommate, its name's PowerMac G5! :-)
Pier
>> using the garbage generator to the scratchpad samples.
>
> Wow, you guys rock! community power at work!
In-diddly-deed (too much Ned Flanders?)
>> I would also like to add a Garbage view to Petstore, but I need you to
>> implement #include first ;)
>
> Yeah,
For the records... Didn't go through.
Pier
-- Forwarded Message
> Return-Path: <[EMAIL PROTECTED]>
> Received: (qmail 32150 invoked by uid 500); 21 Jun 2003 21:11:57 -
> Delivered-To: [EMAIL PROTECTED]
> Received: (qmail 32145 invoked from network); 21
pier2003/06/21 14:55:25
Modified:src/scratchpad/garbage build.xml
Added: src/scratchpad/garbage/tools .cvsignore
Log:
Make sure we give a good explaination on why we can't compile if JavaCC
is missing and JavaCC is unavailabe (JavaCC itself cannot be redistri
pier2003/06/21 14:06:35
cocoon-2.1/src/scratchpad/garbage/source/java/org/apache/garbage/servlet - New
directory
pier2003/06/21 14:06:35
cocoon-2.1/src/scratchpad/garbage/source/webapp - New directory
pier2003/06/21 14:06:35
cocoon-2.1/src/scratchpad/garbage/source/webapp/WEB-INF - New directory
pier2003/06/21 14:06:35
cocoon-2.1/src/scratchpad/garbage/tools - New directory
pier2003/06/21 14:06:35
cocoon-2.1/src/scratchpad/garbage/source/java/org/apache/garbage/tree - New directory
pier2003/06/21 14:06:35
cocoon-2.1/src/scratchpad/garbage/source/java/org/apache/garbage/serializer/util -
New directory
pier2003/06/21 14:06:35
cocoon-2.1/src/scratchpad/garbage/source/java/org/apache/garbage/serializer - New
directory
pier2003/06/21 14:06:35
cocoon-2.1/src/scratchpad/garbage/source/java/org/apache/garbage/serializer/encoding
- New directory
pier2003/06/21 14:06:34
cocoon-2.1/src/scratchpad/garbage/source/java/org - New directory
pier2003/06/21 14:06:35
cocoon-2.1/src/scratchpad/garbage/source/java/org/apache/garbage/parser - New
directory
pier2003/06/21 14:06:34
cocoon-2.1/src/scratchpad/garbage/source/java/org/apache/garbage - New directory
pier2003/06/21 14:06:34
cocoon-2.1/src/scratchpad/garbage/source/java - New directory
pier2003/06/21 14:06:34
cocoon-2.1/src/scratchpad/garbage/source/java/org/apache - New directory
pier2003/06/21 14:06:34
cocoon-2.1/src/scratchpad/garbage/source - New directory
pier2003/06/21 14:06:34
cocoon-2.1/src/scratchpad/garbage/lib - New directory
pier2003/06/21 14:00:42
cocoon-2.1/src/scratchpad/garbage - New directory
god knows!!! :-)
Pier
On 21/6/03 18:51, "Christopher Oliver" <[EMAIL PROTECTED]> wrote:
> I completely agree.
>
> Stefano Mazzocchi wrote:
>
>> on 6/19/03 8:23 AM Peter Royal wrote:
>>
>>
>>
>>> On Wednesday, June 18, 2003, at 05:53 P
On 19/6/03 18:51, "Steven Noels" <[EMAIL PROTECTED]> wrote:
> On 19/06/2003 19:39 Pier Fumagalli wrote:
>
>> The original scope of this RFI requested a separate repository for Garbage
>> from Cocoon exactly for this peculiar re-use of the parsing/templating
peculiar re-use of the parsing/templating
component outside the scope of Cocoon itself.
Pier
"Joerg Heinicke" <[EMAIL PROTECTED]> wrote:
> Pier Fumagalli wrote:
>>
>>
>> #foreach {parameters}
>> [EMAIL PROTECTED]: [EMAIL PROTECTED]
>> #end
>>
>
> Having only read one article about XQuery with a few samples this
"Peter Royal" <[EMAIL PROTECTED]> wrote:
> On Wednesday, June 18, 2003, at 05:53 PM, Pier Fumagalli wrote:
>> Unless I'm not mistaken, the above example template is _NOT_ a well
>> formed
>> XML document! :-) :-)
>
> Of course! I guess it wa
ookie, as the session, are unique for a given browser, and this is not
> suitable to store a continuation id which identifies both a flow
> instance and a location in that flow instance.
>
> Hope this makes things clearer.
Indeed it does... Working too much lately and loosing it slowly slowly :-)
Pier
"Sylvain Wallez" <[EMAIL PROTECTED]> wrote:
> Pier, unless I'm mistaken, it seems your problem can be solved with the
> flow without hacking sessions.
Indeed... But Stefano asked "Should the flow _always_ be associated with a
Session?", which I assumed (maybe
I know that the
serializer takes 4 seconds to initialize)
http://www.betaversion.org/~pier/garbage-0.0.tar.bz2
Pier
On 18/6/03 22:17, "Peter Royal" <[EMAIL PROTECTED]> wrote:
> On Wednesday, June 18, 2003, at 01:34 PM, Pier Fumagalli wrote:
>
>> Concise question, concise answer:
>>
>> Forget the XML syntax, use JXPath instead of JEXL for expressions...
>> Like:
&g
"Peter Royal" <[EMAIL PROTECTED]> wrote:
> On Tuesday, June 17, 2003, at 08:07 PM, Pier Fumagalli wrote:
>
>> The most peculiar one is that I always _hated_ the fact that Velocity
>> output
>> need to be passed through a parser _every_time_ the conten
"Bertrand Delacretaz" <[EMAIL PROTECTED]> wrote:
> Le Mercredi, 18 juin 2003, à 02:07 Europe/Zurich, Pier Fumagalli a
> écrit :
>>
>> ...It might not go anywhere, it might go somewhere, but if there's
>> interest in
>> this community to host my
"Christopher Oliver" <[EMAIL PROTECTED]> wrote:
> Cool. When can I try it? I'll help you as long as you stop calling it
> garbage ;)
I'll stop calling it garbage when it'll stop looking (and behaving) like
trash.
Pier
"Vadim Gritsenko" <[EMAIL PROTECTED]> wrote:
> Pier Fumagalli wrote:
> ...
>
>> So, what do you think? (Surely I need some help to put together the brat)
>>
>>
>
> If it provides getKey and getValidity, than it's much better velocity
C records:
- subproject name: "Garbage" (as it stands right now it's a piece of trash)
- initial committer: me, and all the Cocoon committers
- mailing list: [EMAIL PROTECTED]
- CVS notification list: [EMAIL PROTECTED]
So, what do you think? (Surely I need some help to put together the brat)
Pier
stance of a "client" (with all its tasks) on the server.
Kinda like multiplexing, multiple tasks on the client, multiple tasks on the
server, only ONE and only ONE (in most cases) session between the client and
the server...
Just my 0.02 GBP/Euro/USD (depending on whatever country you're in)
Pier
There you go, all 103 for your pleasure guys..
Pier
On 15/6/03 22:31, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> +---+
On 15/6/03 19:26, "Geoff Howard" <[EMAIL PROTECTED]> wrote:
> What happened?
God knows... Rerunning... Some foobarup on my side...
Pier
straightforward: "go and ask your father, the original DOOM is so
old"...
I still remember when me, Fede and Stefano were bewildered playing Doom back
in Pavia, and we were _GROWN_UP_ADULTS_ :-( :-(
Ste, we _are_ in the "olds" :-( :-( :-(
Pier
"Stefano Mazzocchi" <[EMAIL PROTECTED]> wrote:
> Hope this helps (and gets thru)
It got thru, it helps, and I like it! :-)
Pier
have to retrieve something
deeply-nested withing the datasource, I don't have to evaluate the full
XPATH expression every single time
> Another alternative is to use XQuery for generation-based processing and
> XSLT for transformation-oriented processing.
>
> And let the machinery reuse happen *inside* the two different engines.
I'll have to see the spec... Anyone knows of a working implementation?
> Why this? performance of XSLT on generation-stage starts to worry me.
Remember that one week of my time spent on solving one particular problem,
costs to my employer as much as one extra medium-sized Dell x86 server...
Frankly, from my own personal perspective, throwing new iron is a much more
viable solution than delaying going live with a website of a week...
(I know it's a cynical and egocentric view of the world, but, hey, everyone
has to bring something home to eat everynight)
Pier
er. While in my case the author information (or ID) is stored
in the article original XML data... It would be fair enough if I could
rewrite it like
But, darn, that's UGLY! :-(
Pier
:)
>
>> -Original Message-
>> From: Pier Fumagalli [mailto:[EMAIL PROTECTED]
>> Sent: Thursday, April 03, 2003 6:16 PM
>>
>> When I red about your "" document superhack, I have to admit, I
>> have
>
> I am not sure what you are referring t
On 4/4/03 1:33, "Robert Koberg" <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I going to snip alot because I wholeheartedly agree with most everything you
> wrote.
Pleased to hear that...
>> -----Original Message-
>> From: Pier Fumagalli [mailto:[EMAIL PROTEC
ache.org";>
Apache Cocoon Web Site.
Pretty easy XSLT stylesheet, indeed. But now, let's say that our editing
team wants to display something more about the author, for example his
picture, and his email address. This data is available already from another
XML source
s answer to my proposal,
> "for serious uses please download a servlet container" etc.
+1...
Pier
pear that we were "promoting" jetty, rather, just
> helping out our users.
I would agree to that...
Pier
or this community to elect one as a "engine
of choice", and "promote" it against other...
Pier
rifications higher up...
Thinking out loud... What if someone modifies an org.apache.cocoon class in
an incompatible way and distributes it incorporated in a product called
"Comanche Baboon" ???
Pier
und ?
I prefer this approach to exposing the source resolver itself, indeed...
If one, then, needs to get a hold on the resolver, yes, he can obtain an
instance of the resolver through the component manager...
Pier
with the
bean values I passed to sendRedirect.
Does this make any sense to any of you? Do you think it would be useful to
some extent?
Pier
ource", but well, better than using
LiveConnect.
Thinking out loud... Should the "resolver" then be another read-only
attribute of the script (instead of passing through the component manager?)
Pier
they are workign on a stripped-down version of
> mozmail to go along with phoenix/camino... hopefully with native widgets
> instead of that super-heavy XUL stuff.
That would be kute! :-)
> besides, I think it's not a problem with mozmail but my stupid router
> that cuts my connections... but hopefully I'm going to be out of here soon.
Don't tell me... Every time I look at netstat I see all your connections in
CLOSE_WAIT forever! :-)
Pier
has some design hints on how we could achieve that? Anyone else sees
it as I do as a "design hack" ???
Pier (the culprit)
On 30/3/03 20:32, "Stefano Mazzocchi" <[EMAIL PROTECTED]> wrote:
> Pier Fumagalli wrote:
>> On 30/3/03 2:43 pm, "Stefano Mazzocchi" <[EMAIL PROTECTED]> wrote:
>>
>>
>>> Here is what I would like to see:
>>>
>>>
.
>
>cocoon.process(uri, dict, output
Stefano... This one was cut as well... Can you please forward the rest
Pier
--+--+
>
>> Anyway, great job!
+1 :-)
Pier
can't speak
>> for Hussayn's project, however. One solution would be to move the WSPG to
>> the Proxy Block and mark it as deprecated.
>>
>>
>
> Or even remove it since it was never released !
I'd like to triple check the functionalities and have some doccos before
removing it... I use the proxy block @ work, so hopefully I'll be able to
maintain it! :-)
Pier
On 28/3/03 6:54 am, "Kevin O'Neill" <[EMAIL PROTECTED]> wrote:
> On Fri, 28 Mar 2003 03:07:01 +, Pier Fumagalli wrote:
>
>> On 28/3/03 0:41, "Gianugo Rabellino" <[EMAIL PROTECTED]> wrote:
>>
>>> What am I missing?
>>
&g
word there: the code is
"unacceptable" by the foundation (as far as my understanding goes)
I'm no lawyer, nor I want to make a stance of good or bad intentions (I'm
not a community activist either)... Just reporting what I grasped given my
position on the infrastructure PMC and
"Jeff Turner" <[EMAIL PROTECTED]> wrote:
> How about we just *try* cocoon-docs. If it turns out to be a
> sufficiently bad idea, scrap it.
+1 :-) Should I open the repo?
Pier
"Bertrand Delacretaz" <[EMAIL PROTECTED]> wrote:
> -Pier suggested [1] using a CVS alias to have cocoon-docs point to the
> src/docs directory of the current code repository (but I don't think he
> said how hard/easy/quick this is to implement).
Null brainer! :-)
Pier
On 27/3/03 9:40, "Sander Striker" <[EMAIL PROTECTED]> wrote:
>> From: Pier Fumagalli [mailto:[EMAIL PROTECTED]
>> Sent: Thursday, March 27, 2003 10:32 AM
>
>> On 27/3/03 3:22 am, "Brian Behlendorf" <[EMAIL PROTECTED]> wrote:
>
e want to have a "formal" vote?
Pier
. my bad, will fix it in a few hours when I commit the samples
> completely refactored.
Per-block samples? (thinking about the proxy block)
Pier
block and
> also remove the one from the trunk.
>
> Anybody against this?
Nope...
Pier
ave been triggered by bounces of some
sort. You sure that whilst your new IP was propagating, something else was
not bouncing email?
Pier
On 25/3/03 9:23 am, "Stefano Mazzocchi" <[EMAIL PROTECTED]> wrote:
> Pier Fumagalli wrote:
>> On 24/3/03 3:09 pm, "Stefano Mazzocchi" <[EMAIL PROTECTED]> wrote:
>>
>>
>>> Anyway, we can't force people to do anything: if
On 25/3/03 9:14 am, "Stefano Mazzocchi" <[EMAIL PROTECTED]> wrote:
> Pier Fumagalli wrote:
>>
>> Folks, do you know that there's the possibility to alias certain subparts of
>> a particular CVS repository from another repository?
>>
>> Like &
k would (although I don't like them
"that much").
Pier
gt; The distribution of Jetty we include is a minimal one, a stripped down one,
>> _precisely_ because of that reason, I'm actually thinking, for that reason,
>> to strip out most of what we don't use from the jetty.jar we include...
>>
>> Pier
>
>
ler" for technology-showoff (you download cocoon,
and you run it, that's it)...
The distribution of Jetty we include is a minimal one, a stripped down one,
_precisely_ because of that reason, I'm actually thinking, for that reason,
to strip out most of what we don't use from the jetty.jar we include...
Pier
t eligible but almost a committer: andrew
>
> [ ] docs should stay in src/documentation of the code tree
> module(s): jefft, nicolaken, pier, stephan
>
> ... which means we could use some more votes do establish genuine
> consensus...!
Steven... I didn't say that the document
> Stammtisch soon?
Who's going to http://www.jax2003.com/ (apart from Carsten, of course) ???
I've been asked to present the Apahe/Jakarta Night (thanks to Stefano)...
Pier
following us.
Hmm.. I don't think you're right on this, Stefano... Look at HTTPd, still a
lot of people are using 1.3, when 2.0 is delivering (for example) _A_LOT_
more performance than the old tree...
Still, a huge part of the user base didn't "switch" just yet...
Pier
d distros, and use a mirrored
> download for the jars, it's part of the same thing.
We _do_ use mirrors already... :-)
Pier
ferences that are *meant* to be there,
> that could get lost if 2.0 and 2.1 docs are generated from a common
> source.
Folks, do you know that there's the possibility to alias certain subparts of
a particular CVS repository from another repository?
Like "cocoon-2.1/src/docs" can be stored in the "cocoon-docs" repository.
Apache does it already with its httpd-docs repository, aliased to
httpd-2.0/docs (or something like it)...
Pier
"Carsten Ziegeler" <[EMAIL PROTECTED]> wrote:
> Pier Fumagalli wrote:
>>
>> "Carsten Ziegeler" <[EMAIL PROTECTED]> wrote:
>>
>>> Hi,
>>>
>>> is it possible to setup a PMC mailing list, like other projects
>
to have their content delivered in XML without the banner-ads or their site
reloaded by random folks :-)
Pier
f all decide the mailing list names. I propose the following:
[EMAIL PROTECTED] -> [EMAIL PROTECTED]
[EMAIL PROTECTED] -> [EMAIL PROTECTED]
[EMAIL PROTECTED] -> [EMAIL PROTECTED]
[EMAIL PROTECTED] -> [EMAIL PROTECTED]
There are few initial stages:
1) (pier) move mailing lists to n
I believe that our best bet is to do it when we also move the mailing lists
from "xml.apache.org" to "cocoon.apache.org"
Do we want to plan this?
Pier
memory from the OS... You should first use this to see if you
actually have a memory leak or not. And then only use the output from the
store janitor.
Pier
s a new app, dont
> declare anything in the parent sitemap you don't want to expose to
> subsitemap! :-)
>
> This will be consistent with the rest of Cocoon - otherwise somebody
> will ask for sitemap which does not inherits, say, generators...
Agreed wholeheartedly...
Pier
"Christopher Oliver" <[EMAIL PROTECTED]> wrote:
> Pier,
>
> Can you fix the IDL docs to show sendPageAndWait() returns a
> WebContinuation and takes a timeToLive parameter, unless/until we come
> up with an alternative interface that supports this functiona
"Niclas Hedhman" <[EMAIL PROTECTED]> wrote:
> On Wednesday 19 March 2003 04:14, Tony Collen wrote:
>> Reading this great article [1] (Thanks Pier!), I realized that the
>> mod_rewrite stuff could possibly be worked around using virtualhosts. I'm
>> no
"Carsten Ziegeler" <[EMAIL PROTECTED]> wrote:
> From: Pier Fumagalli [mailto:[EMAIL PROTECTED]
>>
>> "Carsten Ziegeler" <[EMAIL PROTECTED]> wrote:
>>
>>> Could please everyone add (his) open issues for a 2.1b1 release
>>> to
"Carsten Ziegeler" <[EMAIL PROTECTED]> wrote:
> Could please everyone add (his) open issues for a 2.1b1 release
> to the todo.docs? So, we have one single source of information.
"b" implies beta... We go straight to beta without an alpha???
Pier
On 18/3/03 23:00, "Stefano Mazzocchi" <[EMAIL PROTECTED]> wrote:
> But I have the impression i didn't understand what Pier was implying
> because I'm sure he would not propose to force people to write that much
> java gluecode just for everyday FOM usage.
>
On 18/3/03 23:03, "Stefano Mazzocchi" <[EMAIL PROTECTED]> wrote:
> Pier Fumagalli wrote:
>> On 18/3/03 21:00, "Stefano Mazzocchi" <[EMAIL PROTECTED]> wrote:
>>
>>
>>> I assume, but I'm not sure, that [xx are native internal obje
the session
I like your approach _MUCH_BETTER_... I think we should consider it for most
of the stuff we make visible to the flow, rather than passing the real Java
instances to Rhino (obviously removing the construction part when needed)...
Pier
"write" a "Flow"... You write a "Script" for the flow...
That was my idea when I wrote it though...
Any way you like it guys (I'll just let it be for another few hours to
hopefully make you change your mind, but I'm positive with anything)...
Pier
efine JVMPI_SHORT ((jint)9)
#define JVMPI_INT((jint)10)
#define JVMPI_LONG ((jint)11)
You never _never_ have access to the JVM internal objects from any
whatsoever possible pre-defined interface... And I tried... :-)
Pier
On 18/3/03 20:14, "Tony Collen" <[EMAIL PROTECTED]> wrote:
> Reading this great article [1] (Thanks Pier!), I realized that the
> mod_rewrite stuff could possibly be worked around using virtualhosts. I'm
> not too familliar with Apache HTTPD 2, but I assume s
"Vadim Gritsenko" <[EMAIL PROTECTED]> wrote:
> Pier Fumagalli wrote:
>
>> How does "AbstractTextSerializer" sets the content type header in the HTTP
>> response? The getMimeType method inherited from AbstractSerializer always
>> returns "nul
How does "AbstractTextSerializer" sets the content type header in the HTTP
response? The getMimeType method inherited from AbstractSerializer always
returns "null"...
Pier
. Now we have to decide what to expose in context and request... I
believe (or just inherit all?)...
Now, your personal IDL stenographer at work reflected the changes in the
sources... Can you guys please check the IDLDoc output to tell me where I
foobared up?
Thanks...
Pier
is"... So you can also
write:
alert("alert");
window.alert("window.alert");
this.alert("this.alert");
this.window.alert("this.window.alert");
That said, I believe that the best way to define global operations and
attributes is to define them in a so called "script" object, whose instance
is the one you're going to call from the sitemap...
So, "cocoon.sendPage()" becomes "this.cocoon.sendPage()"... JavaScript, as
Java, allows you to strip out the "this."...
Pier
1 - 100 of 441 matches
Mail list logo
