gt; > >> >> regards,
> > > > > >> >> gerhard
> > > > > >> >>
> > > > > >> >>
> > > > > >> >>
> > > > >
ed #ifPostback)
> > > > >> >> >
> > > > >> >> >
> > > > >> >> > 2014/1/10 Thomas Andraschko
> > > > >> >> >
> > > > >> >> > > Hmm right - but we co
t; > windowContext#activateWindow
> > > >> > to a
> > > >> >> > > AFTER_RESTORE_VIEW phase listener?
> > > >> >> > > AFAIK RESTORE_VIEW shouldn't touch any beans?
> > > >> >> > >
arts.
> > >> >> > >>
> > >> >> > >> regards,
> > >> >> > >> gerhard
> > >> >> > >>
> > >> >> > >>
> > >> >> > >>
> >
> >> >> > >>
> >> >> > >>
> >> >> > >>
> >> >> > >> 2014/1/10 Thomas Andraschko
> >> >
> >> >> > >>
> >> >> > >> > but why shou
;> >
>> >> > >> > 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.
&
;
> >> > >> > 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
> >> > 2014/1/10 Gerhard Petracek
>
>> > >> >
>> > >> > > as a (deactivatable) fallback the view-map would be
> fine (we
>> > couldn't
>> > >> use
>> > >> > > it in codi, because we had
gt; > >> > > regards,
> > >> > > gerhard
> > >> > >
> > >> > >
> > >> > >
> > >> > > 2014/1/10 Mark Struberg
> > >> > >
> > >> > > > we probably should do bo
s,
> >> > > gerhard
> >> > >
> >> > >
> >> > >
> >> > > 2014/1/10 Mark Struberg
> >> > >
> >> > > > we probably should do both.
> >> > > >
> >> > > > LieGrue,
> &g
t; > >
>> > >
>> > > 2014/1/10 Mark Struberg
>> > >
>> > > > we probably should do both.
>> > > >
>> > > > LieGrue,
>> > > > strub
>> > > >
>> > > >
>> > >
t; >
> > > regards,
> > > gerhard
> > >
> > >
> > >
> > > 2014/1/10 Mark Struberg
> > >
> > > > we probably should do both.
> > > >
> > > > LieGrue,
> > > > strub
> > > >
>
gt;
> > > ----- Original Message -----
> > > > From: Thomas Andraschko
> > > > To: "dev@deltaspike.apache.org"
> > > > Cc:
> > > > Sent: Friday, 10 January 2014, 16:56
> > > > Subject: Re: Ideas on ClientWindow handling
trub
> >
> >
> >
> >
> > - Original Message -
> > > From: Thomas Andraschko
> > > To: "dev@deltaspike.apache.org"
> > > Cc:
> > > Sent: Friday, 10 January 2014, 16:56
> > > Subject: Re: Ideas on ClientW
> > From: Thomas Andraschko
> > To: "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 r
we probably should do both.
LieGrue,
strub
- Original Message -
> From: Thomas Andraschko
> To: "dev@deltaspike.apache.org"
> Cc:
> Sent: Friday, 10 January 2014, 16:56
> Subject: Re: Ideas on ClientWindow handling / refactoring
>
> Saving the window
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
> Hi Gerhard,
>
> thats true. Therefore we added extra processing of
> javax.faces.ViewState+javax.faces.ClientWindow in P
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
@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
> Based on the discussion in "JSF - default ClientWindowRen
19 matches
Mail list logo
