Re: [jsr-314-open-mirror] [jsr-314-open] [490-XmlViews][893-ViewDeclarationLanguage] REOPENED
by Ed Burns
>>>>> On Thu, 28 Oct 2010 14:57:43 -0400, Andy Schwartz <andy.schwartz(a)oracle.com> said:
AS> On 10/28/10 2:52 PM, Leonardo Uribe wrote:
>>
>> If ConfigurableNavigationHandler uses deriveLogicalViewId, my answer
>> is yes,
>> in my opinion VDL.viewExists() should be called from
>> ConfigurableNavigationHandler.
>> There is no call for ExternalContext.getResource() from instances of
>> ConfigurableNavigationHandler.
AS> Thanks for checking on this Leonardo. I see that Mojarra's
AS> NavigationHandlerImpl is calling deriveViewId(), so we will already hit
AS> VDL.viewExists().
AS> Ed -
AS> Looks like we are all set. No additional changes are needed for
AS> implicit navigation.
Ok, thanks. Can you please close the issue again?
Thanks,
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] [490-XmlViews][893-ViewDeclarationLanguage] REOPENED
by Ed Burns
EB> Leonardo, In your opinion, do we need to make any changes to
EB> NavigationHandler so that the new ViewDeclarationLanguage.viewExists()
EB> method is consulted? I would expect this might need to be done.
AS> Oh, woops - yep. ConfigurableNavigationHandler implementations
AS> should use VDL.viewExists() instead of ExternalContext.getResource()
AS> to test for view existence when determining whether implicit
AS> navigation is possible. Actually, any place where we were using
AS> ExternalContext.getResource() to check for a physical view needs to
AS> go through VDL.viewExists() now. I believe that
AS> ViewHandler.deriveViewId() and implicit navigation are the only 2
AS> places where this comes up, though I will double check that later
AS> today.
OK, I have reopened the issue and will assign it to you. Please attach
a patch to the issue and send it to dev(a)javaserverfaces.dev.java.net for
review. When I review the patch, I'll make the necessary changes to the
spec PDF document.
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] Chapter 11: The JSF XML View Syntax
by Ed Burns
>>>>> On Tue, 26 Oct 2010 13:15:18 -0400, Andy Schwartz <andy.schwartz(a)oracle.com> said:
AS> BTW, regarding Ed's earlier comment:
EB> the most important manifestation of that, in my opinion, is the
EB> requirement to have *all* elements prefixed. For example, a
EB> proper JSF
EB> XML Syntax View would look like this.
EB>
EB> <?xml version="1.0" encoding="UTF-8"?>
EB> <weNeedSomeRootElement
EB> xmlns:html="http://www.w3.org/1999/xhtml"
EB> xmlns:h="http://java.sun.com/jsf/html">
AS> We already have several potential elements/tags that can serve as the
AS> root level element, including eg:
AS> - <html>
AS> - <h:html>
AS> - <f:view>
Ok, here's what we'll do for JSF XML syntax.
<f:view xmlns="http://www.w3.org/1999/xhtml"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:h="http://java.sun.com/jsf/html">
<html>
<h:head><h:title>Title</h:title></h:head>
<h:body>
<h2>HTML elements ok</h2>
</h:body>
</html>
</f:view>
AS> As such I don't believe that we need to add yet another element.
Ok, agreed. It's <f:view> If you want to do Facelets XHTML, then you
just put your stuff on the root <html> element.
AS> This got me to thinking though... I believe that we have a fairly big
AS> gap in our XML strategy: I don't see any straightforward way to specify
AS> a doctypte that will be passed through to the browser. Earlier Dan had
AS> suggested adding new elements for this purpose:
>> 3) All markup declarations should be produced by the component tree
>> (e.g., XML declaration, doctype, namespaces, CDATA, XML comments, etc)
>> This means we need the following tags:
>> f:document
>> f:doctype
>> f:comment (why not, it is just xml)
>> f:cdata
>> (The prefix is debatable, I'm just throwing it out there)
AS> We have added an h:html component in 2.1 - but as far as I can see we
AS> haven't addressed the other items. I think that we minimally need some
AS> way to specify the doctype - eg. an h:doctype element since without this
AS> the documents rendered in our XML processing mode will be doctype-less.
AS> BTW, one thing that I am not totally clear on... What value does
AS> <h:html> add over plain old <html>?
It's a resource target, in addition to rendering the <html> element.
Yes, I read Dan's initial comments but decided to go with the minimal
set you have seen in the design thus far. So, I'll not be introducing
<f:doctype> in this revision.
Ed
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 11 work days until German Oracle User's Group Conference
13 years, 6 months
[jsr-314-open-mirror] [jsr-314-open] Composite components only support one action attribute (review of issue 859)
by Leonardo Uribe
Hi
Yesterday I attached a patch for this issue:
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=859
and then Ed Burns propose another similar one, but filling the gaps in
documentation and integration with automated tests (That's cool!).
Instead call it "methodType", it was proposed targetAttributeName and added
this
documentation:
"...This attribute allows the name of the attribute exposed to the using
page to differ from the one actually used in the implementation. For
example, consider a composite component that contains two buttons, one
that means "submit" and one that means "cancel". It is natural to want
to declare two composite component attributes to allow these buttons to
be customized, for example, "submitAction" and "cancelAction". For both
of these buttons, the method expression should be retargeted to the
inner button's "action" attribute. This scenario would be expressed as
follows..."
I see that from other point of view. I think that the attribute proposed
indicates
the attribute will be "consumed" as an method expression of type "action".
The proposal using "methodType" looks like this in the test app:
<cc:attribute name="submitAction" targets="submitButton"
methodType="action"/>
<cc:attribute name="cancelAction" targets="cancelButton"
methodType="action"/>
But the intention including the patch on 755 (allow #{cc.attrs.action}) is
this
should looks like this (I'm trying to keep them separate to prevent
confusions):
<cc:attribute name="submitAction" methodType="action"/>
<cc:attribute name="cancelAction" methodType="action"/>
And the proposal using "targetAttributeName" looks like this:
<cc:attribute name="submitAction" targetAttributeName="action"
method-signature="java.lang.Object action()"/>
<cc:attribute name="cancelAction" targetAttributeName="action"
method-signature="java.lang.Object action()"/>
In my opinion, the syntax using "methodType" is preferred. In that one, we
are just
defining the attribute is used for the behavioral interface ActionSource, as
an "action",
and the method-signature declaration is not necessary anymore.
Note that this syntax already works (partially) without the patch:
<cc:attribute name="submitAction" method-signature="java.lang.Object
action()"/>
I said "partially" because these two method signatures are valid for action:
java.lang.Object action()
void action()
The problem is more clear when "actionListener" is considered because it has
these two
valid signatures (since JSF 2):
void method(javax.faces.event.ActionEvent )
void method()
It is not possible to map it using method-signature, because it only allows
one of them, but
if we use a notation like this:
<cc:attribute name="submitActionListener" methodType="actionListener"/>
The previous two signatures are assumed and problem solved. I still think
method-signature should allow multiple ones using ';', but before that (I
want to propose a
patch but not yet), I prefer the proposed patch using methodType.
Suggestions are welcome.
best regards,
Leonardo Uribe
13 years, 6 months
[jsr-314-open-mirror] [jsr-314-open] [490-XmlViews][893-ViewDeclarationLanguage] RESOLVED
by Ed Burns
>>>>> On Wed, 20 Oct 2010 18:32:56 -0400, Andy Schwartz <andy.schwartz(a)oracle.com> said:
AS> I have attached a patch to issue 893 that implements these changes. See:
I have reviewed and applied the most recent patch for 893 that is
attached to the issue (take3). I see no reason not to commit it so I'll
do so presently.
Leonardo, In your opinion, do we need to make any changes to
NavigationHandler so that the new ViewDeclarationLanguage.viewExists()
method is consulted? I would expect this might need to be done.
Andy, for completeness, don't we need to implement viewExists() for JSP?
In any case, I've committed revision 8686 with this fix, and also made
the necessary spec changes, to the Frame document as well.
Ed
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 10 work days until German Oracle User's Group Conference
13 years, 6 months
[jsr-314-open-mirror] [jsr-314-open] [Spec-869-Specify CSRF Solution] PROPOSAL(s)
by Roger Kitain
There are two proposals for enhancing CSRF attacks in JSF. We need to
pick one.
Proposal 1: Form Action URL Approach (Approach provided by Kito Mann)
This approach does the following: - Token is generated on the
server consisting (minimally) of a randomly generated "secret key
(stored in session).
- ViewHandler.getActionURL method must include the token parameter
named "javax.faces.Token", and whose value is the token value.
- At render time this token will be included in Form's action URL -
and it will be
posted back to the server.
- Restore View Phase processing compares the incoming token request
parameter value
with the token value generated from the secret key in the session.
Spec Document Modifications:
Section 7.5.1:
getActionURL:
"The URL must contain the parameter constant defined by
ResponseStateManager.VIEW_TOKEN_PARAM
The value of this parameter must be a cryptographically produced value
minimally consisting
of a "secret key". The "secret key" is a random generated value that was
stored in the session
(preferably around session creation time). Implementations may also
choose to combine other
values with the secret key to produce a more complex token."
Section 2.2.1
"Verify the "javax.faces.Token" request parameter value is the same as
the token value generated
from the "secret key" stored in the session. If the values do not
match, throw a meaningful
exception."
Proposal 2: Form Hidden Field Approach
This approach is similar to Approach 1, except a Form hidden field
"javax.faces.Token"
is used instead of appending to the Form's Action URL.
Spec Document Modifications:
Standard RenderKit Docs
- Form Rendering
"Render a hidden field named "javax.faces.Token" using the
ResponseStateManager.VIEW_TOKEN_PARAM
constant. The value of this hidden field is a cryptographically
produced value that must at least
consist of a "secret key". The "secret key" is a random generated
value that was stored in the
session (preferably around session creation time). Implementations
may also choose to combine
other values with the secret key to produce a more complex token."
Specification Document
Section 2.2.1
"Verify the "javax.faces.Token" request parameter value is the same
as the token value generated
from the "secret key" stored in the session. If the values do not
match, throw a FacesException.
For both approaches see:
[1]
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=869
Look at the two latest change bundles attached to the issue.
Please review by COB Friday as we have no time left for 2.1.
Kudos to Kito Mann for helping out with the implementation.
-roger
13 years, 6 months
[jsr-314-open-mirror] [jsr-314-open] JSF 2.1 Omnibus reply
by Ed Burns
With this email, I'll try to ensure that all loose ends for JSF 2.1 are
tied up.
MANY THANKS to JBoss for the email archive. During the JCP award
ceremony at JavaOne, I winced every time an award was announced for a
category where JBoss was a finalist and did not get the award.
SECTION: [869-CSRF] [1] Roger is rolling back this entire spec issue. If the
feedback were delivered earlier, this rollback might have been avoided.
SECTION: [490-XmlViews] [2] Ed removed Chapter 11 and the faces-view
schema from the spec.
SUBSECTION: What are we doing with <facelets-processing>?
Yes, specifying this information in a faces-config.xml does pre-suppose
some sort of jar-local setting. That was Andy's original intent.
However, we don't have the spec language for this yet, and I think it is
safe to introduce jar-local settings in a future specification release.
LU> 1. Fix ResourceResolver
LU> 2. Fix suffix definition for vdls
LU> 3. Fix specific suffix handling for facelets vdl
What are we doing with suffix/extension configuration:
AS> - Enhance the DEFAULT_FACELETS_SUFFIX context parameter to allow it
AS> to support multiple values + change the default value to ".xhtml
AS> .view.xml". Or...
AS> - Specify a default value for the FACELETS_VIEW_MAPPINGS context
AS> parameter.
AS> Either of these seem acceptable to me.
EB> I am reluctant to bind .view.xml to be "Facelets". Yes, right now
EB> Mojarra is using the Facelets VDL impl to process .view.xml but I'd
EB> rather leave the DEFAULT_FACELETS_SUFFIX and FACELET_VIEW_MAPPINGS
EB> unchanged for 2.1. Note that I did change the value of
EB> ViewHandler.DEFAULT_SUFFIX to be ".xhtml .view.xml .jsp".
SUBSECTION: derived view id changes
LU> It seems, but note the algorithm required to deriveViewId() should
LU> call ResourceResolver to check for resources, specially when suffix
LU> mapping is used, so if it is necessary to change section 7.5.2 for
LU> each problem, it could be good to do both changes at once.
What changes are necessary to 7.5.2?
LU> <faces-config> tag like renderkit does:
LU>
LU> <view-declaration-language>
LU>
LU> <view-declaration-language-id>javax.faces.Jsp</view-declaration-language-id>
LU>
LU> <view-declaration-language-class>my.bizarre.vdl.WrapperForJspOnly</view-declaration-language-class>
LU> </view-declaration-language>
LU>
LU> and VDL prefix/suffix mapping inside <faces-config-extension> tag.
I think this is pushing it for 490. We have to move this part to 2.2.
AS> 1. The ViewHandler.getViewDeclarationLanguage() should be clear that
AS> it expects "derived" view ids.
Your patch to 893 does this.
AS> 2. We need some way to safely derive view ids from the restore view
AS> phase. This means that we either need to be able to use the
AS> existing ViewHandler.deriveViewId() without triggering TCK failures,
AS> or we need a new method on ViewHandler that performs the same
AS> functionality as deriveViewId() without requiring that the derived
AS> view id passes the existence check.
Your patch to 893 does this.
AS> 3. We need a method on ViewDeclarationLanguage for testing view
AS> existence, eg. viewExists(). We should use this instead of directly
AS> calling ExternalContext.getResource() when checking to see whether a
AS> viewId corresponds to a physical view.
Your patch to 893 does this.
AS> 4. We need some way to wrap a specific VDL (eg. the JSP VDL). The
AS> minimal solution would be to introduce a VDL id (eg.
AS> ViewDeclarationLanguage.getId()) and define standard ids for the JSP
AS> and Facelets VDLs.
I'm not opposed, but can you clearly articulate, in one or two
sentences, why we need this?
We are not doing anything along the lines of
ViewDeclarationLanguage.getConfiguredExtensions() in 2.1.
SUBSECTION: XML syntax
CH> A user could actually nominate http://java.sun.com/jsf/html as the
CH> namespace without a prefix and prefix the html tags--don't know if
CH> that's attractive to anyone.
Yes, they could, but I've not seen any books or articles that do it that
way. I assert that you can't have a proper XML Faces view without having
exactly one of the following
1. some kind of root element on which namespaces are declared
2. doing what Cay suggests and just have "html" as the root element, but
have it be the new html renderer that handles the "html" element
rendering.
3. saying that your view is actually an XHTML view, in which case you
have <html> as the root element with the XHTML namespace as the
non-prefixed namespace.
SECTION: [658-PartialViewContextAPI]
I don't think this fits in the changelog, so we have to move it to 2.2
SECTION: [893-UIRepeat:begin:end]
SECTION: [888-ConversionModel]
SECTION: [754-cc:attributes]
SECTION: [884,885,886,887-ResourceHandling]
Handle in 2.2.
SECTION: [696-SUPPRESS_XML_DECL]
Blake really wants it out. I still think it's useful. I'll give in to
Blake in this one and remove it. The way to suppress the XML DECL will
be to use <facelets-processing>, though you'll have to also accept the
other set of options as specified in Appendix A, Table 1-1.
SECTION: [UIData transient] [6] [7]
Summary: I am going to take Andy's first patch from [7] as the basis of
the spec work.
AS> However, while reviewing the 20101013 API doc for UIComponent, I see
AS> that access to these transient properties from "outside" of the
AS> component instance is no longer possible. There are no public
AS> get/putTransient() methods on UIComponent.
AS> getTransientStateHelper() is protected. This means that
AS> arbitrary external access to transient properties is not
AS> supported. Is this by design?
AS> Also, looking at TransientStateHelper, I see that the property keys
AS> are declared as Serializable. However, isn't the point that
AS> these transient properties are per-request and will not be state
AS> saved? Who is serializing this data? Unless I am missing
AS> some reason why this transient data is being serialized, we should
AS> change the type of the property key to Object.
AS> Another thought... The TransientStateHelper extends
AS> StateHelper. Is this necessary? I would prefer to be
AS> able to provide an implementation of TransientStateHelper (eg. in
AS> Trinidad's UIXComponentBase) without also having to implement the
AS> very extensive StateHelper contract. Can we separate these two?
AS> BTW, if we consider adding back the public get/putTransient()
AS> methods on UIComponent as Leonardo proposed originally, I kind of
AS> wonder whether we actually need a public TransientStateHelper
AS> contract at all. The details of transient state storage could
AS> be handled internally.
MM> I agree with the points:
MM> - get/putTransient should be on UIComponent, or TransientStateHelper
MM> needs to be exposed
I strongly feel we shoul expose TransientStateHelper, not put these
methods on UIComponent.
MM> - no Serializable keys are necessary
MM> But - I am not sure about removing the TransientStateHelper
MM> contract... It doesn't need to extend from StateHelper, that is true
MM> - but won't the code look funny if state-saved property handling
MM> looks different from transient property handling?
Andy's definitive patch is at [7]. Both Andy and Blake favor this patch
because it does not introduce a top-level TransientStateHelper
interface.
MM> What I would do:
MM> Double getCalculatedWeight() {
MM> return (Double) getTransientStateHelper().get(PropertyKeys.weight, false);
MM> }
MM> void setCalculatedWeight(Double weight) {
MM> getTransientStateHelper().put(PropertyKeys.weight, weight);
MM> }
MM>
MM> Could TransientStateHelper not be an alternative implementation of the
MM> StateHelper interface?
This is completely analogous to the original design with StateHelper().
So, in addition to Martin's assertion about the API design, it is
consistent with our existing patterns.
I'm not convinced {get/put}Transient is better. If you're going to
quibble with that, why not quibble with getStateHelper() as well?
AS> I don't see how adding a new TransientStateHelper contract improves
AS> this situation. That's not to say that we cannot do this. The
AS> first patch that I provided leaves TransientStateHelper in place.
AS> Just seems like added conceptual overhead that might not be
AS> necessary.
AS> 1. Components storing transient attributes on themselves.
AS> 2. External classes storing transient attributes on components.
The existing StateHelper only addresses 1. Is it ok to allow transient
state to be accessed for case 2 without doing the same for non-transient
state?
B> Since we can always add the TransientStateHelper later if we need it,
B> we shouldn't have it in the specification for this release.
As an author, I find it easier to explain the difference between
transient and non-transient state using the current APIs. If one was to
use getStateHelper() and the other to use direct methods on UIComponent,
it would be harder to explain.
MM> my concern that stateful and transient component getters/setters look
MM> different is not relevant to you?
MM> I am just thinking that users might be confused.
Yes. I agree.
MM> yes - or we just make the getTransientStateHelper() a public method.
MM> Both is possible
SECTION: [537-PrePostValidateEvent]
SPEC> When an instance of this event is passed to
SPEC> SystemEventListener.processEvent(javax.faces.event.SystemEvent) or
SPEC> ComponentSystemEventListener.processEvent(
SPEC> the listener implementation may assume that the source of this
SPEC> event instance is the UIComponent instance that is that has just
SPEC> been validated.
SPEC> Note that iterating components such as UIData, and form components
SPEC> such as UIForm must publish this event after processing their
SPEC> children nodes in
SPEC> UIComponent.processValidators(javax.faces.context.FacesContext).
AS> Does this mean that only input, UIData and UIForm components will
AS> deliver these events?
No, it does not mean that *only* those components will deliver those
events. It means that in the case of components who are iterating
components, the event must be published before, or after, the child
component processing. This is true for any components that have
children. I will revise the documentation to be as follows.
PostValidateEvent
Components with children must publish this event after processing their
child nodes in processValidators. This is especially important for
iterating components such as UIData and form components, such as UIForm.
PreValidateEvent
Components with children must publish this before after processing their
child nodes in processValidators. This is especially important for
iterating components such as UIData and form components, such as UIForm.
SECTION: [853-cc:clientBehavior]
DG> I don't see this in the 2.1 spec. I'd be happy to write
DG> something.
As mentioned in another message, I have committed this.
[1] http://lists.jboss.org/pipermail/jsr-314-open-mirror/2010-October/000410....
[2] http://lists.jboss.org/pipermail/jsr-314-open-mirror/2010-October/000412....
[6] http://lists.jboss.org/pipermail/jsr-314-open-mirror/2010-October/000469....
[7] http://lists.jboss.org/pipermail/jsr-314-open-mirror/2010-October/000491....
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 12 work days until German Oracle User's Group Conference
13 years, 6 months
Re: [jsr-314-open-mirror] [jsr-314-open] [490-XmlViews] Chapter 11: The JSF XML View Syntax
by Ed Burns
>>>>> On Tue, 26 Oct 2010 18:04:39 -0400, Andy Schwartz <andy.schwartz(a)oracle.com> said:
EB> Ok, here's what we'll do for JSF XML syntax.
EB> <f:view xmlns="http://www.w3.org/1999/xhtml"
EB> xmlns:f="http://java.sun.com/jsf/core"
EB> xmlns:h="http://java.sun.com/jsf/html">
EB> <html>
EB> <h:head><h:title>Title</h:title></h:head>
EB> <h:body>
EB> <h2>HTML elements ok</h2>
EB>
EB> </h:body>
EB> </html>
EB> </f:view>
EB>
AS> While this is fine for cases where the page author wants to manually
AS> insert an <f:view> tag, I still think that the fact that Facelets does
AS> not require this is a nice perk. We shouldn't take this shortcut away
AS> from folks who happen to want to use the new XML-style syntax.
AS> Is there some reason why it wouldn't be sufficient to hang XML namespace
AS> declarations off of the <html> element, eg:
AS> <html xmlns="http://www.w3.org/1999/xhtml"
AS> xmlns:f="http://java.sun.com/jsf/core"
AS> xmlns:h="http://java.sun.com/jsf/html">
AS> <h:head><h:title>Title</h:title></h:head>
AS> <h:body>
AS> <h2>HTML elements ok</h2>
AS> </h:body>
AS> </html>
AS> As such I don't believe that we need to add yet another element.
This is fine and valid too. However, I feel that if your root element
is <html> then you should be calling your page XHTML, not XML. In any
case, what you have written above is certainly valid for a .view.xml
file or .xhtml file.
EB> Ok, agreed. It's <f:view> If you want to do Facelets XHTML, then you
EB> just put your stuff on the root <html> element.
AS> Why force folks to add an <f:view> in XML processing mode if we don't
AS> have to? Seems like a step backwards to me. (Am I missing some
AS> requirement that is driving this?)
You don't have to add it.
AS> BTW, one thing that I am not totally clear on... What value does
AS> <h:html> add over plain old <html>?
EB>
EB> It's a resource target, in addition to rendering the <html> element.
EB>
AS> Did we add a new resource target type? Our head/body/form targets were
AS> already covered by the <h:head>, <h:body> and <h:form> components.
The "resource target type" you refer to was always just a loose and
arbitrary string that is equivalent to the QNAME of the element. In
that sense, we did add a new resource target type. See the renderkit
docs for javax.faces.Output javax.faces.Html
EB> Yes, I read Dan's initial comments but decided to go with the minimal
EB> set you have seen in the design thus far. So, I'll not be introducing
EB> <f:doctype> in this revision.
AS> Does this mean that we will not render any doctype for XML-style views?
The initial requirements for what passes through and what does not,
which went into Appendix A table 1-1, didn't say anything about DOCTYPE.
XML-wise, DOCTYPE is not a processing instruction, CDATA, or comment.
Therefore, it passes through unchanged. Do you think we need to
explicitly address doctype in Appendix A table 1-1?
Ed
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 11 work days until German Oracle User's Group Conference
13 years, 6 months
[jsr-314-open-mirror] [jsr-314-open] [755-cc:attributesSpecialKeys] (was: Re: composite:attribute "targets" property does not match with ViewDeclarationLanguage.retargetMethodExpressions)
by Ed Burns
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=755
For the record, this will not make it into JSF 2.1. Not becasue there
was feedback on it after the deadline, but because we didn't have it on
the 2.1 list to begin with.
On Friday 22 October at 18:33 EDT, Martin Marinschek wrote:
MM> Hi guys,
MM> my strong believe is that the target attribute should be immediately
MM> deprecated.
MM> It is wrongly placed where it is right now - an interface definition
MM> should never provide hooks into the implementation. It should only
MM> provide a meaningful context to which the implementation can refer.
The targets attribute is central to the entire concept of composite
components. I assert that it does not constitute a violation of the
abstraction because the targets attribute is not intended for
consumption by the page author. In fact, it is an implementation detail
that happens to reside within the <cc:interface> section.
MM> I am sorry I haven't voiced this objection before - but at the time
MM> this was discussed I was not very active on the EG, and then it was
MM> too late to talk about this.
Yes, I'll say! I recall that we talked about this in December 2007. I
know because we had the EG meeting while I was in the hotel at
JavaPolis and I remember such a unique venue.
>>>>> On Tue, 19 Oct 2010 14:30:17 -0500, Leonardo Uribe <lu4242(a)gmail.com> said:
LU> I like the way it works now. For example, tomahawk t:inputHtml
LU> component was rewritten into a composite component, and it is a good
LU> example about when it could be useful that the only requerimiento
LU> for a component to be composite is implement NamingContainer:
For what it's worth, Leonardo is happy with this way it works, provided
we address his other issues.
On Sat Oct 23 03:46:13 EDT 2010 Ganesh wrote:
G> Martin, I like your proposal on deprecating "targets". But how would
G> you then handle this case: Using a cc I nest <f:actionListener
G> "for=a" ... /> and inside the cc there is a <cc:actionSource name="a"
G> targets="b, c" /> where b and c are buttons? The logic of the "for"
G> attributes only includes this: "If present, this attribute refers to
G> the value of *one* of the exposed attached objects within the
G> composite component inside of which this tag is nested." IMO
G> deprecating "targets" would require opening "for" to refer to
G> *multiple* exposed attached objects within the composite component
G> inside of which this tag is nested just the way targets is doing this
G> right now. "targets" kind of bundles them right now.
Yes, exactly. There was a lot of back and forth between David Geary,
Ken Paulsen, Kito Mann, Andy Schwartz, and myself on this.
G> To make this more convenient omitting "for" could simply be a synonym
G> representing a "for" for *all* nested actionSources, actionSource2s
G> and CCs.
I prefer to be explicit here.
G> Please follow Jakob's proposal on adding action, actionListener,
G> valueChangeListener and validator the attributes map
G> (#{cc.attrs.action}, #{cc.attrs.actionListener},
G> #{cc.attrs.valueChangeListener}, #{cc.attrs.validator}). This is what
G> a developer would expect to happen (at least I did so) and one could
G> easily pass them on to nested components.
JK> I think we should do this a little differently:
JK> 1) try to add the e.g. ActionListener to the component specified in
JK> the targets attribute, if possible. If it is not possible, log a
JK> warning.
JK> 2) also expose the "well-known" attributes ("action",
JK> "actionListener", ...) on the composite component attribute map, this
JK> means being able to access the action attribute via #{cc.attrs.action}
JK> (currently not possible, because those attributes are not put on the
JK> attribute map).
JK> Thus the user can use the targets attribute if he/she wants to (and of
JK> course, if it is possible) and also use #{cc.attrs.action} to refer to
JK> the action attribute (like to any other attribute).
JK> Frankly I really don't understand why this was separated in the first
JK> place. Of course, the targets attribute is neat, but IMHO it is also
JK> kinda confusing. I find it a lot easier to access _every_ attribute
JK> (regardless if well-known or custom) via #{cc.attrs.attributeName}.
JK> Furthermore using this approach you can support nesting normal
JK> components and also nesting composite components.
JK> In addition the targets attribute can't solve a scenario in which the
JK> action attribute of the inner component is required (most likely the
JK> attribute from a composite component), because you need to enter a
JK> value for the attribute, but you currently can't use
JK> #{cc.attrs.action}, because this one points "nowhere".
I'd like to see a prototype of this. Can anyone step up?
Ed
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 12 work days until German Oracle User's Group Conference
13 years, 6 months