Re: [fw-general] FlashMessenger Patch - Completion of the API
I think I'd argue for keeping this stuff in the session, but maybe providing a way to specify different session back-ends, or maybe for specifying a different back-end for different namespaces. I also wonder how the hasMessages() and similar state reporting methods should work with multiple namespaces in FlashMessenger - should they also take an optional argument? Matthew Weier O'Phinney-3 wrote: -- Eric Coleman [EMAIL PROTECTED] wrote (on Monday, 16 July 2007, 12:52 PM -0400): way to rain on my parade I think the issue is valid; the question is how to approach it. Ralph brings up a good argument: some of the use cases indicate that a more generic, intra-action messaging system should probably be created (non-session based, used when _forward()ing between actions). However, if this is done, it would be better not to have two separate helpers, but one helper with multiple backends (one session based, one in-memory). As such, it's a very different thing that simply adding a flag to the flashmessenger. On 7/16/07, Matthew Weier O'Phinney [EMAIL PROTECTED] wrote: -- townxelliot [EMAIL PROTECTED] wrote (on Monday, 16 July 2007, 09:03 AM -0700): I'm not sure how FlashMessenger is supposed to work, as there are several places where a $namespace option is supposed to be accepted by a function, but it's not part of the parameters. Also, adding namespaces adds complexity when using hasMessages(), count() etc., which currently only return values for the current namespace, not all namespaces. I wondered whether anyone can point me at the definitive design document or similar for this, so I can get an idea of how it's intended to work. I would like to be able to use namespaces, so it would be useful to know whether the API is going to cope with those or not. A number of developers -- including Eric, whom you quote below, and myself -- have voiced frustration over how the FlashMessenger currently works in regards to namespaces. I've created a JIRA issue requesting that each of the various *Messages() methods take an optional $namespace parameter; this would simplify using the FlashMessenger in most cases as there would be no setup required to use alternate namespaces (other than the default namespace). The issue can be found at: http://framework.zend.com/issues/browse/ZF-1705 This will only deal with namespace usage, not with clearing a namespace after retrieval; that will be addressed separately. Eric Coleman-3 wrote: I believe the API is incomplete as I mentioned in a previous email. I spent a tiny bit of time testing this and I think the small changes are enough.. What I did - added getNamespace() - returns current namespace - implemented direct method as direct($message, $namespace = 'default') this was mentioned in the manual but seems to have been missing - changed getCurrentMessages() to getCurrentMessages($clear = false) if you want to clear out the namespace after retrieval, change it to true -- Matthew Weier O'Phinney PHP Developer| [EMAIL PROTECTED] Zend - The PHP Company | http://www.zend.com/ -- Matthew Weier O'Phinney PHP Developer| [EMAIL PROTECTED] Zend - The PHP Company | http://www.zend.com/ -- View this message in context: http://www.nabble.com/FlashMessenger-Patch---Completion-of-the-API-tf3898116s16154.html#a11650730 Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] FlashMessenger Patch - Completion of the API
-- townxelliot [EMAIL PROTECTED] wrote (on Tuesday, 17 July 2007, 08:11 AM -0700): I think I'd argue for keeping this stuff in the session, but maybe providing a way to specify different session back-ends, or maybe for specifying a different back-end for different namespaces. That's a debate for another day. If you're interested and willing, please create a new proposal indicating exactly what you'd like to see so we can evaluate and determine how to proceed. I also wonder how the hasMessages() and similar state reporting methods should work with multiple namespaces in FlashMessenger - should they also take an optional argument? Yes, and that's on the issue that has been reported on JIRA. Each of the following will have an optional additional argument for the namespace: addMessage() hasMessages() getMessages() clearMessages() hasCurrentMessages() getCurrentMessages() This will either happen for 1.0.1 or the following release. Matthew Weier O'Phinney-3 wrote: -- Eric Coleman [EMAIL PROTECTED] wrote (on Monday, 16 July 2007, 12:52 PM -0400): way to rain on my parade I think the issue is valid; the question is how to approach it. Ralph brings up a good argument: some of the use cases indicate that a more generic, intra-action messaging system should probably be created (non-session based, used when _forward()ing between actions). However, if this is done, it would be better not to have two separate helpers, but one helper with multiple backends (one session based, one in-memory). As such, it's a very different thing that simply adding a flag to the flashmessenger. On 7/16/07, Matthew Weier O'Phinney [EMAIL PROTECTED] wrote: -- townxelliot [EMAIL PROTECTED] wrote (on Monday, 16 July 2007, 09:03 AM -0700): I'm not sure how FlashMessenger is supposed to work, as there are several places where a $namespace option is supposed to be accepted by a function, but it's not part of the parameters. Also, adding namespaces adds complexity when using hasMessages(), count() etc., which currently only return values for the current namespace, not all namespaces. I wondered whether anyone can point me at the definitive design document or similar for this, so I can get an idea of how it's intended to work. I would like to be able to use namespaces, so it would be useful to know whether the API is going to cope with those or not. A number of developers -- including Eric, whom you quote below, and myself -- have voiced frustration over how the FlashMessenger currently works in regards to namespaces. I've created a JIRA issue requesting that each of the various *Messages() methods take an optional $namespace parameter; this would simplify using the FlashMessenger in most cases as there would be no setup required to use alternate namespaces (other than the default namespace). The issue can be found at: http://framework.zend.com/issues/browse/ZF-1705 This will only deal with namespace usage, not with clearing a namespace after retrieval; that will be addressed separately. Eric Coleman-3 wrote: I believe the API is incomplete as I mentioned in a previous email. I spent a tiny bit of time testing this and I think the small changes are enough.. What I did - added getNamespace() - returns current namespace - implemented direct method as direct($message, $namespace = 'default') this was mentioned in the manual but seems to have been missing - changed getCurrentMessages() to getCurrentMessages($clear = false) if you want to clear out the namespace after retrieval, change it to true -- Matthew Weier O'Phinney PHP Developer| [EMAIL PROTECTED] Zend - The PHP Company | http://www.zend.com/ -- Matthew Weier O'Phinney PHP Developer| [EMAIL PROTECTED] Zend - The PHP Company | http://www.zend.com/ -- View this message in context: http://www.nabble.com/FlashMessenger-Patch---Completion-of-the-API-tf3898116s16154.html#a11650730 Sent from the Zend Framework mailing list archive at Nabble.com. -- Matthew Weier O'Phinney PHP Developer| [EMAIL PROTECTED] Zend - The PHP Company | http://www.zend.com/
Re: [fw-general] FlashMessenger Patch - Completion of the API
I'm not sure how FlashMessenger is supposed to work, as there are several places where a $namespace option is supposed to be accepted by a function, but it's not part of the parameters. Also, adding namespaces adds complexity when using hasMessages(), count() etc., which currently only return values for the current namespace, not all namespaces. I wondered whether anyone can point me at the definitive design document or similar for this, so I can get an idea of how it's intended to work. I would like to be able to use namespaces, so it would be useful to know whether the API is going to cope with those or not. Elliot Eric Coleman-3 wrote: I believe the API is incomplete as I mentioned in a previous email. I spent a tiny bit of time testing this and I think the small changes are enough.. What I did - added getNamespace() - returns current namespace - implemented direct method as direct($message, $namespace = 'default') this was mentioned in the manual but seems to have been missing - changed getCurrentMessages() to getCurrentMessages($clear = false) if you want to clear out the namespace after retrieval, change it to true Regards, Eric -- View this message in context: http://www.nabble.com/FlashMessenger-Patch---Completion-of-the-API-tf3898116s16154.html#a11620967 Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] FlashMessenger Patch - Completion of the API
-- townxelliot [EMAIL PROTECTED] wrote (on Monday, 16 July 2007, 09:03 AM -0700): I'm not sure how FlashMessenger is supposed to work, as there are several places where a $namespace option is supposed to be accepted by a function, but it's not part of the parameters. Also, adding namespaces adds complexity when using hasMessages(), count() etc., which currently only return values for the current namespace, not all namespaces. I wondered whether anyone can point me at the definitive design document or similar for this, so I can get an idea of how it's intended to work. I would like to be able to use namespaces, so it would be useful to know whether the API is going to cope with those or not. A number of developers -- including Eric, whom you quote below, and myself -- have voiced frustration over how the FlashMessenger currently works in regards to namespaces. I've created a JIRA issue requesting that each of the various *Messages() methods take an optional $namespace parameter; this would simplify using the FlashMessenger in most cases as there would be no setup required to use alternate namespaces (other than the default namespace). The issue can be found at: http://framework.zend.com/issues/browse/ZF-1705 This will only deal with namespace usage, not with clearing a namespace after retrieval; that will be addressed separately. Eric Coleman-3 wrote: I believe the API is incomplete as I mentioned in a previous email. I spent a tiny bit of time testing this and I think the small changes are enough.. What I did - added getNamespace() - returns current namespace - implemented direct method as direct($message, $namespace = 'default') this was mentioned in the manual but seems to have been missing - changed getCurrentMessages() to getCurrentMessages($clear = false) if you want to clear out the namespace after retrieval, change it to true -- Matthew Weier O'Phinney PHP Developer| [EMAIL PROTECTED] Zend - The PHP Company | http://www.zend.com/
Re: [fw-general] FlashMessenger Patch - Completion of the API
way to rain on my parade On 7/16/07, Matthew Weier O'Phinney [EMAIL PROTECTED] wrote: -- townxelliot [EMAIL PROTECTED] wrote (on Monday, 16 July 2007, 09:03 AM -0700): I'm not sure how FlashMessenger is supposed to work, as there are several places where a $namespace option is supposed to be accepted by a function, but it's not part of the parameters. Also, adding namespaces adds complexity when using hasMessages(), count() etc., which currently only return values for the current namespace, not all namespaces. I wondered whether anyone can point me at the definitive design document or similar for this, so I can get an idea of how it's intended to work. I would like to be able to use namespaces, so it would be useful to know whether the API is going to cope with those or not. A number of developers -- including Eric, whom you quote below, and myself -- have voiced frustration over how the FlashMessenger currently works in regards to namespaces. I've created a JIRA issue requesting that each of the various *Messages() methods take an optional $namespace parameter; this would simplify using the FlashMessenger in most cases as there would be no setup required to use alternate namespaces (other than the default namespace). The issue can be found at: http://framework.zend.com/issues/browse/ZF-1705 This will only deal with namespace usage, not with clearing a namespace after retrieval; that will be addressed separately. Eric Coleman-3 wrote: I believe the API is incomplete as I mentioned in a previous email. I spent a tiny bit of time testing this and I think the small changes are enough.. What I did - added getNamespace() - returns current namespace - implemented direct method as direct($message, $namespace = 'default') this was mentioned in the manual but seems to have been missing - changed getCurrentMessages() to getCurrentMessages($clear = false) if you want to clear out the namespace after retrieval, change it to true -- Matthew Weier O'Phinney PHP Developer| [EMAIL PROTECTED] Zend - The PHP Company | http://www.zend.com/
Re: [fw-general] FlashMessenger Patch - Completion of the API
-- Eric Coleman [EMAIL PROTECTED] wrote (on Monday, 16 July 2007, 12:52 PM -0400): way to rain on my parade I think the issue is valid; the question is how to approach it. Ralph brings up a good argument: some of the use cases indicate that a more generic, intra-action messaging system should probably be created (non-session based, used when _forward()ing between actions). However, if this is done, it would be better not to have two separate helpers, but one helper with multiple backends (one session based, one in-memory). As such, it's a very different thing that simply adding a flag to the flashmessenger. On 7/16/07, Matthew Weier O'Phinney [EMAIL PROTECTED] wrote: -- townxelliot [EMAIL PROTECTED] wrote (on Monday, 16 July 2007, 09:03 AM -0700): I'm not sure how FlashMessenger is supposed to work, as there are several places where a $namespace option is supposed to be accepted by a function, but it's not part of the parameters. Also, adding namespaces adds complexity when using hasMessages(), count() etc., which currently only return values for the current namespace, not all namespaces. I wondered whether anyone can point me at the definitive design document or similar for this, so I can get an idea of how it's intended to work. I would like to be able to use namespaces, so it would be useful to know whether the API is going to cope with those or not. A number of developers -- including Eric, whom you quote below, and myself -- have voiced frustration over how the FlashMessenger currently works in regards to namespaces. I've created a JIRA issue requesting that each of the various *Messages() methods take an optional $namespace parameter; this would simplify using the FlashMessenger in most cases as there would be no setup required to use alternate namespaces (other than the default namespace). The issue can be found at: http://framework.zend.com/issues/browse/ZF-1705 This will only deal with namespace usage, not with clearing a namespace after retrieval; that will be addressed separately. Eric Coleman-3 wrote: I believe the API is incomplete as I mentioned in a previous email. I spent a tiny bit of time testing this and I think the small changes are enough.. What I did - added getNamespace() - returns current namespace - implemented direct method as direct($message, $namespace = 'default') this was mentioned in the manual but seems to have been missing - changed getCurrentMessages() to getCurrentMessages($clear = false) if you want to clear out the namespace after retrieval, change it to true -- Matthew Weier O'Phinney PHP Developer| [EMAIL PROTECTED] Zend - The PHP Company | http://www.zend.com/ -- Matthew Weier O'Phinney PHP Developer| [EMAIL PROTECTED] Zend - The PHP Company | http://www.zend.com/
