Taking one use case and putting it at the framework level will not address all possible use cases. The desire to have something always rendered does not have to be limited to messages. Furthermore, this assumes that messages are always shown using the Trinidad framework, which is a bad assumption. For example, the Tomahawk message component is much better for customizability than the Trinidad one.
Adding a new components gives users the flexibility to choose the way they want to implement it and be able to work with non-Trinidad libraries. IMO this is a much better solution than a small enhancement for Trinidad messaging and JavaScript. -Andrew On Thu, May 15, 2008 at 12:24 PM, Blake Sullivan <[EMAIL PROTECTED]> wrote: > Why doesn't Adam's proposal: > > This all seems like enormous overkill *just* to get messages > sent down. We have Javascript that can insert messages > on the client. All we need to do is lean slightly on that code > to reuse it for inserting server-side messages, and this'll work fine > without any architectural changes at all. > > -- Adam > > Solve > > https://issues.apache.org/jira/browse/TRINIDAD-697 > > at the framework level? > > -- Blake Sullivan > > > Andrew Robinson said the following On 5/15/2008 11:03 AM PT: >> >> He mentioned ways to do it using backing beans and non-declarative >> ways. He also didn't like my "always render" functionality of one of >> the components. >> >> Here are the links for just the 2 components that I already did and >> bugs and discussions surrounding them (but I think there is room for >> more along these lines): >> >> https://issues.apache.org/jira/browse/TRINIDAD-697 >> https://issues.apache.org/jira/browse/TRINIDAD-663 >> https://issues.apache.org/jira/browse/TRINIDAD-664 >> >> >> https://svn.apache.org/repos/asf/myfaces/trinidad/branches/arobinson-ppr-components >> >> Related discussions: >> >> http://tinyurl.com/5vdb57 >> http://tinyurl.com/5mrm8k >> http://tinyurl.com/56zk8f >> >> -Andrew >> >> On Thu, May 15, 2008 at 11:25 AM, Blake Sullivan >> <[EMAIL PROTECTED]> wrote: >> >>> >>> Andrew Robinson said the following On 5/14/2008 6:40 PM PT: >>> >>>> >>>> In the past, I created 2 new components to make PPR easier from a >>>> declarative stand point. At the time, Adam Winer disagreed with their >>>> inclusion. Now, I wanted to see if there would be any objections to such >>>> components. >>>> >>> >>> Adam is pretty reasonable about these kinds of things. What were his >>> objections? >>> >>> -- Blake Sullivan >>> >>> >>>> >>>> I was thinking that that they would go in the sandbox first, then if >>>> they >>>> seem to be acceptible, move them into a new tag namespace (like tra: for >>>> AJAX or trp: for ppr). >>>> >>>> I won't be working on this right away probably as I am still working on >>>> the new demo when I have the time and energy, but I wanted to get a feel >>>> for >>>> what people think. >>>> >>>> An example component is one that can trigger a PPR re-rendering if any >>>> children components either (1) queue an event (immedate) or (2) >>>> broadcast an >>>> event. >>>> >>>> -Andrew >>>> >>>> Sent from my iPod >>>> >>> >>> > >
