[JAVASERVERFACES_SPEC_PUBLIC-658] PartialViewContext interoperability Created: 02/Nov/09  Updated: 12/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Ajax/JavaScript
Affects Version/s: 2.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: nick_belaevski Assignee: Unassigned
Resolution: Unresolved Votes: 9
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: All
Platform: All

Attachments: Text File jsf-spec.patch    
Issuezilla Id: 658
Status Whiteboard:

cat1 frame size_large importance_medium


Contract of PartialViewContext doesn't give enough freedom for JSF components libraries to override it
partially. Example: simple addition of "extension" element (or any other that RI's implementation doesn't
do, but component libraries may need) requires full re-implementation of PartialViewContext class, thus
making co-existence of different libraries almost impossible. If some AJAX-updated component outputs
"extension" element, then it appears inside "update" element causing malformed XML error on the client,
so this approach doesn't work.

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete api subcomponent

Comment by Ed Burns [ 04/Mar/10 ]

2.0 rev a

Comment by Ed Burns [ 15/Mar/10 ]


Comment by rogerk [ 14/May/10 ]

Just to be clear...
Are you proposing an API change on PartialViewContext?
Can you please provide a more concrete example and use case?

Comment by rogerk [ 14/May/10 ]


Comment by Ed Burns [ 15/May/10 ]

These are valid 2.0 Rev a issues

Comment by rogerk [ 17/May/10 ]

Target 2.1

Comment by nick_belaevski [ 18/May/10 ]

More concrete example can be update/insertion/deletion of component part. Let's
take filterable data table component. When user types something in filter field,
live update of table content should be happening, but we aren't going to update
the whole table, because this will cause loss of user's input focus. So,
component assigns id="#

{clientId}:tbody" to <tbody> element with the intention
to update it later by special event.

Looking at the API of PartialViewContext, how would component be doing this?
There's processPartial(PhaseId phaseId) that does the complete processing and in
Mojarra it is implemented via visiting components tree using either
PartialVisitContext or FullVisitContext. So, if we add component clientId into
renderIds, implementation will call component's encodeAll(...) method wrapping
it into <update id="#{clientId}

">...</update> element. If we don't add component
clientId, then control won't be passed to component at all. If we call
startUpdate()/endUpdate() for our <tbody> from encodeAll(...), then <update>
elements are nested and XML is not correct, causing update to fail (this has
been already discussed in jsr-314 mailing list). The same problem with any
insert/delete/extension element. Solution: do complete re-write of
PartialViewContext, but this affects interoperability in a poor way.

Proposed API change: two methods that will allow users to override creation of
VisitContext & VisitCallback for the particular phase.

Comment by sheetalv [ 10/Jun/10 ]


Comment by rogerk [ 30/Jun/10 ]


Comment by rogerk [ 26/Aug/10 ]

Nick - I need to push this to 2.2 unless you can supply the spec changes.

Comment by nick_belaevski [ 26/Oct/10 ]

Created an attachment (id=318)
Proposed patch

Comment by rogerk [ 16/Nov/10 ]


Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Generated at Mon Apr 24 05:06:37 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.