11:40 p.m.
>>>> On Fri, 07 Aug 2009 08:31:51 +0200, Martin Marinschek
<mmarinschek(a)apache.org> said:
MM> Hi Lincoln,
> Unless I'm mistaken, ui:repeat is not a component and
therefore cannot
> be bound to a backing bean,
MM> I thought it was - and just checked, it derives from UIComponentBase.
MM> Does the binding attribute not work for you?
Yes, but it's implementation specific and not in the
javax.faces.component package.
LB> **Question 1: Almost every AJAX framework I know of allows you to simply
LB> execute a method on the server side, with or without params, and return
LB> a result... is this possible with JSF's Ajax framework?
Such DWR style functionality was in DynamicFaces, but didn't make it
into the JSF standard Ajax.
>>>> On Thu, 13 Aug 2009 00:10:59 +0100, Pete Muir
<pmuir(a)redhat.com> said:
PM> IMO this is not an uncommon use case, and we should support via (1)
Can you please be more specific, Pete? Which part of LB's mail is not
an uncommon case? What is (1)?
>>>> On Thu, 13 Aug 2009 00:26:14 +0200, Martin Marinschek
<mmarinschek(a)apache.org> said:
MM> Hi Dan,
MM> I did a little research, and it won't work. Therefore I just sent a
MM> mail out to the JSR-245 spec lead asking for the following signature
MM> in the EL-resolver - that might help at least a little in providing
MM> such functionality. And I thought we had discussed that this should
MM> work at some point of time.
MM> public Object invoke(ELContext context,
MM> Object base,
MM> Object method,
MM> Class[] formalParamTypes,
MM> Object[] formalParams,
MM> Class[] parsedParamTypes,
MM> Object[] parsedParams
MM> ) {
MM> ...
MM> }
>>>> On Thu, 13 Aug 2009 01:45:45 +0200, Martin Marinschek
<mmarinschek(a)apache.org> said:
MM> 1) add a method-attribute to the f:valueChangeListener-tag
You mean, have an attribute that means, "The value of this attribute
must be a MethodExpression that points to a method that conforms to the
signature of ValueChangeListener.processValueChange()"? If so, then yes
I agree, and we should add it for all the attached objects where it
makes sense.
MM> 2) get Unified-EL to also support passing the formal parameters (see
MM> my mail to the spec lead)
Which I still don't understand. Can you please explain explicitly?
Thanks,
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
11:45 p.m.
New subject: [jsr-314-open] <h:dataTable> binding vs. ui:repeat
On 17 Aug 2009, at 22:40, Ed Burns wrote:
>>>>> On Fri, 07 Aug 2009 08:31:51 +0200, Martin
Marinschek <mmarinschek(a)apache.org
>>>>> > said:
MM> Hi Lincoln,
>> Unless I'm mistaken, ui:repeat is not a component and therefore
>> cannot
>> be bound to a backing bean,
MM> I thought it was - and just checked, it derives from
UIComponentBase.
MM> Does the binding attribute not work for you?
Yes, but it's implementation specific and not in the
javax.faces.component package.
LB> **Question 1: Almost every AJAX framework I know of allows you
to simply
LB> execute a method on the server side, with or without params, and
return
LB> a result... is this possible with JSF's Ajax framework?
Such DWR style functionality was in DynamicFaces, but didn't make it
into the JSF standard Ajax.
>>>>> On Thu, 13 Aug 2009 00:10:59 +0100, Pete Muir
>>>>> <pmuir(a)redhat.com> said:
PM> IMO this is not an uncommon use case, and we should support via
(1)
Can you please be more specific, Pete? Which part of LB's mail is not
an uncommon case? What is (1)?
I meant, we should provide direct support of the (rough) functionality
that Lincoln described in saying how others solve Q1.
>>>>> On Thu, 13 Aug 2009 00:26:14 +0200, Martin Marinschek
<mmarinschek(a)apache.org
>>>>> > said:
MM> Hi Dan,
MM> I did a little research, and it won't work. Therefore I just
sent a
MM> mail out to the JSR-245 spec lead asking for the following
signature
MM> in the EL-resolver - that might help at least a little in
providing
MM> such functionality. And I thought we had discussed that this
should
MM> work at some point of time.
MM> public Object invoke(ELContext context,
MM> Object base,
MM> Object method,
MM> Class[] formalParamTypes,
MM> Object[] formalParams,
MM> Class[] parsedParamTypes,
MM> Object[] parsedParams
MM> ) {
MM> ...
MM> }
>>>>> On Thu, 13 Aug 2009 01:45:45 +0200, Martin Marinschek
<mmarinschek(a)apache.org
>>>>> > said:
MM> 1) add a method-attribute to the f:valueChangeListener-tag
You mean, have an attribute that means, "The value of this attribute
must be a MethodExpression that points to a method that conforms to
the
signature of ValueChangeListener.processValueChange()"? If so, then
yes
I agree, and we should add it for all the attached objects where it
makes sense.
MM> 2) get Unified-EL to also support passing the formal parameters
(see
MM> my mail to the spec lead)
Which I still don't understand. Can you please explain explicitly?
Thanks,
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
11:15 p.m.
New subject: [jsr-314-open] <h:dataTable> binding vs. ui:repeat
On Mon, 2009-08-17 at 22:45 +0100, Pete Muir wrote:
I meant, we should provide direct support of the (rough)
functionality
that Lincoln described in saying how others solve Q1.
I've opened Issue 613 to track this..
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=613
8:08 a.m.
New subject: [jsr-314-open] <h:dataTable> binding vs. ui:repeat
Hi Ed,
Which I still don't understand. Can you please explain
explicitly?
I sent a mail to Kin-Man that we can't pass parameters from the
framework to the method-expression. So, we can now do:
#{bb.action(myparam)}
to call a method with signature:
public String action(String myparam) {}
but we can not do:
#{bb.valueChangeListener(myparam)}
to call a method with signature:
public void valueChangeListener(ValueChangeEvent ev, String myparam) {}
only with signature:
public void valueChangeListener(String myparam) {}
so what we loose is the ValueChangeEvent, which was provided by the
JSF framework as a parameter to the invoke-call in the
Method-Expression instance (we will only receive the parsed
parameters).
I already got mail by Kin-Man - he said this won't be included, we are too late.
This effectively means we cannot use the new EL functionality to solve
the problem that was discussed in this thread (using
valueChangeListeners in a dataTable), and therefore, even though we
can get rid of the f:setPropertyActionListener, we would still need an
f:setPropertyValueChangeListener - a pity.
regards,
Martin
12:16 a.m.
New subject: [jsr-314-open] <h:dataTable> binding vs. ui:repeat
I sent a mail to Kin-Man that we can't pass parameters from the
framework to the method-expression. So, we can now do:
#{bb.action(myparam)}
to call a method with signature:
public String action(String myparam) {}
but we can not do:
#{bb.valueChangeListener(myparam)}
to call a method with signature:
public void valueChangeListener(ValueChangeEvent ev, String myparam) {}
only with signature:
public void valueChangeListener(String myparam) {}
so what we loose is the ValueChangeEvent, which was provided by the
JSF framework as a parameter to the invoke-call in the
Method-Expression instance (we will only receive the parsed
parameters).
Beautifully stated.
I already got mail by Kin-Man - he said this won't be included, we are too
late.
I don't get it. Why are JSR-299 and JSR-330 allowed to change so drastically
before Java EE 6, yet we need one small change in EL and it can't happen.
This is crap. If we all agree this change would be valuable, I want to see
it included. Whose arm do we have to twist?
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
7:24 p.m.
New subject: [jsr-314-open] <h:dataTable> binding vs. ui:repeat
On Fri, 2009-08-28 at 18:16 -0400, Dan Allen wrote:
I don't get it. Why are JSR-299 and JSR-330 allowed to change so
drastically before Java EE 6, yet we need one small change in EL and
it can't happen. This is crap. If we all agree this change would be
valuable, I want to see it included. Whose arm do we have to twist?
For now, I'd still like to see the <f:valueChangeListener
method="...">
and <f:actionListener method="..."> attributes provided, even if the
ValueChangeEvent and ActionEvent parameters are lost. This functionality
is important to provide even at a basic level, in my opinion. This would
put the listener functionality in a more consistent place with the
action method functionality on commandLink and commandButton.
The full functionality can be addressed at a later date when it becomes
possible through EL.
The issue is:
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=612
--Lincoln
9:44 p.m.
New subject: [jsr-314-open] <h:dataTable> binding vs. ui:repeat
Should the attribute be named "action" to be consistent with UICommand
components? (<h:commandButton>). Otherwise, +1
-Dan
On Sun, Aug 30, 2009 at 1:24 PM, Lincoln Baxter, III <
lincolnbaxter(a)gmail.com> wrote:
On Fri, 2009-08-28 at 18:16 -0400, Dan Allen wrote:
I don't get it. Why are JSR-299 and JSR-330 allowed to change so
drastically before Java EE 6, yet we need one small change in EL and it
can't happen. This is crap. If we all agree this change would be valuable, I
want to see it included. Whose arm do we have to twist?
For now, I'd still like to see the <f:valueChangeListener
method="..."> and
<f:actionListener method="..."> attributes provided, even if the
ValueChangeEvent and ActionEvent parameters are lost. This functionality is
important to provide even at a basic level, in my opinion. This would put
the listener functionality in a more consistent place with the action method
functionality on commandLink and commandButton.
The full functionality can be addressed at a later date when it becomes
possible through EL.
The issue is:
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=612
--Lincoln
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
7:26 p.m.
New subject: [jsr-314-open] <h:dataTable> binding vs. ui:repeat
Re: the method="" attributes.
I'd like to try implementing this - I've never checked out or made
changes to the mojarra codebase before. Could someone give me a few
steps to get started? Thanks.
9:42 p.m.
New subject: [jsr-314-open] <h:dataTable> binding vs. ui:repeat
On Sun, Aug 30, 2009 at 1:26 PM, Lincoln Baxter, III <
lincolnbaxter(a)gmail.com> wrote:
Re: the method="" attributes.
I'd like to try implementing this - I've never checked out or made changes
to the mojarra codebase before. Could someone give me a few steps to get
started? Thanks.
It's pretty straightforward. Read these questions to get started:
http://wiki.glassfish.java.net/Wiki.jsp?page=JavaServerFacesRI#section-Ja...
The project builds with Ant and/or imports into NetBeans without any
trouble. It may also import into Eclipse. I can't remember if I had to make
any changes since it has been a long time since I did it.
If there is anything missing from the instructions, please let one of the
Mojarra developers know.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
8:46 p.m.
New subject: [jsr-314-open] <h:dataTable> binding vs. ui:repeat
Finally read through this thread. Fun stuff. :-)
Martin Marinschek wrote:
Hi Ed,
> Which I still don't understand. Can you please explain explicitly?
>
I sent a mail to Kin-Man that we can't pass parameters from the
framework to the method-expression. So, we can now do:
#{bb.action(myparam)}
to call a method with signature:
public String action(String myparam) {}
but we can not do:
#{bb.valueChangeListener(myparam)}
to call a method with signature:
public void valueChangeListener(ValueChangeEvent ev, String myparam) {}
only with signature:
public void valueChangeListener(String myparam) {}
so what we loose is the ValueChangeEvent, which was provided by the
JSF framework as a parameter to the invoke-call in the
Method-Expression instance (we will only receive the parsed
parameters).
An alternative that I believe we could implement in the JSF layer
without any changes to the EL spec would be to provdie access to an
implicit "event" object during event delivery. The page author would
specify:
#{bb.valueChangeListener(event, myparam)}
Where bb.valueChangeListener is bound to:
public void valueChangeListener(ValueChangeEvent ev, String myparam)
{}
And the "event" implicit object is set up by JSF to point to the
ValueChangeEvent (or more generally, to whatever FacesEvent we happen to
be delivering) just prior to invoking any listeners.
This seems like a perfectly reasonable solution to me, and doesn't
require any special handling of expected/actual parameter types in the
EL layer.
Andy
8:59 p.m.
New subject: [jsr-314-open] <h:dataTable> binding vs. ui:repeat
Andy, I lie that idea.
But personally I just like losing the event param altogether for now.
This will enable calling any bean method on an event.
My reason: I don't want to introduce extra restrictions, method signatures, or info
that people need to know in order to use something that should be simple, unless it works
either way.
I see the action attr as less of a valuechange event, but just a plain method called when
the valuechange occurrs.
Eventually I would like to see it work both ways, but for now I think it will be intuitive
and simple.
In conclusion: Ill submit my impl, and if someone wants to do this in addition, while
still supporting the basic function I'm including, go for it!
Lincoln
Sent from my Verizon Wireless BlackBerry
-----Original Message-----
From: Andy Schwartz <andy.schwartz(a)oracle.com>
Date: Fri, 04 Sep 2009 14:46:06
To: <jsr-314-open(a)jcp.org>
Subject: Re: [jsr-314-open] <h:dataTable> binding vs. ui:repeat
Finally read through this thread. Fun stuff. :-)
Martin Marinschek wrote:
Hi Ed,
> Which I still don't understand. Can you please explain explicitly?
>
I sent a mail to Kin-Man that we can't pass parameters from the
framework to the method-expression. So, we can now do:
#{bb.action(myparam)}
to call a method with signature:
public String action(String myparam) {}
but we can not do:
#{bb.valueChangeListener(myparam)}
to call a method with signature:
public void valueChangeListener(ValueChangeEvent ev, String myparam) {}
only with signature:
public void valueChangeListener(String myparam) {}
so what we loose is the ValueChangeEvent, which was provided by the
JSF framework as a parameter to the invoke-call in the
Method-Expression instance (we will only receive the parsed
parameters).
An alternative that I believe we could implement in the JSF layer
without any changes to the EL spec would be to provdie access to an
implicit "event" object during event delivery. The page author would
specify:
#{bb.valueChangeListener(event, myparam)}
Where bb.valueChangeListener is bound to:
public void valueChangeListener(ValueChangeEvent ev, String myparam)
{}
And the "event" implicit object is set up by JSF to point to the
ValueChangeEvent (or more generally, to whatever FacesEvent we happen to
be delivering) just prior to invoking any listeners.
This seems like a perfectly reasonable solution to me, and doesn't
require any special handling of expected/actual parameter types in the
EL layer.
Andy
9:21 p.m.
New subject: [jsr-314-open] <h:dataTable> binding vs. ui:repeat
Hi Lincoln -
lincolnbaxter(a)gmail.com wrote:
Andy, I lie that idea.
But personally I just like losing the event param altogether for now.
This will enable calling any bean method on an event.
My reason: I don't want to introduce extra restrictions, method signatures, or info
that people need to know in order to use something that should be simple, unless it works
either way.
Just to clarify... I was not proposing that we should place any extra
restriction/method signature on the user. I wonder whether perhaps my
use of the term "implicit object" was confusing... I did not mean to
imply that listeners would be forced to consume this implicit object,
just that we expose the FacesEvent in an EL-reachable locations, thus
making it available for use in method expressions.
So, the page author could do this:
#{bb.valueChangeListener(event, myparam)}
Or this:
#{bb.valueChangeListener(myparam, event)}
But this doesn't have any impact on your preferred solution, ie. the
user could also do this:
#{bb.valueChangeListener(myparam)}
Or:
#{bb.valueChangeListener(someManagedBean.foo, requestScope.bar,
component.clientId, event)}
Once we have support for invoking methods with arbitrary arguments, we
don't especially care what the user's method signature looks like.
I see the action attr as less of a valuechange event, but just a plain method called when
the valuechange occurrs.
Eventually I would like to see it work both ways, but for now I think it will be
intuitive and simple.
In conclusion: Ill submit my impl, and if someone wants to do this in addition, while
still supporting the basic function I'm including, go for it!
Sure. We can definitely tackle this part of the problem separately. :-)
Andy
Lincoln
Sent from my Verizon Wireless BlackBerry
-----Original Message-----
From: Andy Schwartz <andy.schwartz(a)oracle.com>
Date: Fri, 04 Sep 2009 14:46:06
To: <jsr-314-open(a)jcp.org>
Subject: Re: <h:dataTable> binding vs. ui:repeat
Finally read through this thread. Fun stuff. :-)
Martin Marinschek wrote:
> Hi Ed,
>
>
>
>> Which I still don't understand. Can you please explain explicitly?
>>
>>
> I sent a mail to Kin-Man that we can't pass parameters from the
> framework to the method-expression. So, we can now do:
>
> #{bb.action(myparam)}
>
> to call a method with signature:
>
> public String action(String myparam) {}
>
> but we can not do:
>
> #{bb.valueChangeListener(myparam)}
>
> to call a method with signature:
>
> public void valueChangeListener(ValueChangeEvent ev, String myparam) {}
>
> only with signature:
>
> public void valueChangeListener(String myparam) {}
>
> so what we loose is the ValueChangeEvent, which was provided by the
> JSF framework as a parameter to the invoke-call in the
> Method-Expression instance (we will only receive the parsed
> parameters).
>
>
An alternative that I believe we could implement in the JSF layer
without any changes to the EL spec would be to provdie access to an
implicit "event" object during event delivery. The page author would
specify:
> #{bb.valueChangeListener(event, myparam)}
>
Where bb.valueChangeListener is bound to:
> public void valueChangeListener(ValueChangeEvent ev, String myparam) {}
>
And the "event" implicit object is set up by JSF to point to the
ValueChangeEvent (or more generally, to whatever FacesEvent we happen to
be delivering) just prior to invoking any listeners.
This seems like a perfectly reasonable solution to me, and doesn't
require any special handling of expected/actual parameter types in the
EL layer.
Andy
9:26 p.m.
New subject: [jsr-314-open] <h:dataTable> binding vs. ui:repeat
I understant now, and I agree! I like that a lot.
Sent from my Verizon Wireless BlackBerry
-----Original Message-----
From: Andy Schwartz <andy.schwartz(a)oracle.com>
Date: Fri, 04 Sep 2009 15:21:20
To: <lincolnbaxter(a)gmail.com>; <jsr-314-open(a)jcp.org>
Subject: Re: [jsr-314-open] <h:dataTable> binding vs. ui:repeat
Hi Lincoln -
lincolnbaxter(a)gmail.com wrote:
Andy, I lie that idea.
But personally I just like losing the event param altogether for now.
This will enable calling any bean method on an event.
My reason: I don't want to introduce extra restrictions, method signatures, or info
that people need to know in order to use something that should be simple, unless it works
either way.
Just to clarify... I was not proposing that we should place any extra
restriction/method signature on the user. I wonder whether perhaps my
use of the term "implicit object" was confusing... I did not mean to
imply that listeners would be forced to consume this implicit object,
just that we expose the FacesEvent in an EL-reachable locations, thus
making it available for use in method expressions.
So, the page author could do this:
#{bb.valueChangeListener(event, myparam)}
Or this:
#{bb.valueChangeListener(myparam, event)}
But this doesn't have any impact on your preferred solution, ie. the
user could also do this:
#{bb.valueChangeListener(myparam)}
Or:
#{bb.valueChangeListener(someManagedBean.foo, requestScope.bar,
component.clientId, event)}
Once we have support for invoking methods with arbitrary arguments, we
don't especially care what the user's method signature looks like.
I see the action attr as less of a valuechange event, but just a plain method called when
the valuechange occurrs.
Eventually I would like to see it work both ways, but for now I think it will be
intuitive and simple.
In conclusion: Ill submit my impl, and if someone wants to do this in addition, while
still supporting the basic function I'm including, go for it!
Sure. We can definitely tackle this part of the problem separately. :-)
Andy
Lincoln
Sent from my Verizon Wireless BlackBerry
-----Original Message-----
From: Andy Schwartz <andy.schwartz(a)oracle.com>
Date: Fri, 04 Sep 2009 14:46:06
To: <jsr-314-open(a)jcp.org>
Subject: Re: [jsr-314-open] <h:dataTable> binding vs. ui:repeat
Finally read through this thread. Fun stuff. :-)
Martin Marinschek wrote:
> Hi Ed,
>
>
>
>> Which I still don't understand. Can you please explain explicitly?
>>
>>
> I sent a mail to Kin-Man that we can't pass parameters from the
> framework to the method-expression. So, we can now do:
>
> #{bb.action(myparam)}
>
> to call a method with signature:
>
> public String action(String myparam) {}
>
> but we can not do:
>
> #{bb.valueChangeListener(myparam)}
>
> to call a method with signature:
>
> public void valueChangeListener(ValueChangeEvent ev, String myparam) {}
>
> only with signature:
>
> public void valueChangeListener(String myparam) {}
>
> so what we loose is the ValueChangeEvent, which was provided by the
> JSF framework as a parameter to the invoke-call in the
> Method-Expression instance (we will only receive the parsed
> parameters).
>
>
An alternative that I believe we could implement in the JSF layer
without any changes to the EL spec would be to provdie access to an
implicit "event" object during event delivery. The page author would
specify:
> #{bb.valueChangeListener(event, myparam)}
>
Where bb.valueChangeListener is bound to:
> public void valueChangeListener(ValueChangeEvent ev, String myparam) {}
>
And the "event" implicit object is set up by JSF to point to the
ValueChangeEvent (or more generally, to whatever FacesEvent we happen to
be delivering) just prior to invoking any listeners.
This seems like a perfectly reasonable solution to me, and doesn't
require any special handling of expected/actual parameter types in the
EL layer.
Andy
3:09 p.m.
New subject: [jsr-314-open] <h:dataTable> binding vs. ui:repeat
On 4 Sep 2009, at 19:46, Andy Schwartz wrote:
An alternative that I believe we could implement in the JSF layer
without any changes to the EL spec would be to provdie access to an
implicit "event" object during event delivery. The page author
would specify:
> #{bb.valueChangeListener(event, myparam)}
Where bb.valueChangeListener is bound to:
> public void valueChangeListener(ValueChangeEvent ev, String
> myparam) {}
And the "event" implicit object is set up by JSF to point to the
ValueChangeEvent (or more generally, to whatever FacesEvent we
happen to be delivering) just prior to invoking any listeners.
This seems like a perfectly reasonable solution to me, and doesn't
require any special handling of expected/actual parameter types in
the EL layer.
IMO this is a far superior solution, as it is also far easier
understand - adding implicit parameters is very confusing!
11:28 p.m.
New subject: [jsr-314-open] <h:dataTable> binding vs. ui:repeat
On Fri, Sep 4, 2009 at 2:46 PM, Andy Schwartz <andy.schwartz(a)oracle.com>wrote:
Finally read through this thread.
I'm finally returning to it ;) It's been a good volley.
An alternative that I believe we could implement in the JSF layer without
any changes to the EL spec would be to provdie access to an implicit
"event"
object during event delivery. The page author would specify:
#{bb.valueChangeListener(event, myparam)}
>
Where bb.valueChangeListener is bound to:
public void valueChangeListener(ValueChangeEvent ev, String myparam) {}
>
And the "event" implicit object is set up by JSF to point to the
ValueChangeEvent (or more generally, to whatever FacesEvent we happen to be
delivering) just prior to invoking any listeners.
Brilliant. This nicely parallels JavaScript's implicit this and event
variable and aligns nicely with the implicit variables we have added for
composite components (developers will be used to it).
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
11:38 p.m.
New subject: [jsr-314-open] <h:dataTable> binding vs. ui:repeat
This gets my vote for how I'd like to see this handled in 2.1... if we
agree, shall we put in an enhancement for 2.1?
+1
Nice thinking, Andy.
Anyone else?
--Lincoln
On Tue, 2009-09-08 at 17:28 -0400, Dan Allen wrote:
On Fri, Sep 4, 2009 at 2:46 PM, Andy Schwartz
<andy.schwartz(a)oracle.com> wrote:
Finally read through this thread.
I'm finally returning to it ;) It's been a good volley.
An alternative that I believe we could implement in the JSF
layer without any changes to the EL spec would be to provdie
access to an implicit "event" object during event delivery.
The page author would specify:
#{bb.valueChangeListener(event, myparam)}
Where bb.valueChangeListener is bound to:
public void valueChangeListener(ValueChangeEvent ev,
String myparam) {}
And the "event" implicit object is set up by JSF to point to
the ValueChangeEvent (or more generally, to whatever
FacesEvent we happen to be delivering) just prior to invoking
any listeners.
Brilliant. This nicely parallels JavaScript's implicit this and event
variable and aligns nicely with the implicit variables we have added
for composite components (developers will be used to it).
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
--
Lincoln Baxter, III
Co-Founder of OcpSoft
Author of PrettyFaces URL Rewriting for JSF
9:56 p.m.
New subject: [jsr-314-open] <h:dataTable> binding vs. ui:repeat
Ed Burns wrote:
>>>>> On Fri, 07 Aug 2009 08:31:51 +0200, Martin
Marinschek <mmarinschek(a)apache.org> said:
>>>>>
MM> Hi Lincoln,
>> Unless I'm mistaken, ui:repeat is not a component and therefore cannot
>> be bound to a backing bean,
>>
MM> I thought it was - and just checked, it derives from UIComponentBase.
MM> Does the binding attribute not work for you?
Yes, but it's implementation specific and not in the
javax.faces.component package.
Ah, interesting. In Trinidad we have a common base class for components
that iterate over a collection:
http://myfaces.apache.org/trinidad/trinidad-api/apidocs/org/apache/myface...
This is used as the base for both UIXIterator (Trinidad equivalent of
ui:repeat) and UIXTable (Trinidad equivalent for UIData). Perhaps for
2.1 we should consider surfacing a similar base class/contract, along
with a public UIRepeat component.
Andy
6:03 p.m.
New subject: [jsr-314-open] <h:dataTable> binding vs. ui:repeat
First, please let me know if there is a better place to ask JSF Dev
related questions.
Question for you all: I could use some help.
I'm testing my listener changes with the new EL2 (and also Seam EL just
in case)-- I wanted to make sure that parameters can be passed through
the EL action MethodExpression.
It seems as though parameters work fine in general, but if the parameter
is cc.attrs.* --- EL resolves the param values to null.
So:
#{myObject} -- works if in scope, as it should
#{cc.attrs.myObject} -- null, even though it's passed in from
#{myObject} as an attribute.
UICommand components seem to have no trouble with resolving cc.attrs.*,
though.
Any thoughts? I've attached the modified source files in case anyone
wants to take a look. I'm not sure if this is a larger problem, or if
I've just missed something.
Thanks,
Lincoln
On Fri, 2009-09-04 at 15:56 -0400, Andy Schwartz wrote:
Ed Burns wrote:
>>>>>> On Fri, 07 Aug 2009 08:31:51 +0200, Martin Marinschek
<mmarinschek(a)apache.org> said:
>>>>>>
>
> MM> Hi Lincoln,
>
>>> Unless I'm mistaken, ui:repeat is not a component and therefore cannot
>>> be bound to a backing bean,
>>>
>
> MM> I thought it was - and just checked, it derives from UIComponentBase.
> MM> Does the binding attribute not work for you?
>
> Yes, but it's implementation specific and not in the
> javax.faces.component package.
>
>
Ah, interesting. In Trinidad we have a common base class for components
that iterate over a collection:
http://myfaces.apache.org/trinidad/trinidad-api/apidocs/org/apache/myface...
This is used as the base for both UIXIterator (Trinidad equivalent of
ui:repeat) and UIXTable (Trinidad equivalent for UIData). Perhaps for
2.1 we should consider surfacing a similar base class/contract, along
with a public UIRepeat component.
Andy
--
Lincoln Baxter, III
Co-Founder of OcpSoft
Author of PrettyFaces URL Rewriting for JSF
9:23 p.m.
New subject: [jsr-314-open] <h:dataTable> binding vs. ui:repeat
Hey Lincoln -
Lincoln Baxter, III wrote:
First, please let me know if there is a better place to ask JSF Dev
related questions.
I suppose the Mojarra dev list might be the right place for
implementation questions:
https://javaserverfaces.dev.java.net/mailinglists.html
Though personally I am fine with you asking here. :-)
Could you send along your composite component implementation (and
perhaps a snippet from the consuming page)? Just want to make sure I
understand the use case.
Andy
8:34 p.m.
New subject: [jsr-314-open] <h:dataTable> binding vs. ui:repeat
On 09/04/2009 12:56 PM, Andy Schwartz wrote:
Ed Burns wrote:
>>>>>> On Fri, 07 Aug 2009 08:31:51 +0200, Martin Marinschek
>>>>>> <mmarinschek(a)apache.org> said:
>
> MM> Hi Lincoln,
>>> Unless I'm mistaken, ui:repeat is not a component and therefore cannot
>>> be bound to a backing bean,
>
> MM> I thought it was - and just checked, it derives from
> UIComponentBase.
> MM> Does the binding attribute not work for you?
>
> Yes, but it's implementation specific and not in the
> javax.faces.component package.
>
Ah, interesting. In Trinidad we have a common base class for
components that iterate over a collection:
http://myfaces.apache.org/trinidad/trinidad-api/apidocs/org/apache/myface...
This is used as the base for both UIXIterator (Trinidad equivalent of
ui:repeat) and UIXTable (Trinidad equivalent for UIData). Perhaps for
2.1 we should consider surfacing a similar base class/contract, along
with a public UIRepeat component.
RichFaces uses the same approach too. I believe
that iteration
components should be complete rewritten in JSF 2.1 using such
architecture. Does Trinidad tree comonent use the same base class ?
Andy
9:49 p.m.
New subject: [jsr-314-open] <h:dataTable> binding vs. ui:repeat
Hi,
Yes, Trinidad uses UIXCollection as the base class for all iterating components
(UIXIterator and UIXHierarchy) which are then extended by UIXTable, UIXTree,
UIXNavigation*, etc. The exact hierarchy is something like:
UIXCollection
-- UIXIterator
-- UIXTable
-- CoreTable
-- UIXHierarchy
-- UIXTree
-- UIXTreeTable
-- CoreTreeTable
-- UIXNavigationHierarchy
-- UIXNavigationLevel
-- CoreNavigationPane
Regards,
~ Simon
________________________________
From: jsr-314-open-bounces(a)jcp.org on behalf of Alaxander Smirnov
Sent: Mon 9/14/2009 2:34 PM
To: jsr-314-open(a)jcp.org
Subject: Re: [jsr-314-open] <h:dataTable> binding vs. ui:repeat
On 09/04/2009 12:56 PM, Andy Schwartz wrote:
Ed Burns wrote:
>>>>>> On Fri, 07 Aug 2009 08:31:51 +0200, Martin Marinschek
>>>>>> <mmarinschek(a)apache.org> said:
>
> MM> Hi Lincoln,
>>> Unless I'm mistaken, ui:repeat is not a component and therefore cannot
>>> be bound to a backing bean,
>
> MM> I thought it was - and just checked, it derives from
> UIComponentBase.
> MM> Does the binding attribute not work for you?
>
> Yes, but it's implementation specific and not in the
> javax.faces.component package.
>
Ah, interesting. In Trinidad we have a common base class for
components that iterate over a collection:
http://myfaces.apache.org/trinidad/trinidad-api/apidocs/org/apache/myface...
This is used as the base for both UIXIterator (Trinidad equivalent of
ui:repeat) and UIXTable (Trinidad equivalent for UIData). Perhaps for
2.1 we should consider surfacing a similar base class/contract, along
with a public UIRepeat component.
RichFaces uses the same approach too. I believe
that iteration
components should be complete rewritten in JSF 2.1 using such
architecture. Does Trinidad tree comonent use the same base class ?
Andy
5343
days inactive
5371
days old
jsr-314-open-mirror@lists.jboss.org
20 comments
9 participants
participants (9)
-
Alaxander Smirnov -
Andy Schwartz -
Dan Allen -
Ed Burns -
Lincoln Baxter, III -
lincolnbaxter＠gmail.com
-
Martin Marinschek -
Pete Muir -
Simon Lessard