[results][vote] Make status code attribute of seriailzers expandable
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
implement it as soon as time permits.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Make status code attribute of seriailzers expandable
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 something). Most of them is really near finishing. Above set is what understand by Cocoon 2.2. Do others have different view? Everybody have his own list of favorite blocks; mine includes forms, templates, poi, fop, batik, databases, repository, ... But services isn't in my list because it is possible to use Cocoon 2.2 in the same manner as Cocoon 2.1 (with monolithic cocoon.xconf), which makes for low migration barrier - the only thing which is 'broken' compared with 2.1 is logging. Vadim
JIRA subprojects (was: Re: Make status code attribute of seriailzers expandable)
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 half of ours modules is *a lot* of work. After the > series of final releases (scheduled for May), we should only release > modules that have significant improvements or bugfixes. > I agree with all you said. Now, I wonder if we could create subprojects for most active Cocoon blocks/modules. Currently we use components for separation but AFAIK they can't have version independent from owning project. Is it technically possible to create these subprojects? Do you agree that I would be helpful to have them? Speaking for myself I really like task driven development. -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: Make status code attribute of seriailzers expandable
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 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 half of ours modules is *a lot* of work. After the series of
final releases (scheduled for May), we should only release modules that have
significant improvements or bugfixes.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Make status code attribute of seriailzers expandable
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 on 2.2. > > I don't think we've actually voted on that though I've seen > suggestions. Personally, I think we'd have to be close to releasing > 2.2 as a final release before stopping all development on 2.1? Don't > know if getting to RC1 counts 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 something). Most of them is really near finishing. Above set is what understand by Cocoon 2.2. Do others have different view? 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. >> What's more important, I think this change would break compatibility of >> core functionality and I'm not sure if it's desirable. > > I'm sure it could be made backwards compatible with yet another config > option... > If it was done that way then I have no problem that someone invest time doing it... -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: Make status code attribute of seriailzers expandable
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 actually voted on that though I've seen suggestions. Personally, I think we'd have to be close to releasing 2.2 as a final release before stopping all development on 2.1? Don't know if getting to RC1 counts What's more important, I think this change would break compatibility of core functionality and I'm not sure if it's desirable. I'm sure it could be made backwards compatible with yet another config option... -- Peter Hunsberger
Re: Make status code attribute of seriailzers expandable
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 functionality and I'm not sure if it's desirable. -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: Make status code attribute of seriailzers expandable
On 3/30/07, Grzegorz Kossakowski <[EMAIL PROTECTED]> wrote: Peter Hunsberger napisał(a): > On 3/30/07, Grzegorz Kossakowski <[EMAIL PROTECTED]> wrote: > > 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 > to be fixed (not my Validation example! ;-p), this sounds like a > concrete use case that supports the need to fix it? Yes. That's the real problem, but as I've said previously, I do not think that we need to "fix" anything regarding internal requests and just focus on new paradigm in servlet services. I guess it depends on whether the original poster needs this for 2.2. or 2.1? -- Peter Hunsberger
Re: Make status code attribute of seriailzers expandable
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 forget about this and focus on real problems. > > 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 > to be fixed (not my Validation example! ;-p), this sounds like a > concrete use case that supports the need to fix it? Yes. That's the real problem, but as I've said previously, I do not think that we need to "fix" anything regarding internal requests and just focus on new paradigm in servlet services. -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: Make status code attribute of seriailzers expandable
On 3/30/07, Grzegorz Kossakowski <[EMAIL PROTECTED]> wrote: Ard Schrijvers napisał(a): I see, it's classical example of situation where conditional (condition based on processed content) pipelines would be very helpful. Unfortunately, we don't have them (yet?). 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. 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 to be fixed (not my Validation example! ;-p), this sounds like a concrete use case that supports the need to fix it? -- Peter Hunsberger
RE: E-mail threading (was: Re: Make status code attribute of seriailzers expandable)
> > 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 to not get lost in all threads... Acceptee, was indeed my mistake. Ard > > Thanks. > > -- > Grzegorz Kossakowski > http://reflectingonthevicissitudes.wordpress.com/ > >
E-mail threading (was: Re: Make status code attribute of seriailzers expandable)
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 repository sources where the customer (the cms user) defines > wether or not a form is on the page, so, no...we cannot know in our main > pipeline what the headers should be > > >> Nevertheless, if you know in flow how headers should be set, why don't >> set them there? >> > > Then they only are set on the pipeline calling this flow, and according [1] > these are lost in the main pipeline > > 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 to not get lost in all threads... Thanks. -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: Make status code attribute of seriailzers expandable
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 repository sources where the customer (the cms user) defines > wether or not a form is on the page, so, no...we cannot know in our main > pipeline what the headers should be > I see, it's classical example of situation where conditional (condition based on processed content) pipelines would be very helpful. Unfortunately, we don't have them (yet?). > >> Nevertheless, if you know in flow how headers should be set, why don't >> set them there? >> > > Then they only are set on the pipeline calling this flow, and according [1] > these are lost in the main pipeline > COCOON-1619 is not bug IMO. It's just part of contract that internal pipelines are serve some data and do not interfere with original request. I think that was valid design decision at the time whole stuff was created. Now, the same problem applies for postable sources and servlet services. I've been thinking about it for a while and came to conclusion that information about result of processing (status code, various http headers) should be collected from all internal requests and even from pipeline components, prioritized and then information put into HTTP response should be calculated from these collected parts. Priorities would be assigned automatically based on simple rules like: when main pipeline and internal pipeline want to set the same header, main wins; when pipeline and pipeline's component want to set the same header, component wins etc. It's important at design level, see my comment here: https://issues.apache.org/jira/browse/COCOON-2009#action_12475631 Current situation where all components and pipelines have write access to whole environment is really bad because leads to the situation described in comment above. What do you think? -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: Make status code attribute of seriailzers expandable
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 below it that aggregates content with map:parts that delegate to subsitemaps > ). So, all request eventually use the same serializer. I cannot know in this > matcher, that there will be a form with contiuation, so I cannot set the > header in this pipeline (then stateless flat html pages would get a pragma > no-cache header for example). > > And, thx Bertrand for finding back the discussion [1], in combination with > the problem that setting http headers on internal pipelines do not make it to > the main pipepipeline, therefor, my suggestion to store it like the > status-code in a variable. Ofcourse, when [1] is easier to fix, that would > probably be the better way to go. > I do not follow you you here. You want to store status code in "variable". What kind of variable? Where it should be stored, how values of internal request should be returned to main pipeline? How this relates to ability to set status code in serializer? I think I understand what you want achieve and understand your trouble but do not understand proposed solution. -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
RE: Make status code attribute of seriailzers expandable
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 repository sources where the customer (the cms user) defines wether or not a form is on the page, so, no...we cannot know in our main pipeline what the headers should be > Nevertheless, if you know in flow how headers should be set, why don't > set them there? Then they only are set on the pipeline calling this flow, and according [1] these are lost in the main pipeline Ard [1] https://issues.apache.org/jira/browse/COCOON-1619 > > -- > Grzegorz Kossakowski > http://reflectingonthevicissitudes.wordpress.com/ > >
RE: Make status code attribute of seriailzers expandable
>
> I'm sorry, but I can't spot a difference between these two options:
>
> cache-control="{cache}"/>
>
> and:
>
>
>
>
>
>
>
> In both cases, sitemap parameter expansion will happen while
> sitemap is executed
> and pipeline is built. In first case you'd presumable set
> response headers in
> Serializer.setOutputStream() method, which is happening a bit
> later comparing
> with Action.act() of the second case, but still it should be
> the same effect,
> isn't it?
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 https://issues.apache.org/jira/browse/COCOON-1619
Ard
>
> Vadim
>
Re: Make status code attribute of seriailzers expandable
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:
cache-control="{cache}">
I would like to store in a variable wether I am dealing
with something that is not allowed to be cached by mod_cache,
like a cforms with continuation. We had a discussion before
on this list, but cannot find the thread ATM
I do not know about the serializers, but is this possible
and/or desirable?
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,
but quite normally, I have one main catch all matcher with the xhtml serialzer.
I'm sorry, but I can't spot a difference between these two options:
and:
In both cases, sitemap parameter expansion will happen while sitemap is executed
and pipeline is built. In first case you'd presumable set response headers in
Serializer.setOutputStream() method, which is happening a bit later comparing
with Action.act() of the second case, but still it should be the same effect,
isn't it?
Vadim
Re: Make status code attribute of seriailzers expandable
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 https://issues.apache.org/jira/browse/COCOON-1619, we discussed a possible solution a while ago. -Bertrand
Re: Make status code attribute of seriailzers expandable
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 variable at that point and be able to use it in > the serializer as an extra http header is IMO the only way > 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. Nevertheless, if you know in flow how headers should be set, why don't set them there? -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
RE: Make status code attribute of seriailzers expandable
> 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:
> >
> > cache-control="{cache}">
> >
> > I would like to store in a variable wether I am dealing
> with something that is not allowed to be cached by mod_cache,
> like a cforms with continuation. We had a discussion before
> on this list, but cannot find the thread ATM
> >
> I'm -1 for setting this in a serializer.
> > I do not know about the serializers, but is this possible
> and/or desirable?
> >
>
> I was going to propose the same but set on pipeline level. Then one
> would group pipelines sharing the same caching
> characteristics. We have
> already "expires" parameter for pipelines so I think it fits into
> current design.
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 variable at that point and be able to use it in
the serializer as an extra http header is IMO the only way
Ard
> As servlet sevice stuff demands high conformity with HTTP
> specification
> I'm all +1 on such addition.
>
> --
> Grzegorz Kossakowski
> http://reflectingonthevicissitudes.wordpress.com/
>
>
RE: Make status code attribute of seriailzers expandable
> 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:
> >
> > cache-control="{cache}">
> >
> > I would like to store in a variable wether I am dealing
> with something that is not allowed to be cached by mod_cache,
> like a cforms with continuation. We had a discussion before
> on this list, but cannot find the thread ATM
> >
> > I do not know about the serializers, but is this possible
> and/or desirable?
>
> 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, but quite normally, I have one main catch all matcher with the
xhtml serialzer. In this catch all matcher, I do not know wether or not I will
have a form with continuation, and I only want to set the header no-cache when
there actually is a continuation for example. The problem is way more subtle
then just a HttpHeaderAction and currently there is not a really easy solution
for having continuation in forms behind mod_cache (let alone a balanced
environment, where the sticky sessions come in)
Ard
>
> Vadim
>
Re: Make status code attribute of seriailzers expandable
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: I would like to store in a variable wether I am dealing with something that is not allowed to be cached by mod_cache, like a cforms with continuation. We had a discussion before on this list, but cannot find the thread ATM I do not know about the serializers, but is this possible and/or desirable? Please see HttpHeaderAction, can set any response header you want Vadim
Re: Make status code attribute of seriailzers expandable
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: > > > > I would like to store in a variable wether I am dealing with something that > is not allowed to be cached by mod_cache, like a cforms with continuation. We > had a discussion before on this list, but cannot find the thread ATM > I'm -1 for setting this in a serializer. > I do not know about the serializers, but is this possible and/or desirable? > I was going to propose the same but set on pipeline level. Then one would group pipelines sharing the same caching characteristics. We have already "expires" parameter for pipelines so I think it fits into current design. As servlet sevice stuff demands high conformity with HTTP specification I'm all +1 on such addition. -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Make status code attribute of seriailzers expandable
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:
I would like to store in a variable wether I am dealing with something that is
not allowed to be cached by mod_cache, like a cforms with continuation. We had
a discussion before on this list, but cannot find the thread ATM
I do not know about the serializers, but is this possible and/or desirable?
Ard
>
> 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 recall a VOTE on that. Previous
> decision on what
> can be expandable in the sitemap was VOTEd upon.
> >
> > I will start a vote on this then. Any opinions in the meantime?
>
> I don't see reason why not, even if not needed often.
>
> Vadim
>
> > My usecase is that I want to provide REST-style
> webservices with Cocoon and
> knowing which status code to set is part of the business logic.
>
>
>- o -
>
>
> 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.
>
> --
> Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
>
> {Software Engineering, Open Source, Web Applications, Apache Cocoon}
>
> web(log): http://www.poetz.cc
>
>
RE: [vote] Make status code attribute of seriailzers expandable
> 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 because I have needed it quite some times before! > > Sylvain > > -- > Sylvain Wallez - http://bluxte.net > >
Re: [vote] Make status code attribute of seriailzers expandable
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 Wallez - http://bluxte.net
Re: [vote] Make status code attribute of seriailzers expandable
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
Re: [vote] Make status code attribute of seriailzers expandable
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.
Re: [vote] Make status code attribute of seriailzers expandable
On 28.03.2007 17:55, Reinhard Poetz wrote: I propose making the status code attribute of serializers expandable. +1 Joerg
Re: [vote] Make status code attribute of seriailzers expandable
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 Ok. From procedure POV, I don't recall a VOTE on that. Previous > decision on what can be expandable in the sitemap was VOTEd upon. > > > > I will start a vote on this then. Any opinions in the meantime? > > I don't see reason why not, even if not needed often. > > Vadim > > > My usecase is that I want to provide REST-style webservices with > Cocoon and knowing which status code to set is part of the business > logic. > > > - o - > > > 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 -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: [vote] Make status code attribute of seriailzers expandable
On 3/28/07, Reinhard Poetz <[EMAIL PROTECTED]> wrote: Peter Hunsberger wrote: > On 3/28/07, Reinhard Poetz <[EMAIL PROTECTED]> 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. >> > > Could you explain what you mean by "expandable" a little? Can't do it any better than Jochen at the provided JIRA link: --- does not return the resolved variable sc as HTTP status code but simply returns 200 OK as HTTP code. Some applications may want to store the status code in a variable and pass this varibale to the serialzer, expecting it to expand it (Cocoon-Lenya is an example). Suggested enhancement patch to expand variables on the serializer is attached. Ah, got ya, you mean, return the "proper" status code or some such thing... +1 -- Peter Hunsberger
Re: [vote] Make status code attribute of seriailzers expandable
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
Re: [vote] Make status code attribute of seriailzers expandable
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
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: [vote] Make status code attribute of seriailzers expandable
Peter Hunsberger wrote:
On 3/28/07, Reinhard Poetz <[EMAIL PROTECTED]> 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.
Could you explain what you mean by "expandable" a little?
Can't do it any better than Jochen at the provided JIRA link:
---
does not return the resolved variable sc as HTTP status code but simply returns
200 OK as HTTP code. Some applications may want to store the status code in a
variable and pass this varibale to the serialzer, expecting it to expand it
(Cocoon-Lenya is an example).
Suggested enhancement patch to expand variables on the serializer is attached.
---
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: [vote] Make status code attribute of seriailzers expandable
On 3/28/07, Reinhard Poetz <[EMAIL PROTECTED]> 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. Could you explain what you mean by "expandable" a little? -- Peter Hunsberger
[vote] Make status code attribute of seriailzers expandable
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 recall a VOTE on that. Previous decision on what
can be expandable in the sitemap was VOTEd upon.
>
> I will start a vote on this then. Any opinions in the meantime?
I don't see reason why not, even if not needed often.
Vadim
> My usecase is that I want to provide REST-style webservices with Cocoon and
knowing which status code to set is part of the business logic.
- o -
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.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
