[jsr-314-open] Metadata complete jar files
by Andy Schwartz
Gang -
Section 11.5.1 of the spec defines the following annotation scanning
behavior:
> Requirements for scanning of classes for annotations
> * If the <faces-config> element in the WEB-INF/faces-config.xml file
> contains metadata-complete attribute whose value is “true”, the
> implementation must not perform annotation scanning on any classes
> except for those classes provided by the implementation itself.
> Otherwise, continue as follows.
> * If the runtime discovers a conflict between an entry in the
> Application Configuration Resources and an annotation, the entry in
> the Application Configuration Resources takes precedence.
> * All classes in WEB-INF/classes must be scanned.
> * For every jar in the application's WEB-INF/lib directory, if the jar
> contains a “META-INF/faces-config.xml” file or a file that matches the
> regular expression “.*\.faces-config.xml” (even an empty one), all
> classes in that jar must be scanned.
Since application developers have the ability to disable annotation
scanning at a global level, this means that any component set that wants
to support this mode would need to provide a metadata complete
faces-config.xml file. I don't think this is a hardship for most
component vendors, since presumably component vendors are going to want
to provide design-time metadata (eg. JSR-276 metadata), which, for the
moment, requires a faces-config.xml file anyway.
A question that came up here is whether we can tweak section 11.5.1 to
accommodate metadata complete jar files. That is, can we specify that
any jar that contains a faces-config.xml with a metadata-complete="true"
attribute would not be scanned? This would allow component vendors to
indicate that their jar files are metadata complete, and thus avoid the
cost of annotation scanning for the contents of the jar.
Note that while the annotation scan is typically a one time hit (during
application startup), design-time tools may end up starting/stopping JSF
repeatedly during the development process. Thus, avoiding unnecessary
scanning should provide for a more efficient development experience.
Any thoughts on whether we could/should make this change? Does anyone
know of reasons why we avoided specifying this originally?
Also - if we agree to make this change, is this small enough that we
could get this into the the next MR?
Andy
13 years, 8 months
[jsr-314-open] ADMIN: Final list of issues for JSF 2.0 and actions for each
by Ed Burns
This is the final list of issues for JSF 2.0. No other issues will be
considered for 2.0.
I do not think content of any of these issues, nor their quantity,
warrant another Proposed Final Draft, but I will of course produce an
Editor's Draft for the public on jsr-314-open to review.
I will send another email with the dates for the remainder of JSR-314.
Any further discussion on any topic sent to this list will be rolled
into the next release of the spec.
SECTION: List of EG Members from whom I have obtained explicit buy-in
I have obtained explicit buy in for this list in its present state from
the following EG members.
Pete Muir Status: DONE, but need final official answer from JBoss. Promised by 1800 EDT 20090415.
Andy Schwartz 617 794 7974 Status: DONE Spoke with him 1319 20090415
Kito Mann 917 848 3359 Status: DONE Spoke with him 1600 20090415
Martin Marinschek +43 699 1805 3906 Status: DONE Spoke with him at 1400 EDT 20090415
Ken Paulsen x42083 Status DONE Spoke with him 1403 20090415
Alexandr Smirnov DONE IRC chat with him 16:00 20090415
SECTION: Issue sums
Number of issues remaining: 30
I've broken down the issues into two groups, bigger and smaller. I
assert that we do not need to do a PFD2 because none of the issues are
so big as to warrant such an action.
Bigger issues:
Number of bigger issues: 16
deferred: 5
will fix: 10
pushed to EG member requesting the issue: 1
Smaller issues:
Number of smaller issues: 14
deferred: 1
will fix: 13
SECTION: Bigger issues
PM> ISSUE: 1) Fully stateless views. This is a performance optimization
PM> which is ideal for the use case of pages which are output-only (no
PM> form). This is moderately complex to get right, and a blocker in our
PM> opinion. This also has the support of Apache.
We see two aspects to consider.
a. Marking specific views in an app as stateless. Putting a
transient="true" attribute on <f:view> doesn't work here because the
template page with <f:view> can be shared across pages.
There are several options we could try but none of them are feasible at
this point in time.
b. If the Form Renderer never calls StateManager.writeState(), and the
ViewHandler is aware of this fact, then you have a stateless view.
Therefore, statelessness is an implementation detail. Adam Winer
provided this idea, which we implement in Mojarra.
ACTION: Defer to a later release.
EB> Pete agrees to defer, but Gavin does not.
EB> Andy agrees to defer.
EB> Ken agrees to defer.
EB> Martin agrees to defer.
EB> Kito agrees to defer
EB> Alexandr, agrees to defer, but is unhappy about it.
PM> ISSUE: 3) Better handling of whitespace in facelets. Currently
PM> whitespace in view sources can get "eaten" and you have to resort to
PM> tricks like to add space. I would put this as a critical and
PM> the (spec) complexity as low (simply switch it on/off).
ACTION: Defer to a later release.
EB> Pete says, "70 - yes, defering that is fine"
EB> Andy is ok for deferring this
EB> Ken is ok to defer.
EB> Martin agrees to defer. Not a spec issue.
EB> Kito agrees to defer.
EB> Alexandr, agrees to defer
PM> ISSUE: 2) First class support for page actions. This allows a more
PM> action orientated approach (Struts style) approach to page
PM> authoring, where some arbirtrary method can be run when the page is
PM> accessed. Use cases include security (redirect to another page if
PM> the user isn't logged in for example). JSF2 currently includes
PM> "second class" support - it's possible to do this stuff, but not in
PM> simple fashion. As the design for this has already been done, and
PM> reviewed/approved by the EG, the complexity is low. I would put this
PM> as a blocker. It also has the support of Oracle.
Pete, when we had the discussion regarding View Parameters, we decided
to defer Page Actions to a later release. We will not reverse that
decision.
ACTION: Defer to a later release.
EB> Pete says "I am happy for this to slip, given you can do a
EB> workaround with events. l know Dan is unhappy with the current
EB> state. On this one, Gavin was wavering, and would probably be happy
EB> to slip it".
EB> Andy can accept deferral for this
EB> Ken says, "Events should be able to accommodate this use case until
EB> we have a chance to improve the user-experience in a later release.
EB> I think we should defer this.
EB> Martin says ok to defer. But Ed and Martin agree that we should
EB> have a {Pre,Post}BuildViewEvent that is published appropriately.
EB> Kito agrees to defer.
EB> Alexandr, agrees to defer
PM> ISSUE: 5) make behaviour of new components more consistent -
PM> currently f:validateBean (JSR-303 support) / f:ajax use different
PM> strategies to mark areas of the areas of the page to enable. Align
PM> these. This is a blocker (once it is written in stone we can't go
PM> back and fix it) and complexity low (the EG has agreed on the
PM> correct design, so the language needs tweaking in the spec and
PM> javadoc). This has the support of Oracle.
ACTION: If the EG agrees that the default validator setup currently hard
coded into UIInput.encodeEnd() can be moved into
Application.createComponent(), this can be done.
EB> Pete agrees with the plan on this.
EB> Andy agrees with the plan on this.
EB> Ken agrees with the plan on this.
EB> Martin agrees with the plan on this.
EB> Kito agrees with the plan on this.
EB> Alexandr agrees with the plan, but thinks the tag handler is a
EB> better place to imbue the component with the default validator.
PM> ISSUE: 7) Allow multiple error messages for a component to be
PM> displayed - especially useful for JSR-303 support. This is
PM> complexity low, and priority minor (easy for an addon to fix).
ACTION: Pete, please submit a diff patch modifying the following files:
standard-html-renderkit-base.xml jsf-api/doc/standard-html-renderkit-base.xml
message-message-props.xml jsf-api/doc/message-message-props.xml
to specify the change, and the necessary implementation changes for this
feature.
For to the patch to be accepted at this VERY late date it must meet the
following requirements. Because of the late timing of this feature
request we will be unable to accept the feature if the patch doesn't
meet all of the following requirements.
* All existing automated tests still run successfully after applying the patch.
* The spec wording in the patch requires no grammatical or formatting
changes.
* The patch is sent to the EG list no later than 23:59 EDT Wednesday
20090415.
RL> ISSUE: 2. View ID Derivation Fix
RL> (java.net Issue 1002)
RL> Status: Ed had a fix - push back from Ken Paulsen on the fix;
ACTION: Because this breaks the V3 Admin GUI, it must be fixed for 2.0
=> edburns fix by Thursday 20090316 17:00 EDT.
RL> ISSUE: 3. Client Behavior in Composite Components
RL> (patch from Exadel)
RL> Status: Patch 1 checked in; Patch 2 checked in;
RL> Javadocs / prose updates need to be made.
ACTION: Fix checked in to revision 6952, will review spec implications
RL> ISSUE: 4. Bean Validation Bug Fixes
RL> (java.net issue 1058)
RL> Status: Checked in; Needs discussion; Javadocs, prose updates
ACTION: Will review docs, RELEASE_PENDING. Make sure spec for
CompositeComponent Attributes ELResolver mentions this, 5.6.2.2
JD> ISSUE: Impl 1071: UIData.visitTree()
ACTION: Will Fix. fully specify
JD> ISSUE: Impl 1072: Facelet Meta* Javadocs not cleanroom implementable
ACTION: Will fix.
EG> ISSUE: JavaScript disabled support [Was: Outcome of JSFDays
EG> discussions]
ACTION: This can easily be doable in a later release. Considering the
late date of this request we need to defer it.
EB> Pete is ok with deferring this.
EB> Andy is ok with deferring this.
EB> Ken is ok to defer.
EB> Martin is ok with defer
EB> Kito agrees to defer.
EB> Alexandr agrees to defer.
EG> ISSUE: minor feature enhancement for Facelets/VDL
ACTION: Defer to a later release
EB> Pete's ok with deferring this.
EB> Andy's ok with deferring this.
EB> Ken is ok to defer.
EB> Martin ok to defer.
EB> Kito ok to defer.
EB> Alexandr is ok to defer.
EG> ISSUE: required attributes in composite components
ACTION: Defer to a later release
EB> Pete's ok with deferring this.
EB> Andy's ok with deferring this.
EB> Ken is ok to defer this.
EB> Martin is ok to defer this.
EB> Kito ok to defer this.
EB> Alexandr, agrees to defer
EG> ISSUE: remove target attr from h:outputStylesheet (was:
EG> h:outputStylesheetdocs need to be updated)
ACTION: Will fix this
EG> ISSUE: #{compositeComponent.attrs....} verbosity
ACTION: Change "compositeComponent" to be "cc". Implementations may
provide a context-param that allows renaming the implicit object name to
an arbitrary value for the case where an app happens to have a
managed-bean named cc.
EB> Pete says he won't object to this solution.
EB> Andy is ok with this action
EB> Ken says, "I like 'cc' better to solve the verbosity issue. I
EB> recommend deferring on the renaming via context-param for now -- but
EB> would not object to it making the release if others feel strongly
EB> that it needs to be done now."
EB> Martin is ok with this solution.
EB> Kito is ok with this solution.
EB> Alexandr is ok to defer.
EG> ISSUE: composite insert children
ACTION: 2 days. Take the following steps
EB> Pete is ok with this action.
EB> Andy is ok with this action.
Ken says,
KP> I am very nervous about the reparenting (insert*) commands. If 2
KP> composite:insertFacet/Children tags are used in the same composite
KP> component, it will likely fail. Is that acceptable?
EB> We will specify that if multiple <composite:insertFacet> elements
EB> exist with the same name in the <composite:implementation> section,
EB> the "last one wins".
EB> We will specify that if multiple <composite:insertChildren> elements
EB> exist in the <composite:implementation> section the facelet layer
EB> must throw a FaceletException.
KP> If the component inserted has code which does: getParent(), they'll
KP> be exposed to the internal workings of a composite component (which
KP> they shouldn't know exists).
Yes, you are correct, but I feel this is sufficiently corner case to
ignore.
KP> I would prefer render* in most cases. In cases where this isn't
KP> possible (implementing a facet inside a composite component),
KP> perhaps we can do a proxy component which can be added to the inner
KP> facet and delegate rendering to the page-facet? I think there will
KP> be problems with this implementation. If I am wrong, then I do not
KP> object to this going in -- otherwise, I think it should be deferred.
EB> Martin is ok with this action.
EB> Alexandr is ok with this action.
1. rename composite:insertFacet to composite:renderFacet
2. create composite:insertFacet that reparents the named facet from the
top level component to be a facet child of the parent tag in the
composite:implementation section in which the composite:insertFacet
resides.
3. delete composite:renderUsingPageChildren
4. create composite:insertChildren that reparents the children from the
top level component to the parent of tag in the composite:implementation
section in which the composite:insertChildren resides.
5. For composite:insert{Facet,Children} support nested composite
components.
=> edburns take this to Bill and see what he thinks, if we need to do a
PFD2.
SECTION: Smaller issues
PM> ISSUE: 6) Better support for timezones. Currently only one of two
PM> timezones can be used - default or system. The user may well be in
PM> some other timezone entirely, so make the timezone used
PM> configurable. This is a critical issue, and the complexity is medium
PM> (but we have a full proposal for this waiting in the wings that
PM> didn't make it due to time constraints)
If this was a truly critical issue, it would have been brought up a long
time ago, not after the PFD has been published. Furthermore, this is a
platform level thing. I direct you to your JSR-316 EG rep for this feature.
ACTION: Defer to later release.
EB> Pete is ok with deferring this.
EB> Andy is ok with deferring this.
EB> Ken says defer.
EB> Martin ok to defer.
EB> Kito ok to defer.
EB> Alexandr is ok to defer
RL> ISSUE: 2. 11.4.7 - Absolute ordering. I think if a document name
RL> is explicitly referenced but not present, an exception should be
RL> thrown.
ACTION: We'll log a message in this case.
EB> Pete's ok with this action.
EB> Andy's ok with this action.
EB> Ken's ok with this action.
EB> Martin is ok with this action.
EB> Kito is ok with this action
EB> Alexandr states, "if related document was not present, it is
critical error, therefore Exception should be thrown." Given the
prevailing opinion, we'll stick with logging.
RL> ISSUE: 3. FacesRenderKit annotation hasn't existed from some time
RL> now.
ACTION: Remove this from the spec.
RL> ISSUE: 4. Javadocs for EditableValueHolder.addValidator() and
RL> ValueHolder.setConverter() mention ResourceDependency annotation
RL> processing. This documentation should be moved to
RL> Application.createConverter() and Application.createValidator().
ACTION: Will fix this in the spec.
RL> ISSUE: 5. 3.1.11 mentions that the AttributesMap, if the current
RL> component is composite, must eval any ValueExpressions stored in the
RL> Map. This is incorrect. This logic is handled by the
RL> CompositeComponentAttributesELResolver
ACTION: Will fix in the spec.
RL> ISSUE: 6. Preface references META-INF/managed-beans.xml. Support
RL> for this file is no longer required.
ACTION: Will fix.
RL> ISSUE: 7. 5.6.2.2 Doesn't mention any support for the special
RL> parent keyword in #{compositeComponent} expressions.
ACTION: Will fix.
RL> ISSUE: 8. 6.1.1.15 lists Flash as a property of FacesContext. It's
RL> now a property of ExternalContext.
ACTION: Will fix.
RL> ISSUE: 9. 7.1.1 and 7.1.2 Typo in assertion marker
RL> 'defualtActionListener' and 'defualtRenderKit' There may be others.
ACTION: Will fix
RL> ISSUE: 10. 7.4.2 will need to be discussed due to the
RL> implementation of issue 1066.
ACTION: Will fix
RL> ISSUE: 11. 7.4.3 should include a navigation case example with
RL> redirect parameters.
ACTION: Will fix
RL> ISSUE: 7.5.1 and others. This may already be done, but
RL> PageDeclarationLanguage should be ViewDeclarationLanguage
ACTION: Will fix. Make sure retargetAttachedObjects and retargetMethodExpressions are on VDL, not ViewHandler.
RL> ISSUE: 1. Spec ResponseWriter methods: startCDATA endCDATA (java.net
RL> issue 1055) Status: impl done; method javadocs / prose need to be
RL> done;
ACTION: Will fix
EG> ISSUE: View and custom scoped eager managed beans?
ACTION: Will Fix. Add eager for session scoped managed beans
RL> Update 3rd bullet in 11.5.1 so that pattern for custom faces config file
names is something that ends with .faces-config.xml. This brings it in
alignment with 11.4.
--
14 years, 6 months
[jsr-314-open-mirror] [jsr-314-open] Fix UIData state saving model (issue 153)
by Leonardo Uribe
In short, this topic is an attempt to add full state to components inside
UIData. I'll do a brief resume, so people can understand this one easily.
UIData uses the same component instances to render multiple rows. Suppose
this example:
<h:dataTable id="cities" var="city" value="#{country.cities}">
<h:column>
<h:outputText value="#{city}" />
</h:column>
</h:dataTable>
In the component tree it is created this hierarchy:
HtmlDatatable
UIColumn
HtmlOutputText
If we have 10 cities, the same component is used over and over to render all
10 cities. The reason to do that in this way is keep state as small as
possible.
Now let's suppose something like this:
<h:dataTable id="cities" var="city" value="#{country.cities}">
<h:column>
<h:inputText value="#{city}" />
</h:column>
</h:dataTable>
It was changed the output component for an input one. If this table is in a
form and the values are submitted, the same component is used to apply
request values, validate and apply them to the model (update process). To
make this possible, UIData class has some code to preserve this values
between phases (using EditableValueHolder interface), so when each phase is
processed, all rows are traversed and you get the expected behavior.
Now suppose something more complex: We have a code that use
invokeOnComponent to change the style of my inputText. In theory, only one
row should change. But in fact, all rows are rendered with the same color.
Why? because we use the same component to render all rows, and we don't
preserve the children component state between rows.
There is a lot of issues, questions, and side effects related to this issue,
but just to put some of them here:
TOMAHAWK-1062 InputTextArea doesn't work properly inside facet DetailStamp
TOMAHAWK-96 Data table Scroller not working the dataTable which was actually
contained in other DataTable
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=1...
with UIData state saving
Also, it is well know that one reason why people uses c:forEach in facelets,
is because this one create "full" components per each row. It is very easy
to find articles on internet.
Now, with jsf 2.0 we have partial state saving, so we have a chance to fix
this one once and for all. I tried fix this one per months (maybe years!),
but talking with Martin Marinschek on JSFDays, some ideas came out and
finally it was found a possibility to fix this one using the existing api
and with little changes on the spec.
The proposal is this:
1. Do not call UIComponent.markInitialState() on
ComponentTagHandlerDelegate, as ComponentHandler javadoc says, instead call
it after PostAddToViewEvent are published on vdl.buildView(). We need to
call it from root to nodes, so the parent component is marked first. I know
the place where this call comes is from trinidad tag handler, but this call
needs to be fixed in a more predictable way.
2. Use an attribute on facesContext to identify when the VDL is marking the
initial state (in myfaces there is already an attribute called
"org.apache.myfaces.MARK_INITIAL_STATE"). This is necessary to indicate
UIData instances that it is time to save the full state of all component
children,
3. Allow UIData to hold a map where the key are client ids and the value are
the deltas of all components per row. This map should be saved and restored.
4. Change UIData.setRowIndex() to restore and save the component state.
I'll attach a patch on myfaces issue tracker with the algorithm proposed
(because it is based on myfaces codebase). It was tested and it works. But
note it is necessary to fix the javadoc for UIData.markInitialState(),
ComponentHandler and maybe vdl.buildView(), so the intention is propose this
change for jsf 2.0 rev A. Note this works only with PSS enabled because
without it we don't have a place to notify UIData instances that it is
necessary to get the full state. Also, note this patch preserve backward
compatibility, because the old way to store/save is applied after the full
state is restored.
Really, I have the strong temptation to apply some similar code on myfaces
UIRepeat component (because this class is private), but I prefer first ask
to EG to know what you guys think about it.
Suggestions are welcome,
regards,
Leonardo Uribe
14 years, 7 months
Re: [jsr-314-open-mirror] [jsr-314-open] f:selectItems value="#{myMap}" underspecified
by Martin Marinschek
Hi Leonardo,
> Map - The keys of this object (once converted to Strings) are assumed to be
> labels, and the values of this object (once converted to Strings) are
> assumed to
> be values, of SelectItem instances that will be constructed dynamically and
> added to the set of available options for the parent component, in the order
> provided by an iterator over the keys.
I never understood why the labels should be the key here - it should
really be the other way round, and the value should be the key. I
thought that was sorted for 1.2 - it is not?
> This behavior comes from jsf 1.1, but in jsf 2.0 it was added some new
> attributes (from f:selectItems tlddoc):
>
> Version 2 of the specification introduces several new attributes, described
> below. These are: var, itemValue, itemLabel, itemDescription, itemDisabled,
> and
> itemLabelEscaped.
>
> Now, what happen if some user do something like this:
>
> <f:selectItems value="#{myMap}" var="item"
> itemLabel="#{item.value.someLabelProperty}" itemValue="#{item.value}">
>
> It just does not work, because there is no clear definition about what
> should
> f:selectItems do in this case.
>
> The proposal for solve this one is if var property is set and value
> implements
> Map interface, use the entry object as var, so the user can choose between
> the
> key and some attribute on the item value.
I totally agree - +1 from me.
best regards,
Martin
14 years, 7 months
Re: [jsr-314-open-mirror] [jsr-314-open] Use a Renderer on a composite component
by Ed Burns
>>>>> On Sun, 28 Mar 2010 21:21:10 -0500, Leonardo Uribe <lu4242(a)gmail.com> said:
LU> The problem is why it is mandatory to set "javax.faces.Composite" as
LU> renderer type. The javadoc should say:
LU> "...If the renderer type is not set (return null), Call
LU> UIComponent.setRendererType(java.lang.String)<file:///D:/jdk-1_5_0-doc/jsf20/mojarra-2.0.3-SNAPSHOT/docs/javadocs/javax/faces/component/UIComponent.html#setRendererType%28java.lang.String%29>on
LU> the
LU> UIComponent instance, passing "javax.faces.Composite" as the argument...".
LU> In that case, a user can override the rendererType on the constructor and
LU> avoid this hack that works with the current spec:
I understand the problem you have uncovered. Take a look at the
renderkit docs for javax.faces.NamingContainer/javax.faces.Composite.
There are specific requirements in there that depend on the composite
component metadata specification.
I thought it would be toooooooo subtle to allow the Renderer to be
customized beause this contract must also be followed in the custom
renderer case.
LU> Why override the default Renderer and use a custom one? Let's
LU> suppose the component proposed needs some custom code for converter,
LU> or for decode. The right place to put that kind of code is the
LU> Renderer class, not the component, but note it is possible to put
LU> that on the component class.
Yes I understand that the Renderer is the right place for such things
but the chosen programming model for customization of composite
components is to override the top level component. Simple. If we're
going to change that I need a more compelling reason than correctness.
Ed
--
| edward.burns(a)oracle.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 7 months
[jsr-314-open-mirror] [jsr-314-open] Fwd: State saving of UIViewParameter
by Matthias Wessendorf
Since MyFaces committer "Jakob Korherr" has only read-access to this
list, I am forwarding this mail.
-Matthias
PS: we use this forwarding "work-around" instead of filing issues
against the spec (for discussions).
---------- Forwarded message ----------
From: Jakob Korherr <jakob.korherr(a)gmail.com>
Date: Thu, Apr 8, 2010 at 2:46 PM
Subject: State saving of UIViewParameter
To: Matthias Wessendorf <mwessendorf(a)gmail.com>
Hi,
Yesterday we received an issue about the state saving of an
UIViewParameter in combination with an AJAX request on the MyFaces
user list (see [1] for details). This opened some questions/problems:
UIViewParameter uses the submittedValue to store its value in the
state for the next postback, because obviously the view parameter
won't be in the request parameter map of the next request (which is
the postback). But because its submittedValue is null after the
conversions and validations, it has to be set again before the state
is generated. To accomplish that, the spec currently states to
override encodeAll() and make the call to setSubmittedValue() there.
In addition, encodeAll() has to be called in UIViewRoot.encodeEnd()
for every UIViewParameter in the view. This works perfectly for normal
requests, but when you are using an AJAX request the state is
generated before UIViewRoot.encodeEnd() is called an thus the
submittedValue for every UIViewParameter is null in the state. This
means that the value of every UIViewParameter will be null in the
following request.
Now the easiest solution to this problem, which I also already
committed to MyFaces trunk (again see [1] for details), is to do
mostly the same as in UIViewRoot.encodeEnd() just also in
PartialViewContext.
processPartial() when the PhaseId is RENDER_RESPONSE before the state
is generated to make it work for AJAX-requests.
However I don't really like this solution, because we have to think of
handling UIViewParameters in a special way every time we change
something on any render mechanism. Why don't we just override
saveState() on UIViewParameter and set the submittedValue there before
the state is saved. This will have the same result, but without the
code in UIViewRoot, PartialViewContext and UIViewParameter.encodeAll()
and without future headaches. I also already uploaded a patch for this
to the MyFaces issue at [1].
The second thing I want to bring up here is an issue I ran into while
testing the first one. Imagine you have a page with a required
UIViewParameter called input. You will get a validation error as long
as you don't access the view with ?input=abc. Now if you do that once,
"abc" will be saved as the submittedValue in the state of the
UIViewParameter for every postback and thus will be available for
every further postback. If you now access the view again with a GET
request (non-postback), but without ?input=abc, you will again get a
validation error. However, if you hit any button or link on the view
to generate another postback to the view, the validation error will be
gone, because UIViewParameter takes the value from before ("abc") out
of the model (managed-bean) and sets it in the state. Thus you haven't
provided it via ?input=abc, but you will now have a value of "abc" for
your UIViewParameter, which seems kinda wrong to me. The solution to
this one is to get the value from the model to set it as the
submittedValue in UIViewParameter only if the current request is a
postback. However I don't know if this really is an error or the
expected behaviour. I personally just think that it is weird.
Many thanks for looking at this!
Regards,
Jakob
[1] https://issues.apache.org/jira/browse/MYFACES-2645
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
14 years, 7 months
[jsr-314-open-mirror] [jsr-314-open] question regarding ajax update cycle
by Werner Punz
Hello everyone, I ran into an issue regarding the update, which is closely
related to a behavior jsf2 exposes regarding component rendering
in the update cycle.
The main issue is following: If we have a component which we trigger with
following code:
<myComp:javascriptTestComponent
id="myTestComponent"></grv:javascriptTestComponent>
<a href="#" name="mego3"
onclick="jsf.ajax.request(this,event,{execute:'myTestComponent',
render:'myTestComponent'}); return false;">submit
me</a>
and the component itself renders following in its renderer:
ResponseWriter writer = context.getResponseWriter();
writer.startElement(DIV, component);
writer.writeAttribute(ID,component.getClientId(context), null );
writer.write("hello world"+Math.random());
writer.endElement(DIV);
writer = context.getResponseWriter();
writer.startElement(DIV, component);
writer.writeAttribute(ID,component.getClientId(context)+":_second",
null );
writer.write("hello world"+Math.random());
writer.endElement(DIV);
the resulting ppr response now looks like following:
<update id="myTestComponent">
<![CDATA[<div id="myTestComponent">hello world0.8619488403376933</div>
<div id="myTestComponent:_second">hello world0.25176272071402683</div>]]>
</update>...
Now the problem is, since the update part of the response is already opened
the component author cannot really influence the response rendering in any
meaningful way (the correct solution would be to issue two update commands
here)
Now the javascript has to react on the client side to resolve that
situation.
Now MyFaces just replaced the original
myTestComponent
with the update code and hence the result was a div wandering down (aka
wrong update)
hello world0.48748236239247755
hello world0.6020541783857698
hello world0.7181842402648805
hello world0.2803064696069696
(after a handful of requests, with the lowest line being the first second
div being dran)
now due to being incorrect a user gave me rightfully a bug issue. I dug
deeper and ran the same example
against Mojarra, now Mojarra does cherry pick the delivered first div and
replaces the original div, and omits the second one.
The Problem is Mojarra just does it for newer browsers, it does the same
just updating the original element with the replacement code
(and hence producing a wandering div) for IE6+7-
My question is, first, how to handle that problem correctly. Secondly, is
this even a problem for us or more one for the component author?
In the end the main problem would not exist if they ajax api could be used
on the component side properly without being enforced already into an update
(or to allow nested updates, inserts within an update)
Werner
14 years, 7 months
[jsr-314-open-mirror] [jsr-314-open] Cannot call invokeOnComponent on UIColumn without rowIndex
by Leonardo Uribe
Hi
Looking some jsf 2.0 code, I notice the current algorithm of
UIData.invokeOnComponent cannot handle the case when the target is a
UIColumn instance and no rowIndex is on clientId. Is that ok?
Checking the new visit tree api, UIData.visitTree cleary says:
*"....If this component has children, for each UIColumn child:
Call VisitContext.invokeVisitCallback(javax.faces.component.UIComponent,
javax.faces.component.visit.VisitCallback) on that UIColumn instance. If
such a call returns true, terminate visiting and return true from this
method.
If the child UIColumn has facets, call
UIComponent.visitTree(javax.faces.component.visit.VisitContext,
javax.faces.component.visit.VisitCallback) on each one....."
*
I think we should do something like this:
for (Iterator<UIComponent> itChildren =
this.getChildren().iterator();
!returnValue && itChildren.hasNext();)
{
UIComponent child = itChildren.next();
if (child instanceof UIColumn &&
clientId.equals(child.getClientId()))
{
try {
callback.invokeContextCallback(context, child);
} catch (Exception e) {
throw new FacesException(e);
}
returnValue = true;
}
// process the child's facets
for (Iterator<UIComponent> itChildFacets =
child.getFacets().values().iterator();
!returnValue && itChildFacets.hasNext();)
{
//recursive call to find the component
returnValue =
itChildFacets.next().invokeOnComponent(context, clientId, callback);
}
}
Does that sounds reasonable? Should be fixed on 1.2.x branch too?
regards,
Leonardo Uribe
14 years, 8 months
[jsr-314-open-mirror] [jsr-314-open] javax.faces.view.facelets.ResourceResolver cannot be fully overriden
by Leonardo Uribe
Hi
Checking this issue on myfaces:
https://issues.apache.org/jira/browse/MYFACES-2628
It was notice there is a way to override the default ResourceResolver, used
to load facelets templates, but the algorithm related to ViewHandler (spec
pdf section 7.5.2) says that if the physical resource exists with the name
requestViewId let that value be viewId, otherwise return null. So, if some
user try to load templates from other sources, the ViewHandler just will not
work.
The problem is there is no standard way to retrieve the current
ResourceResolver object, so the ViewHandler just can't find them. In
myfaces, this one is instantiated on facelets vdl object, when it is
initialized.
One idea to solve this one could be expose this object through vdl interface
(maybe a public method called getResourceResolver()?).
Since this issue is related to other ones that requires expose facelets api
objects, I'll not create an issue on the spec jira, but if it is necessary I
can create it.
regards,
Leonardo Uribe
14 years, 8 months
[jsr-314-open-mirror] [jsr-314-open] Servlet-API dependency with resources
by Neil Griffin
Hi Guys,
While developing the portletfaces-bridge [1] I discovered a Servlet-API dependency with the way JSF 2.0 implements detection of resource requests.
Specifically, javax.faces.application.Resource.getRequestPath() [2] states that "/javax.faces.resource" [3] must be part of the return value of the path.
Now... it's true that the Javadoc for javax.faces.application.Resource.getRequestPath() [2] adds:
"Make it portlet safe by passing the result through ViewHandler.getResourceURL(javax.faces.context.FacesContext, java.lang.String)" [4]
... but this isn't good enough. To make a long story short, the Portlet 2.0 API does not provide access to the URL requested by the userAgent/browser. It only provides access to request parameters. So there is no way for a portlet bridge to examine the request path. In fact, the behavior of ExternalContext.getRequestPathInfo() [5] and ExternalContext.getRequestServletPath() [6] are undefined for portlets, because there are no equivalent methods in the javax.portlet.PortletRequest class like there is for javax.servlet.http.HttpServletRequest. So it's just not appropriate for a JSF implementation to rely on them to behave like their Servlet API counterparts.
Therefore, in order to provide compatibility with portlets, I propose that for JSF 2.1, we deprecate:
- The presence of "/javax.faces.resource/resource-name" in the path
And change it to this:
- The presence of a "javax.faces.resource" request parameter with value resource-name.
Using this method, custom implementations of ResourceHandler that are present in component-suites can add additional request parameters to help them identify themselves as a custom resource request.
Thoughts? I've got it coded up in the bridge and it seems to be working fine.
Thanks guys,
Neil
[1] http://www.portletfaces.org/projects/portletfaces-bridge
[2] https://javaserverfaces.dev.java.net/nonav/docs/2.0/javadocs/javax/faces/...
[3] https://javaserverfaces.dev.java.net/nonav/docs/2.0/javadocs/javax/faces/...
[4] https://javaserverfaces.dev.java.net/nonav/docs/2.0/javadocs/javax/faces/..., java.lang.String)
[5] https://javaserverfaces.dev.java.net/nonav/docs/2.0/javadocs/javax/faces/...
[6] https://javaserverfaces.dev.java.net/nonav/docs/2.0/javadocs/javax/faces/...
14 years, 8 months