I would like to get back on track to the original subject and not let the messaging subject hijack the thread.
Original topic: Is there enough interest from the developer community in supporting non-HTML PPR based components oriented for making PPR more declarative and extend PPR support for non-Trinidad components. I can write such components, but to be any use to the community there needs to be more than one developer supporting such a set of components so that the are adequately maintained. @Blake - feel free to start a new thread on TRINIDAD-697 if you wish or if you feel so inclined, provide a patch for the framework fix. Thanks, Andrew On Thu, May 15, 2008 at 2:52 PM, Blake Sullivan <[EMAIL PROTECTED]> wrote: > Andrew Robinson said the following On 5/15/2008 12:08 PM PT: >> >> 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. >> > > Are you saying that Adam's proposal does completely solve the issue raised > in > > but you have further goals mentioned in Trinidad-663 and Trinidad-664 or not > mentioned in any Jira that you would also like to address. However, even if > Adam's proposal doesn't address all of your issues, it sounds like we would > want to use it to solve Trinidad-697 because it can solve this case without > any page hacking on the part of the page author. > > -- Blake Sullivan > >> 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 >>>>>> >>>>>> >>>>> >>>>> >>> >>> > >
