Hi Gerhard,

LAZY mode without adding ds:windowId will exactly work like URL.
But it will never have a chance to detect new windows.
We could also keep LAZY and URL, doesn't matter for me :)

The main goal of the last email to clarify what the LAZY script part should
do and that it currently has an bug.

Regards,
Thomas


2014/1/14 Gerhard Petracek <gerhard.petra...@gmail.com>

> imo we should keep one mode which works without js.
>
> regards,
> gerhard
>
>
>
> 2014/1/14 Thomas Andraschko <andraschko.tho...@gmail.com>
>
> > I think i understand know what lazy should do...
> >
> > Our windowhandler.js just checks if window.name is empty, removes the
> > windowId and redirects to the same url without a windowId.
> >
> > But we must also do another check if the mode is LAZY because it
> currently
> > don't validate the windowId.
> >
> > If you a page in a new tab ->
> > test.xhtml?windowId=1
> > it checks that the window.name is empty and redirects to
> > test.xhtml?windowId=
> >
> > The server will now redirect to:
> > text.xhtml?windowId=someNewAndValidWIndowId
> >
> > What appens now if you open this in the same tab:
> > test.xhtml?windowId=3
> >
> > nothing! #assertWindowId must also take care of this.
> > What should happen? Reload/redirect via the windowId stored in
> > window.nameor doing a redirect without windowId (assigning a new
> > windowId to the tab)?
> >
> > I would rename URL to LAZY (merge these modes) and fix this small bug
> > above.
> > Any objections?
> >
> >
> >
> >
> >
> >
> > 2014/1/13 Thomas Andraschko <andraschko.tho...@gmail.com>
> >
> > > Mark, i understand the windowhandler.html approach but i still don't
> > > understand LAZY.
> > > You said that it's the same as URL but with some JS checks.
> > > I tried to explain my thoughts about a LAZY in my last email in the
> "JSF
> > -
> > > default ClientWindowRenderMode?" thread.
> > > I really completely understand the logic for CLIENTWINDOW but it would
> be
> > > nice, if you could explain what exactly should happen on client side if
> > the
> > > LAZY mode is used.
> > >
> > > URL is just for appending the windowId to the url's without any JS -
> like
> > > the default mode in CODI.
> > > If LAZY requires JS, then it's a different mode IMO because the current
> > > windowhandling also makes the target attribute of links unusable. Isn't
> > it?
> > >
> > >
> > >
> > > 2014/1/13 Mark Struberg <strub...@yahoo.de>
> > >
> > >> LAZY is really exactly the same as you mean with 'URL'. I just like
> the
> > >> term 'LAZY' more than 'URL' as it explains much better what happens.
> > >>
> > >> Please read the very last paragraph in
> > >>
> > >> http://myfaces.apache.org/orchestra/multiwindow.html
> > >>
> > >> Afaik, this was written by Mario Ivankovic (main-brain of Orchestra)
> and
> > >> Werner Punz (_the_ JSF spec JavaScript wizzard) back in the days when
> > they
> > >> did Apache MyFaces Orchestra.
> > >>
> > >> The 100% solution is the ClientWindow mode. But this has the downside
> of
> > >> the intermediate page...
> > >>
> > >> LieGrue,
> > >> strub
> > >>
> > >>
> > >>
> > >>
> > >> > On Sunday, 12 January 2014, 22:25, Thomas Andraschko <
> > >> andraschko.tho...@gmail.com> wrote:
> > >> > > Here is my idea about the initial refactoring on the
> > windowhandler.js
> > >> >
> > >> > https://gist.github.com/tandraschko/3d2aa9d84f6469206ce7
> > >> >
> > >> > I think it will need some more refactoring/fixing when we finally
> know
> > >> what
> > >> > LAZY should do.
> > >> > But i like to structure and the single entry point via
> > >> DSWindowContext#init.
> > >> >
> > >> > Also storeEvent seems the be unused? Could anyone explain this to
> me?
> > >> >
> > >> >
> > >> >
> > >> > 2014/1/10 Gerhard Petracek <gerhard.petra...@gmail.com>
> > >> >
> > >> >>  (similar to what we have in codi) we can do a lazy restore in
> > >> addition (if
> > >> >>  it is limited to the url/lazy mode).
> > >> >>
> > >> >>  regards,
> > >> >>  gerhard
> > >> >>
> > >> >>
> > >> >>
> > >> >>  2014/1/10 Thomas Andraschko <andraschko.tho...@gmail.com>
> > >> >>
> > >> >>  > (of course it would only be required #ifPostback)
> > >> >>  >
> > >> >>  >
> > >> >>  > 2014/1/10 Thomas Andraschko <andraschko.tho...@gmail.com>
> > >> >>  >
> > >> >>  > > Hmm right - but we could also move
> windowContext#activateWindow
> > >> > to a
> > >> >>  > > AFTER_RESTORE_VIEW phase listener?
> > >> >>  > > AFAIK RESTORE_VIEW shouldn't touch any beans?
> > >> >>  > >
> > >> >>  > >
> > >> >>  > > 2014/1/10 Gerhard Petracek <gerhard.petra...@gmail.com>
> > >> >>  > >
> > >> >>  > >> we need to restore the window-id before the lifecycle starts.
> > >> >>  > >>
> > >> >>  > >> regards,
> > >> >>  > >> gerhard
> > >> >>  > >>
> > >> >>  > >>
> > >> >>  > >>
> > >> >>  > >> 2014/1/10 Thomas Andraschko
> > >> > <andraschko.tho...@gmail.com>
> > >> >>  > >>
> > >> >>  > >> > but why should we keep the JS logic instead of ViewMap?
> > >> >>  > >> > Are there any drawbacks when we store it in the ViewMap?
> > >> >>  > >> >
> > >> >>  > >> > The current implementations looks soo complex, but
> > >> > actually it isn't
> > >> >>  > >> that
> > >> >>  > >> > complex. So therefore i would like to get rid of not
> > >> > required code.
> > >> >>  > >> >
> > >> >>  > >> >
> > >> >>  > >> > 2014/1/10 Gerhard Petracek
> > >> > <gerhard.petra...@gmail.com>
> > >> >>  > >> >
> > >> >>  > >> > > as a (deactivatable) fallback the view-map would be
> > >> > fine (we
> > >> >>  > couldn't
> > >> >>  > >> use
> > >> >>  > >> > > it in codi, because we had to support jsf 1.2.x as
> > >> > well)
> > >> >>  > >> > >
> > >> >>  > >> > > regards,
> > >> >>  > >> > > gerhard
> > >> >>  > >> > >
> > >> >>  > >> > >
> > >> >>  > >> > >
> > >> >>  > >> > > 2014/1/10 Mark Struberg <strub...@yahoo.de>
> > >> >>  > >> > >
> > >> >>  > >> > > > we probably should do both.
> > >> >>  > >> > > >
> > >> >>  > >> > > > LieGrue,
> > >> >>  > >> > > > strub
> > >> >>  > >> > > >
> > >> >>  > >> > > >
> > >> >>  > >> > > >
> > >> >>  > >> > > >
> > >> >>  > >> > > > ----- Original Message -----
> > >> >>  > >> > > > > From: Thomas Andraschko
> > >> > <andraschko.tho...@gmail.com>
> > >> >>  > >> > > > > To: "dev@deltaspike.apache.org"
> > >> > <dev@deltaspike.apache.org>
> > >> >>  > >> > > > > Cc:
> > >> >>  > >> > > > > Sent: Friday, 10 January 2014, 16:56
> > >> >>  > >> > > > > Subject: Re: Ideas on ClientWindow
> > >> > handling / refactoring
> > >> >>  > >> > > > >
> > >> >>  > >> > > > > Saving the windowId for postbacks in the
> > >> > ViewMap, would be
> > >> >>  > really
> > >> >>  > >> a
> > >> >>  > >> > > much
> > >> >>  > >> > > > > easier, more compatible and safer way
> > >> > than adding hidden
> > >> >>  inputs
> > >> >>  > >> via
> > >> >>  > >> > JS.
> > >> >>  > >> > > > >
> > >> >>  > >> > > > >
> > >> >>  > >> > > > >
> > >> >>  > >> > > > > 2014/1/10 Thomas Andraschko
> > >> > <andraschko.tho...@gmail.com>
> > >> >>  > >> > > > >
> > >> >>  > >> > > > >>  Hi Gerhard,
> > >> >>  > >> > > > >>
> > >> >>  > >> > > > >>  thats true. Therefore we added extra
> > >> > processing of
> > >> >>  > >> > > > >>
> > >> > javax.faces.ViewState+javax.faces.ClientWindow in PrimeFaces
> > >> >>  > :)
> > >> >>  > >> > > > >>  Don't know if Cagatay would
> > >> > accept that i add workarounds
> > >> >>  for
> > >> >>  > >> DS in
> > >> >>  > >> > > > >>  PrimeFaces. Therefore adding the
> > >> > windowId e.g. to the
> > >> >>  ViewMap
> > >> >>  > >> would
> > >> >>  > >> > > be
> > >> >>  > >> > > > a
> > >> >>  > >> > > > >>  safer way.
> > >> >>  > >> > > > >>
> > >> >>  > >> > > > >>  Regards,
> > >> >>  > >> > > > >>  Thomas
> > >> >>  > >> > > > >>
> > >> >>  > >> > > > >>
> > >> >>  > >> > > > >>  2014/1/10 Gerhard Petracek
> > >> > <gerhard.petra...@gmail.com>
> > >> >>  > >> > > > >>
> > >> >>  > >> > > > >>>  @thomas:
> > >> >>  > >> > > > >>>  with jsf 2.2+ it's
> > >> > different.
> > >> >>  > >> > > > >>>  the window-id is (/should be)
> > >> > also used (if enabled) to
> > >> >>  find
> > >> >>  > >> the
> > >> >>  > >> > > > > correct
> > >> >>  > >> > > > >>>  state.
> > >> >>  > >> > > > >>>  -> any compliant request
> > >> > needs to include the window-id (if
> > >> >>  > >> > > > > enabled).
> > >> >>  > >> > > > >>>
> > >> >>  > >> > > > >>>  regards,
> > >> >>  > >> > > > >>>  gerhard
> > >> >>  > >> > > > >>>
> > >> >>  > >> > > > >>>
> > >> >>  > >> > > > >>>
> > >> >>  > >> > > > >>>  2014/1/10 Thomas Andraschko
> > >> > <andraschko.tho...@gmail.com>
> > >> >>  > >> > > > >>>
> > >> >>  > >> > > > >>>  > Based on the discussion in
> > >> > "JSF - default
> > >> >>  > >> > > > > ClientWindowRenderMode?":
> > >> >>  > >> > > > >>>  >
> > >> >>  > >> > > > >>>  > >> struberg:
> > >> >>  > >> > > > >>>  > >> The windowId is
> > >> > added as root element to the view
> > >> >>  tree.
> > >> >>  > >> > > > >>>  >
> > >> >>  > >> > > > >>>  > You mean that the
> > >> > dsPostWindowId input is added as direct
> > >> >>  > >> form
> > >> >>  > >> > > > > child.
> > >> >>  > >> > > > >>>  > Right?
> > >> >>  > >> > > > >>>  >
> > >> >>  > >> > > > >>>  > Posting it with default
> > >> > ajax options should work fine
> > >> >>  with
> > >> >>  > >> > > > > PrimeFaces.
> > >> >>  > >> > > > >>>  > The only difference is our
> > >> > partialSubmit modus, which
> > >> >>  only
> > >> >>  > >> > > > > collects the
> > >> >>  > >> > > > >>>  > values from the processed
> > >> > components.
> > >> >>  > >> > > > >>>  > So if you only process e.g.
> > >> > "input1 input2", the hidden
> > >> >>  > >> > > > > inputs on the
> > >> >>  > >> > > > >>>  form
> > >> >>  > >> > > > >>>  > won't processed.
> > >> >>  > >> > > > >>>  > Updating the ViewState is a
> > >> > custom logic with
> > >> >>  > partialSubmit.
> > >> >>  > >> > > > >>>  >
> > >> >>  > >> > > > >>>  > Maybe it should be handled
> > >> > better on PrimeFaces side but
> > >> >>  I
> > >> >>  > >> think
> > >> >>  > >> > > > > it
> > >> >>  > >> > > > >>>  would
> > >> >>  > >> > > > >>>  > be better the store the
> > >> > windowId in the
> > >> >>  WindowIdComponent.
> > >> >>  > >> > > > >>>  > It works for all cases and
> > >> > it don't requires any JS or
> > >> >>  > >> > > > > compontlib
> > >> >>  > >> > > > >>>  > compatibility.
> > >> >>  > >> > > > >>>  > It's just stored the
> > >> > windowId in the ViewRoot which is
> > >> >>  > always
> > >> >>  > >> > > > > available
> > >> >>  > >> > > > >>>  for
> > >> >>  > >> > > > >>>  > postbacks.
> > >> >>  > >> > > > >>>  > Or will it have other
> > >> > drawbacks?
> > >> >>  > >> > > > >>>  >
> > >> >>  > >> > > > >>>  >
> > >> >>  > >> > > > >>>  > About
> > >> > windowhandler.js/html:
> > >> >>  > >> > > > >>>  > What about moving the whole
> > >> > JS stuff to the
> > >> >>  > windowhandler.js?
> > >> >>  > >> > > > >>>  > We could parse the
> > >> > windowhandler html string on the
> > >> >>  server
> > >> >>  > >> and
> > >> >>  > >> > > > > parse JSF
> > >> >>  > >> > > > >>>  > resource includes. So we
> > >> > could easily include our
> > >> >>  > >> > > > > windowhandler.js.
> > >> >>  > >> > > > >>>  > The user can also import
> > >> > other resources like css.
> > >> >>  > >> > > > >>>  >
> > >> >>  > >> > > > >>>  > I already done this for a
> > >> > custom JSF 2.2 ClientWindow -
> > >> >>  > works
> > >> >>  > >> > > > > fine.
> > >> >>  > >> > > > >>>  >
> > >> >>  > >> > > > >>>  > I think we should also
> > >> > render the ClientWindowRenderMode
> > >> >>  to
> > >> >>  > >> the
> > >> >>  > >> > > > > client,
> > >> >>  > >> > > > >>>  so
> > >> >>  > >> > > > >>>  > that the windowhandler only
> > >> > handles CLIENTWINDOW and not
> > >> >>  > e.g.
> > >> >>  > >> > URL.
> > >> >>  > >> > > > >>>  > I would refactor the
> > >> > windowhandler.js, that it must be
> > >> >>  > >> > initialized
> > >> >>  > >> > > > > via
> > >> >>  > >> > > > >>>  a JS
> > >> >>  > >> > > > >>>  > call ->
> > >> > DSWindowContext.init(windowId,
> > >> >>  > >> clientWindowRenderMode);
> > >> >>  > >> > > > >>>  > We could simply render that
> > >> > script via our
> > >> >>  > >> > > > >>>  WindowIdComponentHtmlRenderer.
> > >> >>  > >> > > > >>>  >
> > >> >>  > >> > > > >>>
> > >> >>  > >> > > > >>
> > >> >>  > >> > > > >>
> > >> >>  > >> > > > >
> > >> >>  > >> > > >
> > >> >>  > >> > >
> > >> >>  > >> >
> > >> >>  > >>
> > >> >>  > >
> > >> >>  > >
> > >> >>  >
> > >> >>
> > >> >
> > >>
> > >
> > >
> >
>

Reply via email to