Reinhard Poetz wrote:
I propose making the status code attribute of serializers expandable.
This makes it easier to provide REST style services with Cocoon that
make use of the different meanings of status codes.
The proposal has been accepted. It got 9 binding +1 votes and no -1. I will
Ard Schrijvers napisał(a):
In this example, there is really no difference in output indeed, but if you
have one catch all matcher with one single serializer which is always used
for every request (I always use map:match pattern=** and then an aggregate
below it that aggregates content with
Ard Schrijvers napisał(a):
Hello,
Don't you have two distinct pipelines for rendering pages with forms
included and without? I don't details of your use case but IMO it is
good practice to have two distinct pipelines and decide in flow which
one should be used.
we rely on
Ard
[1] https://issues.apache.org/jira/browse/COCOON-1619
Could you Ard use e-mail client that is standard compliant
and produces
valid In-Reply-To headers? It's second time this week I have to raise
this issue (and I really don't like doing it) but it's really crucial
for me
Peter Hunsberger napisał(a):
On 3/30/07, Grzegorz Kossakowski [EMAIL PROTECTED] wrote:
The classic response has always been that dynamic conditional
pipelines have no place in Cocooon and that if you need them you are
looking at the problem incorrectly.
Hmmm... Maybe you are right. Let's
On 3/30/07, Grzegorz Kossakowski [EMAIL PROTECTED] wrote:
Peter Hunsberger napisał(a):
On 3/30/07, Grzegorz Kossakowski [EMAIL PROTECTED] wrote:
snip/
Isn't the real problem here that you can't pass header info up from
the sub-pipeline? We've talked about other reasons why this may need
Peter Hunsberger napisał(a):
I guess it depends on whether the original poster needs this for 2.2.
or 2.1?
Yes, but AFAIR we already agreed that we will stop developing 2.1.x
really soon a concentrate on 2.2.
What's more important, I think this change would break compatibility of
core
On 3/30/07, Grzegorz Kossakowski [EMAIL PROTECTED] wrote:
Peter Hunsberger napisał(a):
I guess it depends on whether the original poster needs this for 2.2.
or 2.1?
Yes, but AFAIR we already agreed that we will stop developing 2.1.x
really soon a concentrate on 2.2.
I don't think we've
Peter Hunsberger napisał(a):
On 3/30/07, Grzegorz Kossakowski [EMAIL PROTECTED] wrote:
Peter Hunsberger napisał(a):
I guess it depends on whether the original poster needs this for 2.2.
or 2.1?
Yes, but AFAIR we already agreed that we will stop developing 2.1.x
really soon a concentrate
Grzegorz Kossakowski wrote:
As for RC1... Yes, it means that we will stop massive changes and polish
things (like DOCUMENTATION) after RC1 is released. I guess final/next
candidate release would follow RC1 really soon. However, Reinhard seems
to have better idea of current plan.
Unless we have
Reinhard Poetz napisał(a):
Unless we have big concerns, we should have only one series of release
candidates and than a final release of all modules that have been
releases as milestones so far. As said some days ago, I plan to
release in the week after the Easter break.
Releasing more than
Grzegorz Kossakowski wrote:
The problem is that there will be no monolithic Cocoon 2.2. If we
consider Cocoon's core I guess it's quite stable and ready to be
released as final. In order to do some productive things with it we need
forms, ajax, templates and servlet services (maybe I forgot
Reinhard Poetz wrote:
I propose making the status code attribute of serializers expandable.
This makes it easier to provide REST style services with Cocoon that
make use of the different meanings of status codes.
+1
Jeroen
Reinhard Poetz wrote:
I propose making the status code attribute of serializers expandable.
This makes it easier to provide REST style services with Cocoon that
make use of the different meanings of status codes.
+1. Should have actually been there right from the start!
Sylvain
--
Sylvain
Reinhard Poetz wrote:
I propose making the status code attribute of serializers
expandable.
This makes it easier to provide REST style services with Cocoon that
make use of the different meanings of status codes.
+1. Should have actually been there right from the start!
big +1
I missed the discussion before the vote, but have one more question:
Is it also possible to add extra optional http headers in the serializer, like:
map:serialize type=xhtml pragma={cache} cache-control={cache}
I would like to store in a variable wether I am dealing with something that is
not
Ard Schrijvers napisał(a):
I missed the discussion before the vote, but have one more question:
Is it also possible to add extra optional http headers in the serializer,
like:
map:serialize type=xhtml pragma={cache} cache-control={cache}
I would like to store in a variable wether I am
Ard Schrijvers wrote:
I missed the discussion before the vote, but have one more question:
Is it also possible to add extra optional http headers in the serializer, like:
map:serialize type=xhtml pragma={cache} cache-control={cache}
I would like to store in a variable wether I am dealing with
Ard Schrijvers wrote:
I missed the discussion before the vote, but have one more question:
Is it also possible to add extra optional http headers in
the serializer, like:
map:serialize type=xhtml pragma={cache}
cache-control={cache}
I would like to store in a variable wether
Ard Schrijvers napisał(a):
I missed the discussion before the vote, but have one more question:
Is it also possible to add extra optional http headers in
the serializer, like:
map:serialize type=xhtml pragma={cache}
cache-control={cache}
I would like to store in a variable
Ard Schrijvers napisał(a):
I am not in favor of this. When you only create a form with a continuation
based on the contents of some xml file, you do not know which pipelines do,
and which do not contain a form. You do know in flow when you are creating a
form/continuation. Setting a
On 3/29/07, Ard Schrijvers [EMAIL PROTECTED] wrote:
... Please see HttpHeaderAction, can set any response header you want
I know. But, it does not work when you set the response header in a
subpipeline, so you *have* to do this in the pipeline which contains the
serializer...
See also
Ard Schrijvers wrote:
Ard Schrijvers wrote:
I missed the discussion before the vote, but have one more question:
Is it also possible to add extra optional http headers in
the serializer, like:
map:serialize type=xhtml pragma={cache}
cache-control={cache}
I would like to store in a variable
Reinhard Poetz wrote:
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
Is there a specific reason why this patch
(http://issues.apache.org/jira/browse/COCOON-1354) has never been applied?
Technically, other than rewriting the last chunk of the patch, it looks Ok.
From procedure POV, I don't
On 3/28/07, Reinhard Poetz [EMAIL PROTECTED] wrote:
snip/
I propose making the status code attribute of serializers expandable. This makes
it easier to provide REST style services with Cocoon that make use of the
different meanings of status codes.
Could you explain what you mean by
Peter Hunsberger wrote:
On 3/28/07, Reinhard Poetz [EMAIL PROTECTED] wrote:
snip/
I propose making the status code attribute of serializers expandable.
This makes
it easier to provide REST style services with Cocoon that make use of the
different meanings of status codes.
Could you
Reinhard Poetz wrote:
I propose making the status code attribute of serializers expandable.
This makes it easier to provide REST style services with Cocoon that
make use of the different meanings of status codes.
+1
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
Reinhard Poetz schrieb:
Reinhard Poetz wrote:
I propose making the status code attribute of serializers expandable.
This makes it easier to provide REST style services with Cocoon that
make use of the different meanings of status codes.
+1
+1
On 3/28/07, Reinhard Poetz [EMAIL PROTECTED] wrote:
Peter Hunsberger wrote:
On 3/28/07, Reinhard Poetz [EMAIL PROTECTED] wrote:
snip/
I propose making the status code attribute of serializers expandable.
This makes
it easier to provide REST style services with Cocoon that make use of the
Reinhard Poetz napisał(a):
Reinhard Poetz wrote:
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
Is there a specific reason why this patch
(http://issues.apache.org/jira/browse/COCOON-1354) has never been
applied?
Technically, other than rewriting the last chunk of the patch, it
looks
Reinhard Poetz escribió:
I propose making the status code attribute of serializers expandable.
This makes it easier to provide REST style services with Cocoon that
make use of the different meanings of status codes.
+1
Best Regards,
Antonio Gallardo.
31 matches
Mail list logo
