You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Andrew Robinson <an...@gmail.com> on 2008/05/15 03:40:57 UTC
A4J-like Trinidad components?
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.
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
Re: A4J-like Trinidad components?
Posted by Bruno Aranda <br...@gmail.com>.
+1 Hi, I am not sure about the namespace but I would like to see those
components included. I guess you mean something like a4j:support,
right? And I happen to have that need from time to time...
Cheers,
Bruno
2008/5/15 Andrew Robinson <an...@gmail.com>:
> 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.
>
> 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
>
Re: A4J-like Trinidad components?
Posted by Matthias Wessendorf <mw...@gmail.com>.
I am not that thrilled to treat ajax/ppr as a special case. Those
components would do that (IMO).
Sent from my iPod.
Am 15.05.2008 um 23:02 schrieb "Andrew Robinson" <andrew.rw.robinson@gmail.com
>:
> 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
> <bl...@oracle.com> 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
>>> <bl...@oracle.com> 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
>>>>> <bl...@oracle.com> 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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
Re: A4J-like Trinidad components?
Posted by Andrew Robinson <an...@gmail.com>.
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
<bl...@oracle.com> 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 <an...@...> 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
> <bl...@oracle.com> 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
> <bl...@oracle.com> 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
> <bl...@oracle.com> 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
>
>
>
>
>
>
>
>
>
>
Re: A4J-like Trinidad components?
Posted by Blake Sullivan <bl...@oracle.com>.
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 <andrew.rw.robinson@...
<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
> <bl...@oracle.com> 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
>>> <bl...@oracle.com> 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
>>>>> <bl...@oracle.com> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>
Re: A4J-like Trinidad components?
Posted by Andrew Robinson <an...@gmail.com>.
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
<bl...@oracle.com> 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
>> <bl...@oracle.com> 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
>>>> <bl...@oracle.com> 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
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
Re: A4J-like Trinidad components?
Posted by Blake Sullivan <bl...@ORACLE.COM>.
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
> <bl...@oracle.com> 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
>>> <bl...@oracle.com> 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
>>>>>
>>>>>
>>>>
>>
Re: A4J-like Trinidad components?
Posted by Andrew Robinson <an...@gmail.com>.
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
<bl...@oracle.com> 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
>> <bl...@oracle.com> 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
>>>>
>>>
>>>
>
>
Re: A4J-like Trinidad components?
Posted by Blake Sullivan <bl...@oracle.com>.
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
> <bl...@oracle.com> 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
>>>
>>
Re: A4J-like Trinidad components?
Posted by Andrew Robinson <an...@gmail.com>.
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
<bl...@oracle.com> 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
>
>
Re: A4J-like Trinidad components?
Posted by Blake Sullivan <bl...@oracle.com>.
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