Re: Java Language Advocacy (was Re: How ASF membership works and what it means)

on 6/28/03 4:43 PM Nicola Ken Barozzi wrote: > The fact is that SWT is crap. Total crap. Pff, SWT is a thin layer on top of the operating system, everything else is native, therefore optimized and normally hardware accelerated (today's GPUs are gigaflop machines with gigabyte/sec video mem2mem tr

Re: [Flow] Calling internal-only pipelines

on 6/27/03 11:48 AM Stefano Mazzocchi wrote: > As for implementing this, I planned to look into this today. Ok, I dived into the code and I found where the problem is. The call to the sitemap invocation is located in the class org.apache.cocoon.components.flow.AbstractInterpreter

Re: Error/status codes in webapp sitemap

on 6/27/03 5:40 AM Upayavira wrote: > Dear All, > > The current webapp's sitemap doesn't report 404 for broken links. All it takes is > adding in the element. > > Apart from anything else, this lack breaks the CLIs ability to detect broken links > (as otherwise the error page is just returne

Re: [Flow] getComponent(id) implementation

on 6/27/03 4:47 AM Sylvain Wallez wrote: > Carsten Ziegeler wrote: > > >>Reinhard Pötz wrote: >> >> >> >>>The Cocoon object of the FOM has the method >>> >>> Component getComponent(id) >>> >>>It should return any component but no sitemap components. This means we >>>only return components defin

Re: [Flow] Calling internal-only pipelines

on 6/27/03 4:25 AM Jeremy Quinn wrote: > On Friday, June 27, 2003, at 06:48 AM, Reinhard Pötz wrote: > > >>One of the open issues of flow is that we can't send "internal-only" >>pipelines at the moment. >> >>If we call sendPage( uri, bizData) from the flow layer the forwardTo >>of the AbstractIn

Parrot [was Re: How ASF membership works and what it means]

copying the cocoon folks since we are getting pretty serious with continuations overthere (we implement them using a modified version of Mozilla Rhino, a javascript engine written in java) on 6/26/03 3:15 PM Ask Bjoern Hansen wrote: > On Thu, 26 Jun 2003, Santiago Gala wrote: > > [...] > >>I st

Re: FOM implementation

on 6/26/03 2:13 PM Reinhard Pötz wrote: > >>-Original Message- >>From: Pier Fumagalli [mailto:[EMAIL PROTECTED] >>Sent: Thursday, June 26, 2003 12:22 PM >>To: [EMAIL PROTECTED] >>Subject: Re: FOM implementation >> >> >>"

Re: Java Language Advocacy (was Re: How ASF membership works and what it means)

on 6/26/03 12:01 PM Christopher Oliver wrote: > Although I think Stefano's observation is correct that Sun's codebase is > a primary reason for Java "running everywhere", nevertheless it is an > undeniable reality that in my opinion makes Java development _much_ more > pleasant compared to C an

Re: FOM implementation

on 6/21/03 10:55 AM Christopher Oliver wrote: > OK. I didn't implement the following, so if you or anyone else would > like to, please go ahead: > > Cocoon.addEventListener() > Cocoon.removeEventListener(); > Cocoon.getComponent() > > Can someone explain the purpose and behavior of these operat

Re: FOM implementation

on 6/21/03 10:55 AM Christopher Oliver wrote: > OK. I didn't implement the following, so if you or anyone else would > like to, please go ahead: > > Cocoon.addEventListener() > Cocoon.removeEventListener(); > Cocoon.getComponent() > > Can someone explain the purpose and behavior of these operat

Re: [VOTE] Give all Cocoon committers CVS access?

on 6/24/03 7:19 AM Carsten Ziegeler wrote: > Nicola Ken Barozzi wrote: > >>Jeff Turner wrote, On 24/06/2003 13.38: >> >> >>>As most of you probably saw, there's a thread on cocoon-dev suggesting >>>that Forrest ought to be a Cocoon subproject, with the >> >>consensus being it >> >>>"makes sense"

Re: How ASF membership works and what it means

on 6/24/03 6:55 AM Dirk-Willem van Gulik wrote: > Then perhaps my observation means absolutely nothing - and I should really > try to get my mind around a fundamentally different development model (and > some aspect you call WORA). Oh, sorry, WORA := Write Once Run Anywhere. It's java's first com

Re: Syncing rhino

on 6/25/03 4:55 PM Gianugo Rabellino wrote: > Stefano Mazzocchi wrote: > > >>I think that the option of "active and direct" collaboration between >>Cocoon and Rhino would be better for both. It might increase their >>community, create a solid political link

Re: [RFI] Garbage

on 6/23/03 8:29 PM Pier Fumagalli wrote: > SetAttribute vs Well-formedness: > > > Briefly, I wanted to check with you people if a functionality like the XSLT > setattribute is required, or the non-well-formedness of Garbage is better > (see previous messages on thi

Re: FOM, views, and input modules

on 6/25/03 4:35 AM Reinhard Pötz wrote: >>From: Christopher Oliver [mailto:[EMAIL PROTECTED] >> >>I modified the FOM implementation in the scratchpad to make the FOM >>available to the view layer, thinking that the view author >>also should >>see the FOM (See FOM_JavaScriptFlowHelper.java), ra

Re: FOM, views, and input modules

on 6/25/03 4:35 AM Reinhard Pötz wrote: >>From: Christopher Oliver [mailto:[EMAIL PROTECTED] >> >>I modified the FOM implementation in the scratchpad to make the FOM >>available to the view layer, thinking that the view author >>also should >>see the FOM (See FOM_JavaScriptFlowHelper.java), ra

Re: Syncing rhino

on 6/24/03 3:48 PM Christopher Oliver wrote: > Although I think it would be nice to sync with the Rhino cvs, I can tell > you from personal experience that the Rhino code at cocoondev.org is > more stable than Cocoon itself at this point. > > So I think trying to place the blame on Rhino for not

Re: Syncing rhino

on 6/24/03 2:29 PM Gianugo Rabellino wrote: > Geoff Howard wrote: > > >>>This is good news. I understand that it's very difficult, but I hope >>>that it might be easier than you think, and I hope I can somehow help >>>you in that. Anyway, given that you are the only one showing some >>>intere

Re: Syncing rhino

on 6/24/03 12:30 PM Geoff Howard wrote: > At 01:00 PM 6/24/2003, Gianugo wrote: > >>Christopher Oliver wrote: >> OK... I spent some more time with the code and did some steps forward. Now, unfortunately, I'm stuck due to my ignorance: any further step would be just a wild bet from m

Re: [vote] Reinhard Potz as a Cocoon committer

on 6/24/03 2:24 AM David Crossley wrote: > David Crossley wrote: > >>I propose Reinhard Pötz to be a Cocoon committer. > > > The summary so far is 21 positive votes and no negative votes. > > Is there an official duration that i have to wait before asking > root to set up the account? It has b

Re: doc to explain incubation of sub-projects

on 6/21/03 10:45 PM David Crossley wrote: > I think that we need a document that clearly explains what it > means to be a "Cocoon sub-project under incubation". > > This would go at the top-level of the cocoon website and help to > explain the mysterious statements on the Cocoon and Lenya home pa

Re: Permanent Redirects

on 6/23/03 2:10 AM Upayavira wrote: > I've worked out how I'd like to implement permanent redirects. I'd appreciate > comments as to whether this approach is okay. I would rather have comments > before just doing it... > > Add to o.a.c.environment: > > public interface PermanentRedirector { >

Re: ResourceExistsAction

on 6/23/03 6:22 AM Steven Noels wrote: > On 23/06/2003 11:18 John Morrison wrote: > > >>Sure! Patches always welcome :) > > > Technically, all Lenya people have Cocoon CVS commit karma if I read the > avail file correctly. Hmmm, if this is the case, that even Forrest committers has to have t

Re: [RFI] Garbage

on 6/22/03 2:01 PM Christopher Oliver wrote: > OK, I added GarbageGenerator to the scratchpad and integrated it with > the flow layer. I also added a copy of the Calculator flowscript sample > using the garbage generator to the scratchpad samples. Wow, you guys rock! community power at work! >

Re: [SourceResolver] getLastModified() for cocoon:// sources always returns 0

on 6/22/03 3:32 PM Christopher Oliver wrote: > In Linotype I saw some other strange uses of the cocoon:// protocol that > appear to be very bad for performance: > There's a pipeline that uses the directory generator to read a > directory, and transforms it using xslt into a cinclude template. >

Re: looking at linotype

on 6/22/03 5:28 AM Jeremy Quinn wrote: > Hi All > > Looking at the marvellous LinoType . I have one question: > > Since the login() method calls 'cocoon.createSession()', should the > 'logout()' method not invalidate the Session? yeah, well, you're right, I overlooked that. > Is there a m

Re: flow - database.js - Componentmanager

on 6/22/03 1:36 PM Christopher Oliver wrote: > Agree. I've moved Database.js and related out of the core and into the > scratchpad for now, until petstore gets refactored. Thanks dude. -- Stefano.

Re: [Flow] Preparing the vote - long!

on 6/22/03 5:06 AM Christian Haul wrote: > Stefano Mazzocchi wrote: > >>on 6/20/03 2:01 PM Christian Haul wrote: >> >>>Reinhard Pötz wrote: > > >>>>*

Re: [Flow] Preparing the vote - long!

on 6/22/03 3:07 AM Steven Noels wrote: > On 22/06/2003 8:56 Upayavira wrote: > > >>Just to clarify - Stefano was only suggesting removing input/output >>modules from FOM, not Cocoon or the sitemap (where they are >>appropriate). >> >>Do your comments still stand? > > > If that was what he was

Re: How ASF membership works and what it means

on 6/23/03 8:42 AM Dirk-Willem van Gulik wrote: > > On Mon, 23 Jun 2003, Steven Noels wrote: > > >>Stefano's insightful post got me carried away to run some stats on >>members & projects: http://blogs.cocoondev.org/stevenn/archives/001008.html > > > I've always stopped short of doing just thi

Re: [Flow] Preparing the vote - long!

on 6/20/03 2:01 PM Christian Haul wrote: > Reinhard Pötz wrote: > > >>** >>* FOM (Flow Object model)* >>** > > >>Context object >>

Re: flow - database.js - Componentmanager

on 6/20/03 11:52 AM Reinhard Pötz wrote: > Yes, you are right. The current draft of the FOM does not contain a > database layer. > > I see two options: > > 1.) remove it complety > 2.) add it to the petstore examples (which are based on those JS > functions) > > I'm in favour of removing the

Re: [vote] Reinhard Potz as a Cocoon committer

on 6/21/03 10:11 PM Geoff Howard wrote: >>I propose Reinhard Pötz to be a Cocoon committer. > > > +1 big +1! -- Stefano.

How ASF membership works and what it means

NOTE: copying members@ and community@ since this might be helpful to many people. As many of you know, three cocoon committers were nominated then elected members of the Apache Software Foundation yesterday. Since I've been inquired by a few on how the system works, I'll spend some words on the pr

Re: [RFI] Garbage

on 6/21/03 4:00 PM Pier Fumagalli wrote: > Thank you for your kind support guys... > > As Chris wants to play with the toy, I'll start putting it into the > scratchpad, but please note, garbage for now has its own build system and > stuff... For now (part one) I'll simply copy the CVS repo I have

Re: [RFI] Garbage

on 6/19/03 8:23 AM Peter Royal 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 was more of a, "why (nearly) re-invent the > wheel".. B

Re: [RT] [Cocoon 2.2] Stacktraces in context

on 6/19/03 6:18 AM Matt Sergeant wrote: > On Wed, 18 Jun 2003, Stefano Mazzocchi wrote: > > >>>What about a stacktrace like this: >>> >>>Error occurred at: >>>Java: org.apache.cocoon.components.SomeComponent.Configure:237:4 >>>Sitemap:

Re: Linotype editing: browser requirements?

on 6/19/03 2:10 AM Ugo Cei wrote: > Stefano Mazzocchi wrote: > >>Hey, wait a second. The ad-hoc namespace is added as a wrapper by the >>request processing pipeline, it is *NOT* sent by the client code. > > > I see. I'm still thinking that it's best

Welcome the new ASF members

higher level of ASF participation. -- Stefano Mazzocchi <[EMAIL PROTECTED]>

Re: [RT] [Cocoon 2.2] Stacktraces in context

on 6/18/03 4:39 PM Bart Guijt wrote: > Hi all, > > I am using Cocoon for almost a year now and if one thing bugs me, it is > this: if something fails to operate successfully, the Java stacktraces fail > most of the time to correctly show how the error occurred. Yeah, damn, don't tell me, this ha

Re: Linotype editing: browser requirements?

on 6/18/03 3:07 PM Roger I Martin PhD wrote: > was getting the following double cocoon for the path to > linotype.users.properties > > org.apache.avalon.framework.CascadingRuntimeException: "file:/C:/Program > Files/jakarta-tomcat-5/dist/webapps/cocoon/samples/linotype/flow.js", line > 10: uncaug

Re: Linotype editing: browser requirements?

on 6/18/03 3:56 AM Sylvain Wallez wrote: > Gianugo Rabellino wrote: > > > >>BTW, Stefano: Linotype *really* kicks ass. Problem is that from you we >>aren't expecting anything less, so this is why you are not getting all >>the kudos you deserve. :-) But it's really, really, really a good job!

Re: Linotype editing: browser requirements?

on 6/18/03 3:16 AM Ugo Cei wrote: > Gianugo Rabellino wrote: > >>>Anyway, I'm wondering why the multipart request. Is it because of >>>images? If it weren't for images, wouldn't it be better to POST a >>>text/xml body with all the necessary information, putting the "verb" >>>(save, delete, etc

Re: Linotype editing: browser requirements?

on 6/18/03 2:12 AM Ugo Cei wrote: > Stefano Mazzocchi wrote: > >>No, no need for that. It took me half an hour to figure that problem out >>myself and it's an indication of how generally badly designed is >>cocoon's handling of multipart-encoded POST reque

Re: Linotype editing: browser requirements?

on 6/17/03 3:54 PM Steven Noels wrote: > On 17/06/2003 22:41 Stefano Mazzocchi wrote: > > >>>I dropped the 'd' typo (I assume) from the offending line, and that one >>>is gone. The 'save', 'revert' and 'delete' action aren&#

Re: [Flow] Scope and Sessions

on 6/17/03 11:41 AM Reinhard Pötz wrote: > Today I tried to find out how sessions and flow work together: > > 1. If my tests are correct the global scope of a flow only >lives as long as the session which the flow is tied to is >active. > >So if the session expires or you use anoth

[vote results] FOM

The vote clearly indicates the community wants the "small -> big" approach. Chris has also removed his concerns. This gives us green light to go ahead and finish the FOM design as we proposed it. on 6/16/03 10:23 AM Reinhard Pötz wrote: > So let's try to finish the FOM! > > First I summarized t

Re: Linotype editing: browser requirements?

on 6/17/03 12:28 PM Ugo Cei wrote: > Stefano Mazzocchi wrote: > >>Yes, basically all browsers that support Mozilla Midas API which, for >>now are, Mozilla 1.3 or greater. Note that Midas is *NOT* part of >>standard Gecko, so Camino won't do it. > > > Hmmm,

Re: Linotype editing: browser requirements?

on 6/17/03 8:25 AM Steven Noels wrote: > On 17/06/2003 9:47 Steven Noels wrote: > >>On 17/06/2003 8:02 Bertrand Delacretaz wrote: >> >> >>>Linotype looks great but I'm not sure about the browser requirements. >>> >>>IIUC from "welcome to Linotype" page, the editing mode only requires >>>Mozilla

Re: Linotype editing: browser requirements?

on 6/17/03 2:47 AM Steven Noels wrote: > On 17/06/2003 8:02 Bertrand Delacretaz wrote: > > >>Linotype looks great but I'm not sure about the browser requirements. >> >>IIUC from "welcome to Linotype" page, the editing mode only requires >>Mozilla 1.3, is that right? > > > and I've got an

Re: Linotype editing: browser requirements?

on 6/17/03 1:02 AM Bertrand Delacretaz wrote: > Linotype looks great but I'm not sure about the browser requirements. > > IIUC from "welcome to Linotype" page, the editing mode only requires > Mozilla 1.3, is that right? Yes, basically all browsers that support Mozilla Midas API which, for now

[Fwd: Re: [ANN] Orixo launched]

Damn, sent only to [EMAIL PROTECTED] Sorry -- Stefano. --- Begin Message --- on 6/16/03 5:27 AM Matthew Langham wrote: > To the Cocoon Community > > The involvement of commercial entities in an open source project can help > tremendously with its success. If we look at the Linux OS, the Apache

Re: Cocoon 2.1 showstopper?

on 6/16/03 1:20 AM Carsten Ziegeler wrote: > Hi, > > I think I found a showstopper for 2.1 :( : > 2.1 is not binary compatible to 2.0.x - if you compile a (sitemap) > component using 2.0.x and put this into 2.1 it will in most cases > fail to run. As a simple example, you can use the FileGenerat

[vote] FOM design methodology

The FOM is the API contract between the flowscript and the rest of Cocoon. In the next few years, I believe that the FOM and the sitemap semantics will be recognized as the single most important contracts in Cocoon. Solidity and well behaved evolution of those contracts will be vital to the succes

Re: FOM blocking 2.1 release

on 6/15/03 3:53 PM Christopher Oliver wrote: > Stefano Mazzocchi wrote: > > >>Ovidiu wrote the FOM with "let's cover everything" mindset. He restated >>the fact that he likes this approach better on his last mail to this list. >> >>The proble

Re: FOM blocking 2.1 release

on 6/15/03 6:42 AM Steven Noels wrote: > On 15/06/2003 0:31 Stefano Mazzocchi wrote: > > >> 1) I will try to patch the FOM for the proposed plan for June 24th. >> >> 2) If I can't do it, we release with what we have and we state loud and >>clear that

Re: Finding Linotype

on 6/14/03 3:52 PM Michael Wechner wrote: > Stefano Mazzocchi wrote: > > >>on 5/30/03 7:13 AM Upayavira wrote: >> >> >> > > > >>> >>> >> >>I'm back from my devastating, challenging yet superfun 2 week peruvian &

FOM blocking 2.1 release

We have a horrible time following good release early and often practices and the more we go, the worst. You all know that I'm not happy with the current FOM design because of the based on the concept of "let's try to do everything", while I favor the approach "do the simplest thing that can possib

Re: [RT] FOM

on 5/29/03 9:43 PM Vadim Gritsenko wrote: > Stefano Mazzocchi wrote: > > >>void callAction(name,map) -> invoques the action indicated by the given >>name and pass the given map as model >> > > > How action returns its result? you are right, the ab

Re: Cocoon Nuke

on 6/8/03 6:03 AM Bertrand Delacretaz wrote: > Le Samedi, 7 juin 2003, à 09:44 Europe/Zurich, Sylvain Wallez a écrit : > > >>the code samples made my hair draw up on my head : hardcoded HTML >>in Java code !! > > > Blessed arth thou, who haveth hair on their head ;-) ahah > It shows tha

Re: Finding Linotype

on 5/30/03 7:13 AM Upayavira wrote: > Dear All, > > I would like to download and try Linotype, but can't find it. The page at: > > http://www.betaversion.org/~stefano/dist/linotype_1.0.tar.gz > > doesn't work. Anyone know where I can find it? > > Regards, Upayavira > I'm back from my devasta

Re: [proposal] move stuff from scratchpad into the trunk

on 5/28/03 8:03 AM Christopher Oliver wrote: > FlowVelocityGenerator to replace VelocityGenerator Does it have any drawbacks? if not, +1 all the way. -- Stefano.

Re: [proposal] move stuff from scratchpad into the trunk

on 5/28/03 7:29 AM Carsten Ziegeler wrote: > Stefano Mazzocchi wrote: > >>Here is what I propose to move: >> >> 1) ImageReader >> 2) Paginator >> 3) JXTemplate* >> > > +1 > > >>anything else? > > > Do we have any poli

Sitemap-Extended Pipeline Components [Re: [RT] FOM]

on 5/28/03 7:22 AM Carsten Ziegeler wrote: > Stefano Mazzocchi wrote: > >> >> >> >> >> >> >> >> >> >> >> > I think this is a very useful concept. Do you remember our discussion from > two years ago ab

Re: Overloaded pipeline elements (Was Re: [RT] FOM)

on 5/28/03 2:25 AM Nicola Ken Barozzi wrote: > I mean, if we make use of resources as callable full or partial sitemap > snippets, what would we loose that we instead get from using this new > concept? "extending" a component in a compositional way ('overloading' is a misnomer, I apologize for

Re: Unplugging

on 5/28/03 1:43 AM Nicola Ken Barozzi wrote: > > Tony Collen wrote: > > > >>Hi everybody, > >> > >>I've decided to unplug for a while. > > >>http://manero.org/weblog/ > > David Crossley wrote, On 28/05/2003 2.22: > > >>Thanks Tony, for all the excellent contributions that you >>have

[proposal] move stuff from scratchpad into the trunk

Here is what I propose to move: 1) ImageReader 2) Paginator 3) JXTemplate* anything else? -- Stefano.

Re: [RT] FOM

on 5/27/03 4:19 PM Sylvain Wallez wrote: > Ok. By "component", I actually meant "instance" obtained by lookup() or > getComponent(). Then we have a big problem here : automatic component > release is very likely to be handled by the container at special times > such as end of request processing

Re: [RT] FOM

on 5/27/03 2:25 PM Giacomo Pati wrote: > On Tue, 27 May 2003, Stefano Mazzocchi wrote: > > > >>This is, IMO, what the FOM requires. Nothing less, nothing more. But let >>me explain why I consider flow-driven URI handling harmful. >> >>Today, once you mount

Re: [RT] FOM

on 5/27/03 1:05 PM Geoff Howard wrote: > At 01:05 PM 5/27/2003, Stefano wrote: > >>on 5/27/03 4:06 AM Sylvain Wallez wrote: > > > > > void callAction(name,map) -> invoques the action indicated by the given name and pass the given map as model NOTE: I personally believe t

Re: [RT] FOM

on 5/27/03 4:20 PM Sylvain Wallez wrote: > Stefano Mazzocchi wrote: >>Ovidiu, please excuse me for copying you on this, but I would like to >>let you and everybody else know this: > > Stefano, seems like you were too fast at sending and forgot to CC Ovidiu... No, I

Re: [RT] FOM

on 5/27/03 1:44 AM Stefano Mazzocchi wrote: > Pier and I already stated a while back that our current implementation > of the FOM is weak and its design poor. In the past, it was exactly such comments that made Ovidiu abandon this community. Let me state things clearly so that we can cle

Re: [RT] FOM

on 5/27/03 4:06 AM Sylvain Wallez wrote: >>Object getComponent(id) -> obtains the component indicated by the given ID > > Why don't you use the traditional lookup() name ? Also, release() is > missing. So what about lookupComponent(id) and releaseComponent(id)? release() is missing on purpose.

Re: Scheduling service

on 5/27/03 9:12 AM Mato Mira, Fernando wrote: > It would be nice if Cocoon had an scheduling service for background tasks. > For example, I have to keep alive a SOAP service session by sending it > requests once a minute. What about changing the expiration time of the session? -- Stefano.

Re: [RT] FOM

on 5/27/03 2:33 AM Bertrand Delacretaz wrote: > > > Le Mardi, 27 mai 2003, à 08:44 Europe/Zurich, Stefano Mazzocchi a écrit > : > >>... 2) design for safety: the flow will be a center of abuse because >>people >>will find it easier to write longer flows tha

Re: [RT] FOM

on 5/27/03 7:18 AM Jeff Turner wrote: > On Tue, May 27, 2003 at 01:44:45AM -0500, Stefano Mazzocchi wrote: > > >>How? >> >>Using a link-translating protocol. >> >>Example: >> >> >> >> ... >> > > > Ho

Re: [HEADS-UP] writing components for cache efficiency

on 5/14/03 4:29 AM Sylvain Wallez wrote: > Stefano Mazzocchi wrote: > >>how about wikifying this? :-) > > http://wiki.cocoondev.org/Wiki.jsp?page=WritingForCacheEfficiency ! Thanks! -- Stefano.

Re: Regarding Excalibur XMLUtil and Store

on 5/14/03 1:24 AM Carsten Ziegeler wrote: > I absolutely agree with the above - so this will be an interesting time ;) Ok, super cool. If we all agree on this line of action, this makes things much easier for me. >>As soon as Cocoon 2.1 is out of the door I'll start working on it, >>either as a

Re: cvs commit: cocoon-2.1/src/scratchpad/src/org/apache/cocoon/transformationJXPathTransformer.java

on 4/6/03 6:50 AM [EMAIL PROTECTED] wrote: > coliver 2003/04/05 20:50:48 > > Modified:src/scratchpad/src/org/apache/cocoon/transformation > JXPathTransformer.java > Log: > Fixed breakage caused by Stefano's cleanup: I think you need to be equally picky > abo

Issues with chaperon

We were very picky with Ivelin and his move to factor out xmlform, but I'm going to be as well with Chaperon. There are few things that I don't like: 1) copyright is given to the ASF. While I *do* appreciate the intention, the ASF's policy cannot allow this (I'm going to be picky on those things

Re: [POLL] Removing Roles File?

Berin Loritsch wrote: Fortress (The ECM replacement) has a feature that allows you to automatically gather all your roles and components that implement those roles at runtime. There is no need to maintain a separate file, or to include a "user-roles" document. Hmmm, how do you do that? I mean, the

Re: [RT] the quest for the perfect template language

Hunsberger, Peter wrote: Are you sure they don't need to be Turing complete? I suspect so... See my previous reply: what should be in charge of 'adapting' the data for the view? the view itself or the underlying controlling stage? Instead of controller -(model)-> view I would separate 'cont

Re: [OT] Re: [RT] the quest for the perfect template language

Pier Fumagalli wrote: "Stefano Mazzocchi" <[EMAIL PROTECTED]> wrote: [I wonder if laughing at this hopelessly moves me from the 'youngs' into the 'olds'... who cares anyway ;-)] I was downloading yesterday Doom for my cellphone (yeah, it runs)... As the page

Re: Are Actions Redundant in a Flowscript world?

Tony Collen wrote: On Fri, 4 Apr 2003, Richard In Public wrote: 2. If this is the case, then I am left wondering about ACTIONS: would one still want to use, for example, database actions in the sitemap, rather than calling a persistence layer from within the flowscript? Funny, I was just conte

Re: Are Actions Redundant in a Flowscript world?

Richard In Public wrote: Hi I'm trying to get to grips with how the introduction of Flowscript effects Cocoon best practices. Some questions (half-baked, I know): 1. Should CONTROL be handled exclusively by Flowscript? Looking over the examples, particularly the 'prefs' one, it seems that the s

Re: [GUMP] Build Failure - cocoon-block-web3

Sam Ruby wrote: Stefano Mazzocchi wrote: compile-scratchpad: [javac] Compiling 39 source files to /home/rubys/jakarta/cocoon-2.1/build/cocoon-20030404/scratchpad/dest [javac] /home/rubys/jakarta/cocoon-2.1/build/cocoon-20030404/scratchpad/src/org/apache/cocoon/transformation

Re: [heads-up] Updated upload system and fixed a bunch of securityissues

Vadim Gritsenko wrote: Stefano Mazzocchi wrote: ... Anyway, I also fixed a number of security issues. Most notably: 1) uploaded files are saved on disk by default (and web.xml has been changed accordingly) as a temporary storage. 2) uploaded files saved on disk are removed right at the end of

Re: [RT] the quest for the perfect template language

Diana Shannon wrote: On Friday, April 4, 2003, at 09:56 AM, Stefano Mazzocchi wrote: I really don't understand why some of you are so emotionally attached to something like but even more I'm surprised to see 'conservationism' on this list. Are you guys getting old or sh

Re: [Fwd: [heads-up] Updated upload system and fixed a bunch of securityissues]

Sylvain Wallez wrote: Stefano Mazzocchi wrote: Note that the Cocoon Environment Request object transparently wraps around the Object get(String name) method, so, you don't have to do any type casting since this is transparently done for you. The only difference is that since the C

How to use the file uploading mechanism in cocoon

Start with the following page the hook the /upload URL to a flow function then write the flow function var role = Packages.org.mystuff.UploadManager.ROLE; function upload() { var uploader = cocoon.componentManager.getComponent(role); var

Re: [Fwd: [heads-up] Updated upload system and fixed a bunch of securityissues]

Stefano Mazzocchi wrote: Let's see if this time gets thru. no :-( stupid mozilla saved it trunkated in my sent folder as well. ok, I'll rewrite it :- -- Stefano.

Re: [RT] the quest for the perfect template language

Hunsberger, Peter wrote: And anyway, when somebody points you to the stars, make sure you don't stop looking at the finger. Sorry, I don't see any stars the direction the finger is pointed in this particular case Fair enough. -- Stefano.

Re: [RT] the quest for the perfect template language

Nicola Ken Barozzi wrote: Stefano Mazzocchi wrote, On 03/04/2003 13.12: Nicola Ken Barozzi wrote: ... Apart from the fact that it lacks brackets, and thus needs an extra transformation, what does this give us? the beauty of the XSLT concepts without the mental drag of the xml syntax. So

[Fwd: [heads-up] Updated upload system and fixed a bunch of securityissues]

Let's see if this time gets thru. -- Stefano. --- Begin Message --- First of all, the servlet api decided not to deal with the payload of the servlet request in case of file-upload. So, either you parse the inputstream yourself, or you wrap the request with something different. Cocoon uses the

Re: [heads-up] Updated upload system and fixed a bunch of securityissues

Stefano Mazzocchi wrote: e the following HTML: ohhh, fuck fuck fuck! But I saved it this time :-) Stefano.

Re: [GUMP] Build Failure - cocoon-block-web3

[EMAIL PROTECTED] wrote: This email is autogenerated from the output from: Buildfile: build.xml init: init-tasks: prepar

[heads-up] Updated upload system and fixed a bunch of security issues

First of all, the servlet api decided not to deal with the payload of the servlet request in case of file-upload. So, either you parse the inputstream yourself, or you wrap the request with something different. Cocoon uses the second approach: the incoming servlet request is wrapped and this w

Re: Perfect template language

Matt Sergeant wrote: Saw your thread on cocoon-dev. Have you ever checked out TAL [1] from the Zope project? It makes things a *lot* easier for page designers - they just add attributes to where the dynamic output goes, and their design can contain mock-ups of what it should look like. Works nic

Re: [RT:Long] Initial Results and comments (was Re: Compiling XML,and its replacement)

Berin Loritsch wrote: Stefano Mazzocchi wrote: I'll also be interested to see how different the performance gets on hotspot server/client and how much it changes with several subsequent runs. Well, with HotSpot client and a 15.4 KB (15,798 bytes) test document (my build.xml file), I go

Re: [RT] the quest for the perfect template language

Robert Koberg wrote: Daniel Fagerstrom wrote: "request::lang" etc, could be translated to the the XSLT function "document(request:/lang)", where "request:" is a Source. With the new Source and XSLTProcessor implementations from excalibur we get cashing for free if the parameter to the document fun

  1   2   3   4   5   6   7   8   9   10   >