Allow @Tester annotation on a field in a super class
Key: MYFACESTEST-31
URL: https://issues.apache.org/jira/browse/MYFACESTEST-31
Project: MyFaces Test
Issue Type: Improvement
PropertyResolver should recognize the propery in the super class
Key: MYFACES-1309
URL: http://issues.apache.org/jira/browse/MYFACES-1309
Project: MyFaces Core
Type: Improvement
Components: JSR-127
IMO saving the state like jsf does is a very nice solution for this
problem. I like it because it perfectly follows the OO paradigms and
is easy to implement. I use it for our applications too. Whenever I
have to handle table data where some fields needs to maintain a state
for each row it is
Simon Kitching wrote:
I'm still on the JSF learning curve, but I believe we're talking here
about saving the UIComponent tree state, and that that is done via a
custom approach in JSF.
Firstly the JSF framework saves the classnames of the UIComponent object
tree, so that it can build an
I´ve added two context parameters:
org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION
defines the number of the latest views stored in the session with a
default of 20 (like RI)
org.apache.myfaces.SERIALIZE_STATE_IN_SESSION
if true (default) the state will be serialized to a byte array,
otherwise it
-Original Message-
org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION
defines the number of the latest views stored in the session with a
default of 20 (like RI)
-/Original Message-
Great... one less test/investigation I have to do before being able to
request that JSF gets mandatory
IMO having a max number of views stored in the session is quite
adequate for this. If the user navigates to other pages the oldest
view is dropped if the max number is reached. Correct me if I´m wrong
but this is different to the RI. AFAIK RI stores the last n views
based on a view. So you can end
-Original Message-
IMO having a max number of views stored in the session is quite
adequate for this. If the user navigates to other pages the oldest
view is dropped if the max number is reached. Correct me if I´m wrong
but this is different to the RI. AFAIK RI stores the last n views
I'd like to agree with Alexander on this one. Sometimes, it's better
to be able to tell end users that their pages will expire after 5
minutes (or 5 hours) rather than saying they can only backtrack 15
views (most end-users have no idea what a view means). Not all of
us need to tune our
This sounds good to me. Any idea how we can implement it. The only
solution I have is too have an additional thread running somewhere
which checks for timeouts.
2005/10/20, Mike Kienenberger [EMAIL PROTECTED]:
I'd like to agree with Alexander on this one. Sometimes, it's better
to be able to
-Original Message-
This sounds good to me. Any idea how we can implement it. The only
solution I have is too have an additional thread running somewhere
which checks for timeouts.
-/Original Message-
Put a bean into application context, which gets the info about actual
sessions
About the branches: is this only in the main trunk, or also in the 1.1.1 trunk (and thus will be in the RC3)?
On 18 Oct 2005, at 22:06, Adam Winer wrote:
This sounds roughly like the implementation of server-side
state saving in the JSF 1.2 RI, as well as what's done in ADF Faces,
though not
Its only in the main trunk. Since it is not fully tested and the next
maintenance release is quite close I´ve not commited it into the 1.1.1
banch.
2005/10/19, ir. ing. Jan Dockx [EMAIL PROTECTED]:
About the branches: is this only in the main trunk, or also in the
1.1.1 trunk (and thus will be
You are right the two objects in SerailizedView are serialized and put
into the session.
The instances of the server side state where not serialized before.
This doesn´t affect the component instances since they are only
referenced by class name in the state but it could have an effect on
the
Sensible.
On 19 Oct 2005, at 9:51, Mathias Brökelmann wrote:
Its only in the main trunk. Since it is not fully tested and the next
maintenance release is quite close I´ve not commited it into the 1.1.1
banch.
2005/10/19, ir. ing. Jan Dockx [EMAIL PROTECTED]>:
About the branches: is this only in
Just FYI...
I took a look at the RI Implemention. The user is
allowed to specify as a ServletContextInitParameter
the maximum number of logical views to be saved in
session. If no value is specified, then the default
value is used.
--- Adam Winer [EMAIL PROTECTED] wrote:
This sounds roughly
That is my only feature enhancement wish as well ;)
regards,
Martin
On 10/19/05, sharath reddy [EMAIL PROTECTED] wrote:
Just FYI...
I took a look at the RI Implemention. The user is
allowed to specify as a ServletContextInitParameter
the maximum number of logical views to be saved in
Ah, so you don't save the objects directly, you save the byte streams?That's excellent for development - it's a pain figuring out down the road that one object way down deep isn't serializable, and only when you try clustering right before going production :) - but seems like an unnecessary
Mathias,
wow - you have solved the server side state saving problem we have had for ages?
That will make some users very, very happy!
Thanks from the whole team, great news indeed.
Do you want to give us (on the dev list) a short wrapup on how you
solved things? Did you keep close to the RI or
Well, I have not taken a look into the ri for this issue. So I can not
say if it is solved like the ri.
This is what I have done:
If server side state is uses the serialized view is now really
serialized (this was not the case before) into the session by using
the viewid and a sequence number.
Sounds very good indeed!
Mathias - absolutely professional as always ;)
Werner, you did have a need for such a thing as well, right?
So you might check this out a bit?
regards,
Martin
On 10/18/05, Mathias Brökelmann [EMAIL PROTECTED] wrote:
Well, I have not taken a look into the ri for this
Mathias Brökelmann wrote:
If server side state is uses the serialized view is now really
serialized (this was not the case before) into the session by using
the viewid and a sequence number.
May I ask if you also add this sequence number to the redirect url if
one uses redirect navigation
Mario Ivankovits wrote:
http://issues.apache.org/jira/browse/MYFACES-516
Oh, and I tried to survive the messages too.
---
Mario
Martin Marinschek wrote:
Sounds very good indeed!
Mathias - absolutely professional as always ;)
Werner, you did have a need for such a thing as well, right?
Yes I had a huge need for that.. ;-)
So you might check this out a bit?
I will ASAP... btw... I have good news, if you can
Redirection is not handled. Neither by client nor by server side state saving.
2005/10/18, Mario Ivankovits [EMAIL PROTECTED]:
Mathias Brökelmann wrote:
If server side state is uses the serialized view is now really
serialized (this was not the case before) into the session by using
the
Mathias Brökelmann wrote:
Redirection is not handled. Neither by client nor by server side state saving.
Its not a question of client or server side state saving.
If you do NOT use redirect you are still in the same request and thus
have access to beans modified during this request.
If
This sounds roughly like the implementation of server-side
state saving in the JSF 1.2 RI, as well as what's done in ADF Faces,
though not exactly, 'cause there's differences in the details (neither,
for instance, supports putting sequence numbers into URLs, just
hidden fields).
What exactly do
27 matches
Mail list logo
