I think that there are some good things to think about and talk about here. I just don't have time at the moment to really dive into this. Just wanted to respond so as not to look like I am ignoring the response.
-A On Fri, May 16, 2008 at 11:08 AM, Blake Sullivan <[EMAIL PROTECTED]> wrote: > OK, looking at the rest of the JIRA issues: > > https://issues.apache.org/jira/browse/TRINIDAD-664 > > Is a request for a component to add partial trigger functionality to > non-Trinidad components. The supplied code is uncommented, so some of the > proposed functionality is unclear, however this raises the general issue of > whether there is additional Trinidad functionality that we would like to add > to an adapter component. On the implementation side, now that we have > FlattenedComponents, all behavior-only components should be implemented as > flattened components. > > https://issues.apache.org/jira/browse/TRINIDAD-663 > > As noted in the JIRA, this is actually three different issues: > > It is not currently possible out of the box to control when in the JSF > lifecycle a Trinidad component triggers its partial notification outside of > actually changing the phase ID of the events, which is not always possible. > > Also, it is very difficult to have a component listen to many components. > For example, someone may want to say, re-render component x when any child > of y is triggered. > > There is also no functionality for a push type of PPR. Meaning that right > now components specify that they want to be triggered, but there is no way > to say for a component to target other components (for example, specify on a > button to re-render a text box, instead of specifying on a text-box to > re-render on that button). > > Of these, Adam clearly doubted whether the first was necessary or desirable: > > On 8/28/07, Andrew Robinson <[EMAIL PROTECTED]> wrote: >> I got it to work with a custom component. I created a component that >> doesn't render, that simply houses children. In the queueEvent method >> of that component, if the type of the event is ActionEvent, I then use >> it to add components as partial targets. >> >> It just would be nice to have this supported by Trinidad out of the >> box. A4J creates AjaxEvents that have their phase ID set to ANY, so >> they fire almost immediately, and thus work regardless of what phases >> are run. >> >> I'm just wondering if there would be any harm to moving the code from >> the broadcast method to the queue method. > « [hide part of quote] > Yes, there would be! It'd break the semantics of partialTriggers. > > If you want your action event to fire in the "ANY" phase, just set > immediate="true". > > -- Adam > > The second of these--PPRing a container when children fire a PPR-triggering > event, is interesting but one of those cases where it would be nice to > collect up the possible use cases (is it any descendant or only children, > would we need additional filtering controls--for example by type of > component or type of triggering event, etc.) but the bigger issue is that if > we were to add this functionality to Trinidad itself, wouldn't it be more > natural to do so by adding a real partial trigger object and then allowing > page authors who need a more specialized trigger to use an > <af:partialTrigger> tag to add it declaratively (if we do need the > functionality from the first item, this behavior could also be specified on > the PartialTrigger object) > > The third of these, adding support for partialTargets in addition to > partialTriggers is interesting. When I originally implemented PPR for UIX, > the forerunner of ADF Faces and Trindad, the components had a partialTargets > attribute that specified the components to PPR when the component in > question fired an event. I did this because: > 1) It mapped directly to the implementation, which only cares about which > components need to be PPRed on a particular request > 2) I just didn't think to hard about the fact that I had done things > backwards and that partialTriggers was the right way to do this if we were > only going to have one way, so it was a good thing Adam changed this when he > converted the UIX code to the ADF Faces code. > > Anyway, if we really do need to declaratively support both schemes, the main > question is what is the best way of exposing the functionality. We have a > continuum of page author convenience and discoverability that looks like > this: > > 1) Collection attribute on component exposed as an attribute on the > component tag (partialTargets="foo bar") > 2) Collection attribute on component exposed as an attribute tag > (<af:partialTarget target="foo"/><af:partialTarget target="bar"/>) > 3) Declarative event listener on component (<af:partialTarget targets="foo > bar"/>)(The tricky part here is that components don't fire a PPR event to > listen to) > 4) Wrapper component > > I think that 3) is actually the most architecturally pleasing, but requires > the most change to the component and PPR infrastructure (though not in any > interesting way). 1) and 2) are closest to how partialTriggers are > exposed. 4) requires the least work from the rest of the system, but is the > most different. Which of these we prefer, if we want to go here at all > right now, also depends on how often we think page authors would use this > feature. > > -- Blake Sullivan > > Andrew Robinson said the following On 5/15/2008 2:02 PM PT: > > 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 > > > > > > > > > >
