Marc Portier wrote:
Christian Haul wrote:
On 28.May.2003 -- 12:51 PM, Marc Portier wrote:
Christian Haul wrote:
map:transformers
map:transformer logger=sitemap.transformer.encodeURL
name=encodeURL
Christian Haul wrote:
Marc Portier wrote:
Christian Haul wrote:
On 28.May.2003 -- 12:51 PM, Marc Portier wrote:
Christian Haul wrote:
map:transformers
map:transformer logger=sitemap.transformer.encodeURL
name=encodeURL
on 5/28/03 7:22 AM Carsten Ziegeler wrote:
Stefano Mazzocchi wrote:
map:serializer name=xhtml
map:transformer type=link-translation/
map:serializer type=xhtml/
map:serializer
map:match pattern=...
map:generate src=.../
map:transform src=.../
map:serialize type=xhtml/
/map:match
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?
If callAction stays... why not:
map act(name, map)
map match(name, pattern, map)
boolean select(name, pattern, map)
Session
Stefano Mazzocchi wrote:
Cool. Sounds like many people are liking this ideas.
But let's defer this for post-2.1 when I will have more sitemap-based RT
to throw in.
This makes me a little bit curious :) - but, yes it's for post-2.1
Carsten
Christian Haul wrote:
On 28.May.2003 -- 12:51 PM, Marc Portier wrote:
Christian Haul wrote:
map:transformers
map:transformer logger=sitemap.transformer.encodeURL
name=encodeURL
src=org.apache.cocoon.transformation.EncodeURLTransformer/
Miles Elam wrote:
Stefano Mazzocchi wrote:
on 5/27/03 4:19 PM Sylvain Wallez wrote:
How is this different from a resource? Resources also allow to define
overloaded generators and transformers. So do we really need a new
concept ?
...
Resources were supposed to be reusable pipelines,
Marc Portier wrote, On 28/05/2003 8.38:
Miles Elam wrote:
...
What is the purpose of resources if this new syntax goes into effect
(which I like by the way)? What can a resource do that an overloaded
pipeline element cannot?
I think as Stefano said (slightly rephrased): it would deprecate the
On Tuesday, May 27, 2003, at 10:24 US/Pacific, Stefano Mazzocchi wrote:
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
Nicola Ken Barozzi wrote:
Marc Portier wrote, On 28/05/2003 8.38:
Miles Elam wrote:
...
What is the purpose of resources if this new syntax goes into effect
(which I like by the way)? What can a resource do that an overloaded
pipeline element cannot?
I think as Stefano said (slightly
On 28.May.2003 -- 09:25 AM, Nicola Ken Barozzi wrote:
Marc Portier wrote, On 28/05/2003 8.38:
Miles Elam wrote:
...
What is the purpose of resources if this new syntax goes into effect
(which I like by the way)? What can a resource do that an overloaded
pipeline element cannot?
I
Christian Haul wrote:
On 28.May.2003 -- 09:25 AM, Nicola Ken Barozzi wrote:
Marc Portier wrote, On 28/05/2003 8.38:
Miles Elam wrote:
...
What is the purpose of resources if this new syntax goes into effect
(which I like by the way)? What can a resource do that an overloaded
pipeline
On 28.May.2003 -- 12:51 PM, Marc Portier wrote:
Christian Haul wrote:
map:transformers
map:transformer logger=sitemap.transformer.encodeURL
name=encodeURL
src=org.apache.cocoon.transformation.EncodeURLTransformer/
map:transformer
On Tuesday, May 27, 2003, at 07:21 PM, Stefano Mazzocchi wrote:
Resources were supposed to be reusable pipelines, but *complete* ones!
Later, they were implemented to be usable as pipeline fragments but,
IMO, they impose some readability problems in the sitemap. The above
aims to correct that.
In
+1 for the FOM as discussed for now.
Ok, this is a little bit OT, but I have to respond :)
Stefano Mazzocchi wrote:
map:serializer name=xhtml
map:transformer type=link-translation/
map:serializer type=xhtml/
map:serializer
map:match pattern=...
map:generate src=.../
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:
html
head
...
link src=link:/styles/main.css ...
Hooray ;) For those who didn't know, this is what the linkrewriter
on 5/27/03 2:33 AM Bertrand Delacretaz wrote:
snips cause=agree or dont't understand implications enough to talk/
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
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. It
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 clear the
On Tue, 27 May 2003, Stefano Mazzocchi wrote:
snip/
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 your web application, you don't know where it
resides. In order to keep your webapp
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 that the getComponent() method removes all
needs for the callAction() method.
Stefano Mazzocchi wrote:
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()
Stefano Mazzocchi wrote:
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
Stefano Mazzocchi wrote:
on 5/27/03 2:33 AM Bertrand Delacretaz wrote:
snips cause=agree or dont't understand implications enough to talk/
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
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 did copy him. But the problem is
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 that the getComponent()
on 5/27/03 2:25 PM Giacomo Pati wrote:
On Tue, 27 May 2003, Stefano Mazzocchi wrote:
snip/
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 your web application, you don't know where
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. This
Stefano Mazzocchi wrote:
on 5/27/03 4:19 PM Sylvain Wallez wrote:
How is this different from a resource? Resources also allow to define
overloaded generators and transformers. So do we really need a new concept ?
...
Resources were supposed to be reusable pipelines, but *complete* ones!
Le Mardi, 27 mai 2003, à 18:33 Europe/Zurich, Stefano Mazzocchi a écrit
:
on 5/27/03 2:33 AM Bertrand Delacretaz wrote:
...I like that, but isn't there a possible attack where a client
makes a
lot of requests without cookies/session IDs, and overflows the poor
server who's creating millions of
30 matches
Mail list logo
