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.
