Hi guys,
why not have the same name for all view state fields in one portlet
(there can be multiple forms, hence multiple view state fields per
portlet). This name would need to include the view-root discriminator.
Javascript code could then search by name - right?
On top, we could have a real unique id per view state field - not sure
if that's then necessary.
As to why this had to be done like it is implemented now: originally,
the view was rebuilt from the state, but if the id of the view state
param was dynamic, you wouldn't know in which param the state resided.
A classic hen and egg problem ;)
Now, if the id is not dynamic, we can always build the view and then
check which param we need to check for the state.
Thinking about this more carefully - wasn't there an extension
recently that some part of the view state is already available when
building the view? Then this new approach with a dynamic name might
cause problems...
best regards,
Martin
On 2/13/12, Neil Griffin <neil.griffin_at_portletfaces.org> wrote:
> Hi Ed,
>
> I did a search in JIRA and it seemed that there were 3 semi-related issues.
> Since none of them described the full import of the problems with jsf.js and
> portlets, I created the following new issue and linked the semi-related
> issues:
> http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1069
>
> Best Regards,
>
> Neil
>
> On Feb 6, 2012, at 5:07 PM, Edward Burns wrote:
>
>> NG> But actually there is a larger issue, probably worthy of its own
>> NG> thread, but I'll mention it here. The assumption that jsf.js makes
>> [...]
>> NG> transport. Need to solve this issue in JSF 2.2 for portlet
>> NG> alignment.
>>
>> Thanks for bringing that up. Can you please search for an existing
>> isuse and bring it to us here? If you don't find one can you please
>> create one and bring it to us here?
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces