Hi Leo,
Great job!
Regards,
Jakob
2011/5/14 Leonardo Uribe lu4...@gmail.com:
Hi
I finally committed a solution for this issue, and other cool
optimizations in MYFACES-3117. I'll going to explain below which
changes were done.
Now there exists a class called
Hi
I finally committed a solution for this issue, and other cool
optimizations in MYFACES-3117. I'll going to explain below which
changes were done.
Now there exists a class called
org.apache.myfaces.application.StateCacheK, V, to delegate all logic
related to state storing/retrieving in a
hi,
i talked with ed about this topic and he opened [1].
imo we should implement a solution including a spi. it would be easier to
specify the mechanism based on our implementation.
furthermore, a spi would allow to implement a myfaces-core2 specific add-on
for libs like codi.
regards,
gerhard
Hi why not introduce a url param as view window/tag token and
then basically hook the map history in the session onto this token if given.
We could use codi window id for that token. If present we can handle
multiple maps per session if not then we run within the old scheme.
Outside of codi you
hi werner,
it's the other way round - a jsf impl is able to do way more in a portable
way (as soon as it is in the spec) than codi.
what we should prototype (imo):
- window-id
- request token
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses
Hi
Working on this stuff I have found a problem with our current
ResponseStateManager implementation. The spec javadoc says this:
... ResponseStateManager is the helper class to StateManager that
knows the specific rendering technology being used to generate the
response. It is a singleton
hi leo,
@window-id:
we have a window(-id) concept e.g. in trinidad, icefaces, cdi (at least a
conversation-id which should be specific to a window), codi,... . so we
again have incompatibilities (esp. in case of dialogs,...) which can't be
solved by just wrapping something. - adding the concept
Hi
There is an old, known problem related to server side state saving,
that becomes more evident in JSF 2.0 and its ajax support.
For more information about it, you can see:
https://issues.apache.org/jira/browse/MYFACES-3117
Current server state saving implementation prevents multi-window usage
