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]
<http://www.nabble.com/user/SendEmail.jtp?type=post&post=12378593&i=0>>
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
<http://www.nabble.com/-Trinidad--ppr:-partialTriggers-doesn%27t-work-if-there-are-validation-messages--td12357146.html#>]
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
