Hi,
I agree with Leonardo!
ad Q2 and Q3: we use prePhase/postPhase stuff like FlashScope to keep
consistency inside the JSF spec + we may want to let an extension
point open for custom JSF frameworks (consider e.g. ICEfaces).
ad Q4: It really feels that way, but as Neil correctly threw in: there
is no FacesServlet in a portlet environment.
Regards,
Jakob
Am 14. Februar 2012 16:52 schrieb Leonardo Uribe <lu4242_at_gmail.com>:
> Hi
>
> The proposal in MyFaces Wiki considers the possibility to use
> different algorithms do deal with windowId logic.
>
> url-Mode : just embeed window-id in the URL. For example, MyFaces
> Orchestra embeed an id to identify a window
> client-Mode : similar to the option used in MyFaces CODI. It tries to
> generate the windowId on the client side using some javascript
> portlet-Mode : in this case the portlet container deals with windowId
> logic. I know this is not included on the current scope, but think
> about it doesn't harm and help to understand how this should work.
>
> To answer the previous questions it is necessary to take into account
> how the two previous mode works:
>
> EB >> Q.2 aside from before RestoreView, what other pre-phase actions
> are required?
>
> url-Mode: Try to detect if there is a windowId, decoding the data
> available from the request. If there exists, store it for later use,
> if not let it to null or generate one, but in this case since the
> counter to generate windowIds should be stored on session, it is
> better to let it in null and use another method to force windowId
> creation (createWindowId).
>
> client-Mode: Try to detect if there is a windowId, decoding the data
> available from the request. If there exists, store it for later use.
> If not render a small page with a script that calculate a windowId on
> the client side and finalize JSF lifecycle calling
> facesContext.responseComplete. Later, a new request with the windowId
> calculated will be derived.
>
> portlet-Mode: The portlet container should deal with windowId logic
> using one of the previous algorithms internally and then append it a
> portlet identifier, so jsf portlet-brigde should have some code to
> gather the windowId from there (UIViewRoot container clientid?).
>
> EB >> Q.3 post-phase action is currently empty. What possible actions could
> EB >> there be here?
>
> The algorithms described does not have any possible action
> contemplated, just the proposal include this call if something in the
> future arise in this part and to keep symmetry in the code. For
> example, if someone wants to create a wrapper for Window object and
> implement a window scope, maybe this call could be useful to dispose
> something.
>
> EB >> Q.4 It seems like the right place to handle the creation of the windowId
> EB >> is in the FacesServlet. Why not there?
>
> EB >> I think Q.4 is the most pressing. Can someone answer me that one?
>
> In my opinion FacesServlet is just something relatet to servlet case,
> but JSF should be able to run in other environments like portlets.
>
> regards,
>
> Leonardo Uribe
>
> 2012/2/14 Neil Griffin <neil.griffin_at_portletfaces.org>:
>> Hi Ed,
>>
>> In a portlet environment, the FacesServlet is not invoked. Instead, the
>> javax.portlet.faces.Bridge [1] implementation is responsible for receiving
>> requests, running the JSF lifecycle, etc.
>>
>> I'll let others comment on the suitability of creating the windowId in the
>> FacesServlet for a servlet environment though.
>>
>> Neil
>>
>> [1]
>> http://myfaces.apache.org/portlet-bridge/2.0/api/apidocs/javax/portlet/faces/Bridge.html
>>
>> On Feb 13, 2012, at 11:33 PM, Edward Burns wrote:
>>
>> Hello Experts,
>>
>> I've been discussing this issue on ##jsf but due to timezone issues I
>> think it's best to take it asynchronous.
>>
>> My first order of business was to edit the proposal on the MYFACES wiki [1]
>> so that I could use it as a starting point for writing the spec
>> language. We made some progress with this, but it's still not where I
>> need it to be so I can just sit down and write it out.
>>
>> Here are some questions I still have after reading the proposal in its
>> current state:
>>
>> Q.2 aside from before RestoreView, what other pre-phase actions are
>> required?
>>
>> Q.3 post-phase action is currently empty. What possible actions could
>> there be here?
>>
>> Q.4 It seems like the right place to handle the creation of the windowId
>> is in the FacesServlet. Why not there?
>>
>> I think Q.4 is the most pressing. Can someone answer me that one?
>>
>> Thanks,
>>
>> Ed
>>
>> [1] https://cwiki.apache.org/confluence/display/MYFACES/WindowId+Proposal
>> --
>> | edward.burns_at_oracle.com | office: +1 407 458 0017
>> | homepage: | http://ridingthecrest.com/
>>
>>
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at