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
