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/
>
>