[jsr-314-open-mirror] [jsr-314-open] [901-DeprecateTargetConcept]
by Ed Burns
>>>>> On Fri, 29 Oct 2010 12:23:34 -0400, Andy Schwartz <andy.schwartz(a)oracle.com> said:
AS> identified in the interface section. Perhaps the verb "implements"
AS> captures this better than "insert"?
AS> <composite:interface>
AS> <composite:actionSource name="loginButton"/>
AS> </composite:interface>
AS> <composite:implementation>
AS> <h:commandButton>
AS> <composite:implementsActionSource name="loginButton"/>
AS> </h:commandButton>
AS> </composite:implementation>
AS> In any case, regardless of the tag name, I think that this is a much
AS> improved approach. Thanks for pushing this Jakob (and Leonardo, Martin
AS> and Ganesh too)!
JK> Thanks, Andy! Frankly I also do not really like the term "insert"
JK> here, because - as you said - it just does not fit that well. However
JK> I really, really like "implements" - this is just soo much better :)
If we're talking verbs here, I think an even better one is "exposes".
The component implements the thing whether it's exposed or not. What
we're really doing here is exposing the fact that it has a
behavioral interface attached object target.
Ed
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 8 work days until German Oracle User's Group Conference
13 years, 6 months
[jsr-314-open-mirror] [jsr-314-open] [902-ViewDeclarationLanguageSelection] (was: Re: 490-XmlViews Processing JSPX files as Facelets)
by Ed Burns
This is targeted for 2.2.
>>>>> On Tue, 12 Oct 2010 19:20:22 -0500, Leonardo Uribe <lu4242(a)gmail.com> said:
LU> <faces-config-extension>
LU> <vdl-configuration>
LU> <vdl-id>facelets</vdl-id>
LU> <vdl-class>xxx.yyy.zzz.MyCustomFaceletsVDLWrapper</vdl-class>
LU> <vdl-global-resource-mapping>
LU> <file-extension>.jspx</file-extension>
LU> <vdl-resource-mapping-config> <!-- Saved on key/value map or
LU> something like that -->
LU> <process-as>jspx</process-as>
LU> </vdl-resource-mapping-config>
LU> </vdl-global-resource-mapping>
LU> <vdl-global-resource-mapping>
LU> <file-extension>.view.xml</file-extension>
LU> <vdl-resource-mapping-config> <!-- Saved on key/value map or
LU> something like that -->
LU> <process-as>xml</process-as>
LU> </vdl-resource-mapping-config>
LU> </vdl-global-resource-mapping>
LU> </vdl-configuration>
LU> </faces-config-extension>
LU> It is almost the same as we have before but with the following
LU> differences:
LU> 1. Every VDL has an id (like with RenderKit)
LU> 2. There is an option to provide custom properties, that allow pass the
LU> "mode".
LU> 3. <vdl-global-resource-mapping> tag says "... all resources that match
LU> this mapping
LU> in the webapp will be processed by this VDL using these configuration
LU> params ..."
LU> 4. (Optional) Allow to provide a wrapper for a VDL implementation,
LU> allowing to extend
LU> it (maybe useful for gracelets????).
LU> Did you see the relationship between all three problems?
LU> - All of them require changes on
LU> ViewDeclarationLanguage/ViewDeclarationLanguageFactory.
LU> - Problem (1) is enough simple to solve, because it just require some code
LU> relocation that already exists,
LU> but it is necessary to update the spec.
LU> - Problem (2) is the general case of (3), so we just need to change the
LU> current patch a little bit.
LU> - To make (3) and use it as expected we need (1) fixed.
LU> I'm willing to contribute with this issue doing some code if necessary (I'll
LU> try it to see how
LU> far I can go).
LU> Suggestions are welcome.
LU> best regards,
[1] https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=902
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 8 work days until German Oracle User's Group Conference
13 years, 6 months
[jsr-314-open-mirror] [jsr-314-open] [901-DeprecateTargetsConcept] PROPOSAL
by Ed Burns
>>>>> On Fri, 29 Oct 2010 13:02:10 +0200, Jakob Korherr <jakob.korherr(a)gmail.com> said:
JK> Hi,
JK> Thinking more of it and trying out some prototypes, I now think
JK> Leonardo's approach is the way to go. Of course, it would somehow be
JK> possible to circumvent the problems mentioned before (like multiple
JK> action listeners or the missing f: tag for client behaviors), but
JK> after reading the vdldocs again, I think it's much more consistent
JK> with what we have right now.
JK> Consider the current facet solution: The user can provide facets for
JK> the composite component and the author of the composite component can
JK> add them to implementation-components via cc:insertFacet. And this is
JK> exactly what we need for cc:actionSource, cc:valueHolder,
JK> cc:editableValueHolder and cc:clientBehavior.
JK> Thus I would propose the following new tags (from Leonardo's original proposal):
JK> <cc:insertActionSource name="XXX" />
JK> <cc:insertEditableValueHolder name="XXX"/>
JK> <cc:insertValueHolder name="XXX" />
JK> <cc:insertClientBehavior name="XXX" />
Seems reasonable. I'd like to see a prototype.
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 8 work days until German Oracle User's Group Conference
13 years, 6 months
[jsr-314-open-mirror] [jsr-314-open] [901-DeprecateTargetsConcept] (was: Re: composite components: targets attribute revisited)
by Ed Burns
LU> To be more explicit, this is the example that should fail:
LU> <ez:loginPanel id="loginPanel" model="#{bean}">
LU> <f:actionListener for="loginEvent"
LU> binding="#{bean.loginEventListener}" />
LU> <f:actionListener for="loginEvent"
LU> binding="#{bean.loginEventListener2}" />
LU> <f:actionListener for="cancelEvent"
LU> binding="#{bean.cancelEventListener}" />
LU> </ez:loginPanel>
LU> <composite:interface name="loginPanel">
LU> <composite:actionSource name="loginEvent" />
LU> <composite:actionSource name="cancelEvent" />
LU> </composite:interface>
LU> <composite:implementation>
LU> <h:commandButton name="button1">
LU> <f:actionListener
LU> binding="#{cc.actionSource.loginEvent}"/>
LU> </h:commandButton>
LU> <x:mycompositecomponent name="button2">
LU> <f:actionListener
LU> binding="#{cc.actionSource.cancelEvent}" for="someOtherEvent"/>
LU> </x:mycompositecomponent>
LU> </composite:implementation>
LU> In this case, the binding #{cc.actionSource.loginEvent} does not
LU> point to just one actionListener.
GP> Leo, IMO your example wouldn't need to fail: the nested
GP> actionListener with binding="#{cc.actionSource.loginEvent}" would
GP> need to execute *all* actionListeners that have been bound to
GP> "loginEvent". In this case "#{bean.loginEventListener}" and
GP> "#{bean.loginEventListener2}" would reside in a Map named
GP> cc.actionSource.loginEvent and could both be executed. Wouldn't this
GP> work?
EB> The type of the binding attribute is specified thus.
EB> Value binding expression that evaluates to an object that implements
EB> javax.faces.event.ActionListener
EB> How would you make that handle a list?
EB> Sure, we could go and add a raft of new "bindingList" attributes to all
EB> of the attached object handlers in f:, but is it worth the complexity?
>>>>> On Fri, 29 Oct 2010 12:05:17 +0200, Martin Marinschek <mmarinschek(a)apache.org> said:
MM> Hi Gentlemen,
MM> I am leaning toward Jakob's approach, but if it is not possible due to
MM> the constraints Leonardo mentioned, then why not add the necessary
MM> tags?
MM> @Leonardo, Jakob: can you put your heads together and come up with a
MM> combined proposal?
Please do so on this new issue I've created [1]. We will not be able to
put this into 2.1. I'm afraid we'll have to live with only targets for
2.1. This will have to go into 2.2.
Ed
[1] https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=901
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 8 work days until German Oracle User's Group Conference
13 years, 6 months
[jsr-314-open-mirror] [jsr-314-open] [859-MultiActionComponent] RESOLVED (was: Re: Composite components only support one action) attribute (review of issue 859)
by Ed Burns
>>>>> On Thu, 28 Oct 2010 12:17:12 -0500, Leonardo Uribe <lu4242(a)gmail.com> said:
LU> https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=859
LU> and then Ed Burns propose another similar one, but filling the gaps in
LU> documentation and integration with automated tests (That's cool!).
LU> Instead call it "methodType", it was proposed targetAttributeName and added
LU> this
LU> documentation:
LU> "...This attribute allows the name of the attribute exposed to the using
LU> page to differ from the one actually used in the implementation. For
LU> example, consider a composite component that contains two buttons, one
LU> that means "submit" and one that means "cancel". It is natural to want
LU> to declare two composite component attributes to allow these buttons to
LU> be customized, for example, "submitAction" and "cancelAction". For both
LU> of these buttons, the method expression should be retargeted to the
LU> inner button's "action" attribute. This scenario would be expressed as
LU> follows..."
LU> And the proposal using "targetAttributeName" looks like this:
As Martin pointed out in a private email, method-signature is optional.
So either of these are valid:
<cc:interface>
<cc:attribute name="submitAction" targetAttributeName="action" />
<cc:attribute name="cancelAction" targetAttributeName="action" />
</cc:interface>
<cc:interface>
<cc:attribute name="submitAction" targetAttributeName="action"
method-signature="java.lang.Object action()" />
<cc:attribute name="cancelAction" targetAttributeName="action"
method-signature="java.lang.Object action()" />
</cc:interface>
LU> In my opinion, the syntax using "methodType" is preferred. In that one, we
LU> are just
LU> defining the attribute is used for the behavioral interface ActionSource, as
LU> an "action",
LU> and the method-signature declaration is not necessary anymore.
I don't want to introduce the concept of type here. We already have the
concepts of method-signature, MethodExpression, and special attribute
names.
Therefore, I'm going with targetAttributeName.
Committed revision 8688.
LU> Note that this syntax already works (partially) without the patch:
LU> <cc:attribute name="submitAction" method-signature="java.lang.Object
LU> action()"/>
LU> I said "partially" because these two method signatures are valid for action:
LU> java.lang.Object action()
LU> void action()
LU> The problem is more clear when "actionListener" is considered because it has
LU> these two
LU> valid signatures (since JSF 2):
LU> void method(javax.faces.event.ActionEvent )
LU> void method()
LU> It is not possible to map it using method-signature, because it only allows
LU> one of them, but
LU> if we use a notation like this:
LU> <cc:attribute name="submitActionListener" methodType="actionListener"/>
LU> The previous two signatures are assumed and problem solved. I still think
LU> method-signature should allow multiple ones using ';', but before that (I
LU> want to propose a
LU> patch but not yet), I prefer the proposed patch using methodType.
LU> Suggestions are welcome.
LU> best regards,
LU> Leonardo Uribe
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 9 work days until German Oracle User's Group Conference
13 years, 6 months
[jsr-314-open-mirror] [jsr-314-open] [490-XmlViews] RESOLVED: Namespace and DOCTYPE
by Ed Burns
Here's what we will do for 2.1.
SECTION: DOCTYPE
* Add this row to Table 1-1 in Appendix A
<process-as>xhtml <process-as>xml <process-as>JSPX
XML Doctype passed through consumed consumed
* Add a doctype renderer to HTML_BASIC. Yes, I know doctype is not just
HTML and is in fact SGML, but I can't see putting it in f: because
nothing there actually has a real renderer (ClientBehaviorRenderers are
not real Renderers).
The tag handler for this comes from Andy's suggestion.
<h:doctype rootElement="html" public="..." system="..." />
SECTION: Namespace
* If you want a namespace passed through to the client, pass it on
<html>, as suggested by Andy.
AS> Of course, the following approach works just fine:
>> <f:view xmlns:f="http://java.sun.com/jsf/core"
>> xmlns:h="http://java.sun.com/jsf/html">
>> <html xmlns="http://www.w3.org/1999/xhtml">
SECTION: ResponseWriter
AS> By the time we get to the ResponseWriter, we have less information
AS> available to us, and thus harder to correct arbitrary missing namespaces.
B> This is where the ResponseWriter is being hosed by the lack of apis for
B> the namespace. In theory, the default Facelets tag handler should
I do not want to pull ResponseWriter into this discussion now. That'll
have to wait.
Ed
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 9 work days until German Oracle User's Group Conference
13 years, 6 months
Re: [jsr-314-open-mirror] [jsr-314-open] [490-XmlViews] RESOLVED: Namespace and DOCTYPE
by Ed Burns
>>>>> On Thu, 28 Oct 2010 12:38:15 -0700, Blake Sullivan <blake.sullivan(a)oracle.com> said:
EB> SECTION: Namespace
EB> * If you want a namespace passed through to the client, pass it on
EB> <html>, as suggested by Andy.
B> I think that they can set it on any element that uses the default tag
B> handler.
Yes, that is correct.
B> However, they shouldn't need to pass through the HTML
B> namespace anyway, since the XHTML ResponseWriter should be outputting
B> this for them if we are actually sending out XHTML.
I looked through the latest spec and I can't find any reference to
an XHTML ResponseWriter, nor is there any code that automatically
generates an xmlns="http://www.w3.org/1999/xhtml". As far as I can see,
the only way to get an xmlns="http://www.w3.org/1999/xhtml" through to
the user agent is to put it there as Andy suggests.
Therefore, our existing resolution stands.
B> We agree that the multi-namespace cases can wait. The XHTML
B> ResponseWriter can do the right thing anyway, so there shouldn't be any
B> basic cases where the namespace needs to be passed through.
Again with the XHTML ResponseWriter. Am I missing something?
Ed
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 9 work days until German Oracle User's Group Conference
13 years, 6 months
[jsr-314-open-mirror] [jsr-314-open] composite components: targets attribute revisited
by Jakob Korherr
Hi,
Currently there are a lot of discussions (on spec-issues, on this list
and also internally) about the problems with the targets attribute in
the composite component interface and I'd like to wrap these up here.
IMHO the targets attribute is something we should get rid of, because
it directly points to the implementation section and frankly somehow
feels like the following piece of code:
if (this instanceof Foo)
{
// do something
}
The interface section should just specify the interface for the
composite component and should not include any information about the
implementation section. However, the implementation section should of
course refer to the interface section. Unfortunately the targets
attribute works against this. And furthermore the targets attribute
also confuses users, because the don't really know which clientid to
use (especially with nested components in the implementation section).
The first step needed here is to put all attributes (also the
"well-known" ones like action, actionListener, valueChangeListener) on
the composite component attribute map in order to access them via
#{cc.attrs.attributeName}. In this way the user can refer from the
implementation section to the related attribute in the interface
section, regardless of what it does. This was already discussed and is
also already accepted, I guess.
The next step is to remove the targets attribute from cc:actionSource,
cc:editableValueHolder and cc:valueHolder. Here we have two options:
1) add new composite tags that insert the related listeners in the
implementation section (proposed by Leonardo):
<ez:loginPanel id="loginPanel" model="#{bean}">
<f:actionListener for="loginEvent"
binding="#{bean.loginEventListener}" />
<f:actionListener for="cancelEvent"
binding="#{bean.cancelEventListener}" />
</ez:loginPanel>
<composite:interface name="loginPanel">
<composite:actionSource name="loginEvent" />
<composite:actionSource name="cancelEvent" />
</composite:interface>
<composite:implementation>
<h:commandButton name="button1">
<composite:insertActionSource name="loginEvent"/>
</h:commandButton>
<x:mycompositecomponent name="button2">
<composite:insertActionSource
name="cancelEvent" for="someOtherEvent"/>
</x:mycompositecomponent>
</composite:implementation>
2) use the existing tags like f:actionListener and
f:valueChangeListener and provide the actionSource,.. via
ValueExpression:
<ez:loginPanel id="loginPanel" model="#{bean}">
<f:actionListener for="loginEvent"
binding="#{bean.loginEventListener}" />
<f:actionListener for="cancelEvent"
binding="#{bean.cancelEventListener}" />
</ez:loginPanel>
<composite:interface name="loginPanel">
<composite:actionSource name="loginEvent" />
<composite:actionSource name="cancelEvent" />
</composite:interface>
<composite:implementation>
<h:commandButton name="button1">
<f:actionListener
binding="#{cc.actionSource.loginEvent}"/>
</h:commandButton>
<x:mycompositecomponent name="button2">
<f:actionListener
binding="#{cc.actionSource.cancelEvent}" for="someOtherEvent"/>
</x:mycompositecomponent>
</composite:implementation>
Frankly I'd prefer option 2, because it is very similar to how we
handle cc:attribute --> #{cc.attrs.xxx}.
One remaining problem here, however, is how to handle non-required
method-attributes (there's a thread about this on the
myfaces-user-list). IMO the default attribute of cc:attribute should
be able to resolve to a MethodExpression and not only to a String (I
think this is already a spec-issue), but it should also work without
providing a default value. In that case #{cc.attrs.thatAttribute}
should internally return an empty action/listener/... so that there
are no problems with the related implementation-components which refer
to this attribute.
What do you think?
Regards,
Jakob
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
13 years, 6 months