Hey Joey,
I just realised that I had submitted patches for panelradio and panelChoice
which had dependencies on other issues being commited. I cancelled those
patches after I read Jeanne's and your e-mails.
Thanks,
Piyush
- Original Message -
From: Joseph Rozier [EMAIL PROTECTED]
Does anyone mind if I make the following method in
UIXComponentBase protected?
It is a method that component extensions (and components in other packages)
would find very useful.
It is used to deliver a faces event to a method binding listener, as in the
following:
tr:commandButton
Anyone saw this?
-Matthias
--
Matthias Wessendorf
http://tinyurl.com/fmywh
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
+1, though maybe with a different name?
-- Adam
On 9/22/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote:
Does anyone mind if I make the following method in
UIXComponentBase protected?
It is a method that component extensions (and components in other
packages)
would find very useful.
It is used
protected void callMethodBinding(FacesEvent, MethodBinding) throws
AbortProcessingException
?
other names: executeMethodBinding, invokeMethodBinding, invokeMethod
I think I prefer invokeMethodBinding.
On 9/22/06, Adam Winer [EMAIL PROTECTED] wrote:
+1, though maybe with a different name?
--
Hrm, but it's event-specific (takes a FacesEvent, deals
with AbortProcessingException) so something like
broadcastToMethodBinding() works for me.
-- Adam
On 9/22/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote:
protected void callMethodBinding(FacesEvent, MethodBinding) throws
I've checked in the first big part of getting ready for public rendering
APIs.
The goal is to move APIs out of trinidad-impl and into trinidad-api, but
a number of the desired APIs pulled in a lot of code that really shouldn't
be made public. So, a bunch of refactoring was called for,
Trinidad has a LifecycleRenderer, which is an interface that can be
implemented by a Renderer to let the renderer take over handling
processDecodes(), processUpdates(), processValidators(). This
is a big improvement if you have a smart DHTML table that lets
you scroll around the whole content
Hi,
Thanks Mike. Here's some of the pros and cons of each, if you don't mind
let's stick to the detail string for now.
1] current Trinidad way: have specific attributes for each detail
PROS: usual case is that user binds each detail attr to a specific
bundle key, the message won't be out of
Adam Winer wrote:
Trinidad has a LifecycleRenderer, which is an interface that can be
implemented by a Renderer to let the renderer take over handling
processDecodes(), processUpdates(), processValidators(). This
is a big improvement if you have a smart DHTML table that lets
you scroll
http://issues.apache.org/jira/browse/ADFFACES-190
On 9/22/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote:
fine with me. I'll file a jira
On 9/22/06, Adam Winer [EMAIL PROTECTED] wrote:
Hrm, but it's event-specific (takes a FacesEvent, deals
with AbortProcessingException) so something like
+1
will help solve problems with trees,tables and other stamping components,
since now the same logic that
walks the tree on encode can do the same walk for decode,validate and
update.
--arjuna
On 9/22/06, Gabrielle Crawford [EMAIL PROTECTED] wrote:
Adam Winer wrote:
Trinidad has a
12 matches
Mail list logo
