You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2003/11/05 12:41:53 UTC
[Vote] empty HTTP responses [was Re: Cannot easily set http status]
On Wednesday, Nov 5, 2003, at 12:19 Europe/Rome, Unico Hommes wrote:
> setStatus' friends the sendError brothers are also be eligible for FOM
> membership. But this change has a dependency on the discussion about
> bodyless responses since if you'd do a sendError from a flow script and
> then send a page afterwards this would result in errors.
I dislikde "sendError" because, in fact, HTTP does not have the concept
of errors, but only status codes and empty-payload responses.
In the future, it's entirely possible to have a 309 or equivalent that
is not an error, but has a empty-payload response. I would dislike to
call "sendError()" to send something that is not an error, feels hacky.
I think the optimal solution is:
1) add response.setStatus() in FOM
2) allow the flowscript to terminate without calling sendPage* [thus
resulting in an empty payload]
Vote?
--
Stefano.
Re: [Vote] empty HTTP responses [was Re: Cannot easily set http status]
Posted by Gianugo Rabellino <gi...@apache.org>.
Stefano Mazzocchi wrote:
>> setStatus' friends the sendError brothers are also be eligible for FOM
>> membership. But this change has a dependency on the discussion about
>> bodyless responses since if you'd do a sendError from a flow script and
>> then send a page afterwards this would result in errors.
>
>
> I dislikde "sendError" because, in fact, HTTP does not have the concept
> of errors, but only status codes and empty-payload responses.
>
> In the future, it's entirely possible to have a 309 or equivalent that
> is not an error, but has a empty-payload response. I would dislike to
> call "sendError()" to send something that is not an error, feels hacky.
>
> I think the optimal solution is:
>
> 1) add response.setStatus() in FOM
> 2) allow the flowscript to terminate without calling sendPage* [thus
> resulting in an empty payload]
Sorry to jump in late, I'm probably lagging behind a few posts, but was
the possibility of having *pipelines* send empty payload considered
instead? This way flow will always have to sendPage(), but the result
would be empty content anyway. With the added bonus of having the
pipeline flexibility to, say, set headers.
WDYT?
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Now blogging at: http://blogs.cocoondev.org/gianugo/)
change subjects please (was Re: [Vote] empty HTTP responses [was
Re: Cannot easily set http status])
Posted by Berin Loritsch <bl...@apache.org>.
Is this even still a vote? It seems that it has devolved into a conversation.
Perhaps a change in title will get more people in on the conversation--or
perhaps turning it into an RT would help.
Being drakonian on messages with [VOTE] in the title will make it clear if we
are still voting or not. I don't even know what the outcome of the vote was.
Guido Casper wrote:
> Stefano Mazzocchi wrote:
>
>>On 7 Nov 2003, at 13:52, Vadim Gritsenko wrote:
>>
>>
>>>Stefano Mazzocchi wrote:
>>>
>>>
>>>>On Thursday, Nov 6, 2003, at 14:39 Europe/Rome, Vadim Gritsenko
>>>>wrote:
>>>>
>>>>
>>>>>I agree with comments in this other thread that let's not introduce
>>>>>nested components in <map:call/>. Instead, if needed, let's
>>>>>introduce <act type="flow"/>. Sometime later.
>>>>
>>>>
>>>>-1
>>>
>>>
>>>Your -1 means: "replace later with never", right? Just to remove any
>>>possible point of confusion :)
>>
>>yes. I am against the silly
>>
>> <xxx>
>> ... do something if true
>> </xx>
>> .. do something if false
>>
>>syntax. doesn't matter what the logic that drives the "xxx" tag is or
>>what "xxx" is remapped to.
>
>
> Wow, that would rule out matchers as well.
> But it might make some sense since matchers are not all that different to
> actions ;-)
>
> Guido
>
>
>
>
Re: sitemap design
Posted by Giacomo Pati <gi...@apache.org>.
Stefano Mazzocchi wrote:
>
> The things I would like to see deprecated in the sitemap are:
>
> 1) action/action-sets (flow + real blocks make them unnecessary)
+1
> 2) resources (virtual components and the cocoon: protocol make them
> unnecessary)
+1
> 3) the ability to have generators/transformers/serializers inside
> <pipeline> (only matchers/error-handler should be there) [this shouldn't
> have been there in the first place!]
+1
--
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
RE: Namespace problems wit Hibernate
Posted by Hugo Burm <hu...@xs4all.nl>.
Thanks,
Problem solved.
Hugo
> -----Original Message-----
> From: Ugo Cei [mailto:u.cei@cbim.it]
> Sent: Saturday, November 08, 2003 7:50 PM
> To: dev@cocoon.apache.org
> Subject: Re: Namespace problems wit Hibernate
>
>
> Hugo Burm wrote:
> > 1) I have my own little Avalon component defined in
> cocoon.xconf. It is a
> > factory component that should generate Hibernate sessions. When
> Cocoon is
> > started by Tomcat, my component starts Hibernate. Hibernate
> tries to read
> > its configuration files. These files are XML files. Everything
> seems to work
> > fine, but when there is an element like eg <map> in this
> configuration file,
> > the boot process starts to complain about the fact that "<map>"
> should have
> > an attribute "role". The "<map>" element in my Hibernate
> configuration file
> > does not need this attribute "role". This looks like a
> namespace problem.
>
> What version of the Hibernate mapping DTD are you using? Version 2.0
> does not require the "role" attribute, but version 1 does. See
> <http://hibernate.sourceforge.net/hibernate-mapping.dtd> versus
> <http://hibernate.sourceforge.net/hibernate-mapping-2.0.dtd>.
>
> Ugo
>
>
Re: Namespace problems wit Hibernate
Posted by Ugo Cei <u....@cbim.it>.
Hugo Burm wrote:
> 1) I have my own little Avalon component defined in cocoon.xconf. It is a
> factory component that should generate Hibernate sessions. When Cocoon is
> started by Tomcat, my component starts Hibernate. Hibernate tries to read
> its configuration files. These files are XML files. Everything seems to work
> fine, but when there is an element like eg <map> in this configuration file,
> the boot process starts to complain about the fact that "<map>" should have
> an attribute "role". The "<map>" element in my Hibernate configuration file
> does not need this attribute "role". This looks like a namespace problem.
What version of the Hibernate mapping DTD are you using? Version 2.0
does not require the "role" attribute, but version 1 does. See
<http://hibernate.sourceforge.net/hibernate-mapping.dtd> versus
<http://hibernate.sourceforge.net/hibernate-mapping-2.0.dtd>.
Ugo
Namespace problems wit Hibernate
Posted by Hugo Burm <hu...@xs4all.nl>.
Environment: Windows XP, JDK 1.4, Tomcat 4.27, Cocoon 2.1.3 CVS 7 nov 2003
1) I have my own little Avalon component defined in cocoon.xconf. It is a
factory component that should generate Hibernate sessions. When Cocoon is
started by Tomcat, my component starts Hibernate. Hibernate tries to read
its configuration files. These files are XML files. Everything seems to work
fine, but when there is an element like eg <map> in this configuration file,
the boot process starts to complain about the fact that "<map>" should have
an attribute "role". The "<map>" element in my Hibernate configuration file
does not need this attribute "role". This looks like a namespace problem.
Why does cocoon assume some kind of an Avalon namespace when parsing
cocoon.xconf? I tried to create my own namespace for my Hibernate
configuration file, but that did not work.
Anyone?
2) I excluded Deli in the blocks. Deli creates about 200 lines of error
messages about "com.hp.hpl.jena.rdf.." when Tomcat starts Cocoon. These
errors occur with a vanilla build of Cocoon and have nothing to do with the
rest of this e-mail. This problem was reported before on the user list and
Mikael Björn pointed to the cause of this problem.
Hugo Burm
Re: sitemap design
Posted by Stefano Mazzocchi <st...@apache.org>.
On 8 Nov 2003, at 12:02, Guido Casper wrote:
> Stefano Mazzocchi wrote:
>> Careful. I'm against the use of
>>
>> <match src="something">
>> </match>
>> <read/>
>>
>> as well. The proper way should be
>>
>> <match src="something">
>> ...
>> </match>
>>
>> <match src="**">
>> <reader/>
>> </match>
>>
>> having the logic processing not following the element nesting, is,
>> IMO, very confusing and very bad practice.
>>
>> In the original sitemap design, it was *NOT* possible to have pipeline
>> components inside <pipeline>, only matchers. This is something that
>> was introduced while I wasn't watching, just like actions.
>>
>> Yes, actions are not the only the only things I dislike about the
>> sitemap: the tree processor introduced new ways of dealing with things
>> (like having resources without generators or serializers, or pipeline
>> components in pipelines without matchers)... but all these things
>> ended up being more harm than good from a usage perspective.
>>
>> So, what's the point of introducing something and then come out with
>> "best practices" that prevent you from using them?
>
> Sorry if I added confusion.
>
> Yes, "best practices" has always been hard to come up with for Cocoon.
> This
> certainly has to do with the variety of usages users come up with.
> "Best
> practices" tend to have a short life anyway.
>
> I always wondered what the real difference between actions and
> matchers is
> and (thanks to the power of expressive names) came to the conclusion
> that
> it's the silent consensus to keep matchers side effect free while the
> side
> effect of actions is their primary purpose.
> You seem to be with Rickard Öberg's third principle for making software
> frameworks:
> "A framework's power comes not from what it allows, but from what it
> does
> not allow"
Of course!
> However this comes just after:
> "If you make a decision, be sure that it counts"
> http://www.jroller.com/page/rickard/20030419
>
> I somehow always had the feeling that Cocoon is different and its
> unrestrictiveness (is this the right word?) attracts the creatives and
> it's
> unforeseeable what they come up with. Cocoon is not just a framework
> for
> building aplications. It's more of a framework for building
> frameworks. But
> that's just my opinion.
Cocoon is definately *not* a framework for frameworks. Cocoon is a
vertical framework (specializes in one thing) while Avalon is an
horizontal one (covers many things).
The more cocoon becomes 'horizontal', the weaker it becomes. This is
why I'm against the "operating system for the web" concept. It's too
wide. Avalon suffers from marketing problems: it can be anything for
anybody (but rarely out of the box!), I don't want cocoon to suffer the
same thing.
Actions, in my mind, represent a vertical design going horizontal. We
spent 6 months designing the sitemap and actions came out in a few
weeks, stolen from webapp frameworks but with no idea on where they
were going to be. Introducing them was the biggest design mistake this
community ever made.
There is an easy design pattern to know if your sitemap component is
good or bad: ask yourself:
can you reuse it?
does it contain logic that is specific for your application?
The number of reusable actions is *very* small... and those actions
require normally so many parameters that the sitemap just becomes a
mess.
This shows that the logic that normally actions contain should not be
there... it required a completely different paradigm shift.
Which is what we did introducing the notion of flow.
Matchers were not abused because the matchers we ship are *highly*
reusable. As for generators, transformers, serialziers and selectors.
All of them were designed to be reusable.
Actions were introduced to keep stuff that is application specific....
thus they fell *out of place* in a context were component reusability
is much greater.
I believe that people used Actions instead of Matchers for many reasons:
1) the name
2) the samples suggested that less reusability was not so bad
3) matchers cannot redirect
The things I would like to see deprecated in the sitemap are:
1) action/action-sets (flow + real blocks make them unnecessary)
2) resources (virtual components and the cocoon: protocol make them
unnecessary)
3) the ability to have generators/transformers/serializers inside
<pipeline> (only matchers/error-handler should be there) [this
shouldn't have been there in the first place!]
Before those who have invested a lot in actions jump on me, let me
guarantee you that I don't plan to propose this anytime soon.
But this is my opinion on the sitemap design.
--
Stefano.
sitemap design (was: Re: [Vote] empty HTTP responses)
Posted by Guido Casper <gc...@s-und-n.de>.
Stefano Mazzocchi wrote:
> On 7 Nov 2003, at 17:22, Guido Casper wrote:
>
>> Stefano Mazzocchi wrote:
>>> On 7 Nov 2003, at 13:52, Vadim Gritsenko wrote:
>>>
>>>> Stefano Mazzocchi wrote:
>>>>
>>>>>
>>>>> On Thursday, Nov 6, 2003, at 14:39 Europe/Rome, Vadim Gritsenko
>>>>> wrote:
>>>>>
>>>>>> I agree with comments in this other thread that let's not
>>>>>> introduce nested components in <map:call/>. Instead, if needed,
>>>>>> let's introduce <act type="flow"/>. Sometime later.
>>>>>
>>>>>
>>>>> -1
>>>>
>>>>
>>>> Your -1 means: "replace later with never", right? Just to remove
>>>> any possible point of confusion :)
>>>
>>> yes. I am against the silly
>>>
>>> <xxx>
>>> ... do something if true
>>> </xx>
>>> .. do something if false
>>>
>>> syntax. doesn't matter what the logic that drives the "xxx" tag is
>>> or what "xxx" is remapped to.
>>
>> Wow, that would rule out matchers as well.
>> But it might make some sense since matchers are not all that
>> different to
>> actions ;-)
>
> Careful. I'm against the use of
>
> <match src="something">
> </match>
> <read/>
>
> as well. The proper way should be
>
> <match src="something">
> ...
> </match>
>
> <match src="**">
> <reader/>
> </match>
>
> having the logic processing not following the element nesting, is,
> IMO, very confusing and very bad practice.
>
> In the original sitemap design, it was *NOT* possible to have pipeline
> components inside <pipeline>, only matchers. This is something that
> was introduced while I wasn't watching, just like actions.
>
> Yes, actions are not the only the only things I dislike about the
> sitemap: the tree processor introduced new ways of dealing with things
> (like having resources without generators or serializers, or pipeline
> components in pipelines without matchers)... but all these things
> ended up being more harm than good from a usage perspective.
>
> So, what's the point of introducing something and then come out with
> "best practices" that prevent you from using them?
Sorry if I added confusion.
Yes, "best practices" has always been hard to come up with for Cocoon. This
certainly has to do with the variety of usages users come up with. "Best
practices" tend to have a short life anyway.
I always wondered what the real difference between actions and matchers is
and (thanks to the power of expressive names) came to the conclusion that
it's the silent consensus to keep matchers side effect free while the side
effect of actions is their primary purpose.
You seem to be with Rickard Öberg's third principle for making software
frameworks:
"A framework's power comes not from what it allows, but from what it does
not allow"
However this comes just after:
"If you make a decision, be sure that it counts"
http://www.jroller.com/page/rickard/20030419
I somehow always had the feeling that Cocoon is different and its
unrestrictiveness (is this the right word?) attracts the creatives and it's
unforeseeable what they come up with. Cocoon is not just a framework for
building aplications. It's more of a framework for building frameworks. But
that's just my opinion.
Guido
sitemap design (was: Re: [Vote] empty HTTP responses)
Posted by Joerg Heinicke <jh...@virbus.de>.
On 07.11.2003 19:06, Stefano Mazzocchi wrote:
> Careful. I'm against the use of
>
> <match src="something">
> </match>
> <read/>
>
> as well. The proper way should be
>
> <match src="something">
> ...
> </match>
>
> <match src="**">
> <reader/>
> </match>
>
> having the logic processing not following the element nesting, is, IMO,
> very confusing and very bad practice.
>
> In the original sitemap design, it was *NOT* possible to have pipeline
> components inside <pipeline>, only matchers. This is something that was
> introduced while I wasn't watching, just like actions.
>
> Yes, actions are not the only the only things I dislike about the
> sitemap: the tree processor introduced new ways of dealing with things
> (like having resources without generators or serializers, or pipeline
> components in pipelines without matchers)... but all these things ended
> up being more harm than good from a usage perspective.
AFAIK it's not the tree processor's fault. Resources as pipeline parts
where possible as far as I can remember :-) But with the compiled
sitemap engine they must either call another resource or end with a
serializer. Now (with the tree processor) the pipeline flow falls back
to the calling pipeline, what allows e.g. transformer only resources.
Joerg
Re: [Vote] empty HTTP responses [was Re: Cannot easily set http status]
Posted by Stefano Mazzocchi <st...@apache.org>.
On 7 Nov 2003, at 17:22, Guido Casper wrote:
> Stefano Mazzocchi wrote:
>> On 7 Nov 2003, at 13:52, Vadim Gritsenko wrote:
>>
>>> Stefano Mazzocchi wrote:
>>>
>>>>
>>>> On Thursday, Nov 6, 2003, at 14:39 Europe/Rome, Vadim Gritsenko
>>>> wrote:
>>>>
>>>>> I agree with comments in this other thread that let's not introduce
>>>>> nested components in <map:call/>. Instead, if needed, let's
>>>>> introduce <act type="flow"/>. Sometime later.
>>>>
>>>>
>>>> -1
>>>
>>>
>>> Your -1 means: "replace later with never", right? Just to remove any
>>> possible point of confusion :)
>>
>> yes. I am against the silly
>>
>> <xxx>
>> ... do something if true
>> </xx>
>> .. do something if false
>>
>> syntax. doesn't matter what the logic that drives the "xxx" tag is or
>> what "xxx" is remapped to.
>
> Wow, that would rule out matchers as well.
> But it might make some sense since matchers are not all that different
> to
> actions ;-)
Careful. I'm against the use of
<match src="something">
</match>
<read/>
as well. The proper way should be
<match src="something">
...
</match>
<match src="**">
<reader/>
</match>
having the logic processing not following the element nesting, is, IMO,
very confusing and very bad practice.
In the original sitemap design, it was *NOT* possible to have pipeline
components inside <pipeline>, only matchers. This is something that was
introduced while I wasn't watching, just like actions.
Yes, actions are not the only the only things I dislike about the
sitemap: the tree processor introduced new ways of dealing with things
(like having resources without generators or serializers, or pipeline
components in pipelines without matchers)... but all these things ended
up being more harm than good from a usage perspective.
So, what's the point of introducing something and then come out with
"best practices" that prevent you from using them?
--
Stefano.
Re: [Vote] empty HTTP responses [was Re: Cannot easily set http status]
Posted by Guido Casper <gc...@s-und-n.de>.
Stefano Mazzocchi wrote:
> On 7 Nov 2003, at 13:52, Vadim Gritsenko wrote:
>
>> Stefano Mazzocchi wrote:
>>
>>>
>>> On Thursday, Nov 6, 2003, at 14:39 Europe/Rome, Vadim Gritsenko
>>> wrote:
>>>
>>>> I agree with comments in this other thread that let's not introduce
>>>> nested components in <map:call/>. Instead, if needed, let's
>>>> introduce <act type="flow"/>. Sometime later.
>>>
>>>
>>> -1
>>
>>
>> Your -1 means: "replace later with never", right? Just to remove any
>> possible point of confusion :)
>
> yes. I am against the silly
>
> <xxx>
> ... do something if true
> </xx>
> .. do something if false
>
> syntax. doesn't matter what the logic that drives the "xxx" tag is or
> what "xxx" is remapped to.
Wow, that would rule out matchers as well.
But it might make some sense since matchers are not all that different to
actions ;-)
Guido
Re: [Vote] empty HTTP responses [was Re: Cannot easily set http status]
Posted by Stefano Mazzocchi <st...@apache.org>.
On 7 Nov 2003, at 13:52, Vadim Gritsenko wrote:
> Stefano Mazzocchi wrote:
>
>>
>> On Thursday, Nov 6, 2003, at 14:39 Europe/Rome, Vadim Gritsenko wrote:
>>
>>> I agree with comments in this other thread that let's not introduce
>>> nested components in <map:call/>. Instead, if needed, let's
>>> introduce <act type="flow"/>. Sometime later.
>>
>>
>> -1
>
>
> Your -1 means: "replace later with never", right? Just to remove any
> possible point of confusion :)
yes. I am against the silly
<xxx>
... do something if true
</xx>
.. do something if false
syntax. doesn't matter what the logic that drives the "xxx" tag is or
what "xxx" is remapped to.
--
Stefano.
Re: [Vote] empty HTTP responses [was Re: Cannot easily set http status]
Posted by Vadim Gritsenko <va...@verizon.net>.
Stefano Mazzocchi wrote:
>
> On Thursday, Nov 6, 2003, at 14:39 Europe/Rome, Vadim Gritsenko wrote:
>
>> I agree with comments in this other thread that let's not introduce
>> nested components in <map:call/>. Instead, if needed, let's introduce
>> <act type="flow"/>. Sometime later.
>
>
> -1
Your -1 means: "replace later with never", right? Just to remove any
possible point of confusion :)
> I want to arrive to a point in the future where the ugly <act> element
> and silly usage can be thrown away without nobody whining.
We will get there.
Vadim
Re: [Vote] empty HTTP responses [was Re: Cannot easily set http status]
Posted by Stefano Mazzocchi <st...@apache.org>.
On Thursday, Nov 6, 2003, at 14:39 Europe/Rome, Vadim Gritsenko wrote:
> I agree with comments in this other thread that let's not introduce
> nested components in <map:call/>. Instead, if needed, let's introduce
> <act type="flow"/>. Sometime later.
-1
I want to arrive to a point in the future where the ugly <act> element
and silly usage can be thrown away without nobody whining.
Action -> flow migration paths exists today.
We don't need to reiterate past mistakes over and over.
--
Stefano.
Re: [Vote] empty HTTP responses [was Re: Cannot easily set http status]
Posted by Vadim Gritsenko <va...@verizon.net>.
Stefano Mazzocchi wrote:
>
> On Wednesday, Nov 5, 2003, at 13:41 Europe/Rome, Vadim Gritsenko wrote:
...
>> Before we vote: how to resolve "flow actions" issue then? There
>> should be migration path for users who already have wrote an actions
>> wtih flow.
>>
>> (remember? you've said that actions should be replaced with
>> flowscript ;-)
>
>
> You teaser ;-)
>
> IMVHO, an action is an overlap of three concerns:
>
> 1) processing logic external to the sitemap used to drive its flow
> 2) processing logic external to the pipelines used to drive its creation
> 3) processing logic used to update the external environment
>
> A potential migration strategy is:
>
> 1) should be done in the flow, either rewriting in javascript or
> refactoring the logic, moving it into an isolated component (either
> avalon or simple java class to instantiate from the flow)
>
> 3) this should be refactored into a class or component
>
> which leaves us with 2).
>
> I've seen far too many actions that set parameters that are later used
> by selectors. This is WRONG!!! You should be writing a selector!!!
>
> But at the very end, I think the issues at stake are orthogonal: Unico
> and I want a simple way to generate reponses with empty-payloads
> because this is going to be common for more complex uses of HTTP.
>
> You propose to clone the ugly action-like sitemap semantics with
> flowscript logic.
No, I don't. I'm just teasing ;-)
I'd like to see following:
1) If flow calls sendPage*(), sitemap execution terminates.
2) If flow calls sendStatus(), sitemap execution terminates.
3) If flow does none of the above, sitemap execution continues.
I think we have already consensus on (1) and (2). (3) is the current
behavior which can stay.
I agree with comments in this other thread that let's not introduce
nested components in <map:call/>. Instead, if needed, let's introduce
<act type="flow"/>. Sometime later.
Vadim
Re: [Vote] empty HTTP responses [was Re: Cannot easily set http status]
Posted by Stefano Mazzocchi <st...@apache.org>.
On Wednesday, Nov 5, 2003, at 13:41 Europe/Rome, Vadim Gritsenko wrote:
> Stefano Mazzocchi wrote:
>
>>
>> On Wednesday, Nov 5, 2003, at 12:19 Europe/Rome, Unico Hommes wrote:
>>
>>> setStatus' friends the sendError brothers are also be eligible for
>>> FOM
>>> membership. But this change has a dependency on the discussion about
>>> bodyless responses since if you'd do a sendError from a flow script
>>> and
>>> then send a page afterwards this would result in errors.
>>
>>
>> I dislikde "sendError" because, in fact, HTTP does not have the
>> concept of errors, but only status codes and empty-payload responses.
>>
>> In the future, it's entirely possible to have a 309 or equivalent
>> that is not an error, but has a empty-payload response. I would
>> dislike to call "sendError()" to send something that is not an error,
>> feels hacky.
>>
>> I think the optimal solution is:
>>
>> 1) add response.setStatus() in FOM
>> 2) allow the flowscript to terminate without calling sendPage* [thus
>> resulting in an empty payload]
>>
>> Vote?
>
>
> Before we vote: how to resolve "flow actions" issue then? There should
> be migration path for users who already have wrote an actions wtih
> flow.
>
> (remember? you've said that actions should be replaced with flowscript
> ;-)
You teaser ;-)
IMVHO, an action is an overlap of three concerns:
1) processing logic external to the sitemap used to drive its flow
2) processing logic external to the pipelines used to drive its
creation
3) processing logic used to update the external environment
A potential migration strategy is:
1) should be done in the flow, either rewriting in javascript or
refactoring the logic, moving it into an isolated component (either
avalon or simple java class to instantiate from the flow)
3) this should be refactored into a class or component
which leaves us with 2).
I've seen far too many actions that set parameters that are later used
by selectors. This is WRONG!!! You should be writing a selector!!!
But at the very end, I think the issues at stake are orthogonal: Unico
and I want a simple way to generate reponses with empty-payloads
because this is going to be common for more complex uses of HTTP.
You propose to clone the ugly action-like sitemap semantics with
flowscript logic.
The votes can happen independently.
> ]--
Stefano.
Re: [Vote] empty HTTP responses [was Re: Cannot easily set http status]
Posted by Vadim Gritsenko <va...@verizon.net>.
Stefano Mazzocchi wrote:
>
> On Wednesday, Nov 5, 2003, at 12:19 Europe/Rome, Unico Hommes wrote:
>
>> setStatus' friends the sendError brothers are also be eligible for FOM
>> membership. But this change has a dependency on the discussion about
>> bodyless responses since if you'd do a sendError from a flow script and
>> then send a page afterwards this would result in errors.
>
>
> I dislikde "sendError" because, in fact, HTTP does not have the
> concept of errors, but only status codes and empty-payload responses.
>
> In the future, it's entirely possible to have a 309 or equivalent that
> is not an error, but has a empty-payload response. I would dislike to
> call "sendError()" to send something that is not an error, feels hacky.
>
> I think the optimal solution is:
>
> 1) add response.setStatus() in FOM
> 2) allow the flowscript to terminate without calling sendPage* [thus
> resulting in an empty payload]
>
> Vote?
Before we vote: how to resolve "flow actions" issue then? There should
be migration path for users who already have wrote an actions wtih flow.
(remember? you've said that actions should be replaced with flowscript ;-)
Vadim
Re: [Vote] empty HTTP responses [was Re: Cannot easily set http status]
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Mercredi, 5 nov 2003, à 13:11 Europe/Zurich, Reinhard Poetz a écrit :
> ...I'm +1 with the idea to send pages without payload but -0 with
> flowscripts which terminate without calling sendPage*. I would prefer
> an
> explicit way....
Same here: flowscripts should not hide the fact that a response is
indeed sent.
-Bertrand
RE: [Vote] empty HTTP responses [was Re: Cannot easily set http status]
Posted by Reinhard Poetz <re...@apache.org>.
From: Stefano Mazzocchi
> On Wednesday, Nov 5, 2003, at 12:19 Europe/Rome, Unico Hommes wrote:
>
> > setStatus' friends the sendError brothers are also be
> eligible for FOM
> > membership. But this change has a dependency on the
> discussion about
> > bodyless responses since if you'd do a sendError from a flow script
> > and then send a page afterwards this would result in errors.
>
> I dislikde "sendError" because, in fact, HTTP does not have
> the concept
> of errors, but only status codes and empty-payload responses.
>
> In the future, it's entirely possible to have a 309 or
> equivalent that
> is not an error, but has a empty-payload response. I would dislike to
> call "sendError()" to send something that is not an error,
> feels hacky.
>
> I think the optimal solution is:
>
> 1) add response.setStatus() in FOM
> 2) allow the flowscript to terminate without calling
> sendPage* [thus
> resulting in an empty payload]
I'm +1 with the idea to send pages without payload but -0 with
flowscripts which terminate without calling sendPage*. I would prefer an
explicit way. I think this has advantages when you want to learn what a
script does and I have the feeling that an implicit sending of HTTP
headers can fool you if you have to debug your scripts.
--
Reinhard