3:13 p.m.
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
4:26 p.m.
On 10/26/10 4:13 PM, Ed Burns wrote:
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.
I find this confusing. The DEFAULT_FACELETS_SUFFIX and
FACELET_VIEW_MAPPINGS parameters control which views the Facelets VDL
will handle. How does Mojarra determine that the Facelets VDL should
process .view.xml files if this mapping isn't reflected by the default
values of these context parameters?
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?
7.5.2 does not specify exactly how the deriveViewId() implementation
should check for the existence of a physical view. The wording is generic:
look for a physical resource with the name candidateViewId. If such a
resource exists, candidateViewId is the correct viewId
As of 2.1, we have introduced a new method that performs this test:
ViewDeclarationLanguage.viewExists(). 7.5.2 could add a sentence that
states that this method should be used to perform the view existence test.
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?
I need the ability to wrap one of the standard VDL implementations (the
JSP VDL implementation) in order to insert my own logic. (In my case, I
need to substitute my own VDL.viewExists() implementation). While the
VDLFactory contract provides a hook for this, I have no way to
distinguish between VDL implementations. The presence of an id lets me
to know which VDL is being returned from the VDLFactory and thus allows
me to target my wrapper to a single VDL.
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
We've got a few options here:
- <html>
- <h:html>
- <f:view>
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.
I *think* that it should be okay to just use a plain old <html> element
even when processing mode = xml. Is there a reason why we should
disallow this?
A big concern about our current XML-centric solution: at the moment we
don't seem to have any clean way to specify a doctype. And since
<h:html> doesn't render a doctype, it looks like our XML-style Facelets
pages will be doctype-less. This seems like a very serious
shortcoming. I think that we need to address this.
SECTION: [UIData transient] [6] [7]
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?
StateHelper is a helper class that is helps the component implementation
and its subclasses. The access modifier of getStateHelper() reflects
this - ie. this is a protected, not public.
With transient state, I was under the impression that we were trying to
address two use cases:
- Internal access from the component + subclasses.
- External access from arbitrary code (eg. Renderers, application logic)
The second use case raises the question of what an appropriate
external/public API might be. I find it awkward that external code
would be required to interact with a UIComponent's "helper" class.
I don't view this as quibbling. We're all just trying to find the best API.
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?
Non-transient state is already accessible via public APIs on UIComponent
(eg. getAttributes(), getValueExpression(), etc...) and its subclasses
(eg. property-specific getters/setters). The fact that UIComponent
happens to store state in a StateHelper is effectively an implementation
detail of the component.
BTW, I haven't seen any comments on the questions that I raised
regarding TransientStateHolder. Who implements this besides
UIComponent? Who interacts with this contract?
SECTION: [537-PrePostValidateEvent]
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.
Okay, though I am still a bit confused about how iterating components
are special.
As always, I also worry that the overhead of delivering these system
events through the application-level publication mechanism is going to
be a performance problem for views with large #s of components (common
case for me). I suppose time will tell.
Andy
4:40 p.m.
On the SystemEvent issue, we already know that its design causes
performance problems even when there are no listeners.
-- Blake Sullivan
On 10/26/10 2:26 PM, Andy Schwartz wrote:
On 10/26/10 4:13 PM, Ed Burns wrote:
> 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.
I find this confusing. The DEFAULT_FACELETS_SUFFIX and
FACELET_VIEW_MAPPINGS parameters control which views the Facelets VDL
will handle. How does Mojarra determine that the Facelets VDL should
process .view.xml files if this mapping isn't reflected by the default
values of these context parameters?
> 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?
7.5.2 does not specify exactly how the deriveViewId() implementation
should check for the existence of a physical view. The wording is
generic:
> look for a physical resource with the name candidateViewId. If such a
> resource exists, candidateViewId is the correct viewId
As of 2.1, we have introduced a new method that performs this test:
ViewDeclarationLanguage.viewExists(). 7.5.2 could add a sentence that
states that this method should be used to perform the view existence
test.
> 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?
I need the ability to wrap one of the standard VDL implementations
(the JSP VDL implementation) in order to insert my own logic. (In my
case, I need to substitute my own VDL.viewExists() implementation).
While the VDLFactory contract provides a hook for this, I have no way
to distinguish between VDL implementations. The presence of an id
lets me to know which VDL is being returned from the VDLFactory and
thus allows me to target my wrapper to a single VDL.
> 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
We've got a few options here:
- <html>
- <h:html>
- <f:view>
> 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.
I *think* that it should be okay to just use a plain old <html>
element even when processing mode = xml. Is there a reason why we
should disallow this?
A big concern about our current XML-centric solution: at the moment we
don't seem to have any clean way to specify a doctype. And since
<h:html> doesn't render a doctype, it looks like our XML-style
Facelets pages will be doctype-less. This seems like a very serious
shortcoming. I think that we need to address this.
> SECTION: [UIData transient] [6] [7]
> 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?
StateHelper is a helper class that is helps the component
implementation and its subclasses. The access modifier of
getStateHelper() reflects this - ie. this is a protected, not public.
With transient state, I was under the impression that we were trying
to address two use cases:
- Internal access from the component + subclasses.
- External access from arbitrary code (eg. Renderers, application logic)
The second use case raises the question of what an appropriate
external/public API might be. I find it awkward that external code
would be required to interact with a UIComponent's "helper" class.
I don't view this as quibbling. We're all just trying to find the
best API.
> 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?
Non-transient state is already accessible via public APIs on
UIComponent (eg. getAttributes(), getValueExpression(), etc...) and
its subclasses (eg. property-specific getters/setters). The fact
that UIComponent happens to store state in a StateHelper is
effectively an implementation detail of the component.
BTW, I haven't seen any comments on the questions that I raised
regarding TransientStateHolder. Who implements this besides
UIComponent? Who interacts with this contract?
> SECTION: [537-PrePostValidateEvent]
>
> 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.
>
Okay, though I am still a bit confused about how iterating components
are special.
As always, I also worry that the overhead of delivering these system
events through the application-level publication mechanism is going to
be a performance problem for views with large #s of components (common
case for me). I suppose time will tell.
Andy
5:49 p.m.
Ed,
/1. some kind of root element on which namespaces are declared
/
Why does this have to be a root element? We shouldn't care where the
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.
/
How does adding a new <h:html> tag have any advantage over having the
page author use a real <html> tag? If it doesn't, then there is no
reason to add more tags.
/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.
/
I don't understand. What do you mean by an "XHTML view"? A page that
generates XHTML content? A Facelets page that contains XHTML markup?
If it is the second of these, why do we care how and where they have
specified their namespace as long as they have valid XML?
/MM> - get/putTransient should be on UIComponent, or
TransientStateHelper
MM> needs to be exposed
I strongly feel we should expose TransientStateHelper, not put these
methods on UIComponent./
And
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?
I didn't realize that pushing back on needlessly adding public apis to a
specification criticized for being bloated, but then I'm also guilty of
commenting late so why stop now.
Is your proposal that we add getTransientStateHelper() on UIComponent
and then have the subclasses modify the state using the StateHelper
methods? Why is that better than get/setTransient()? Is the only
justification that it is similar to getStateHelper()? And, yeah, I have
several quibbles with getStateHelper().
-- Blake Sullivan
On 10/26/10 1:13 PM, Ed Burns wrote:
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....
5170
days inactive
5171
days old
jsr-314-open-mirror@lists.jboss.org
3 comments
3 participants
participants (3)
-
Andy Schwartz -
Blake Sullivan -
Ed Burns