Thank you all for responding to my question.
I probably should have begun by stating my problem:
I want to be able to reset an update form to it's initial state. Sounds
simple enough, but...
A button of type="reset" works fine, but on this jsp, a form submit may
have
occurred to refresh lists on the page. I'm seeing that once a submit
occurs,
reset does not return the original bean properties if they have been
modified.
even cancel with immediate="true" does not return original properties
if a property has been modified before a form submit.
So I was trying to cheat by saving a copy of the update bean in *itself*.
My intent was to get the update bean from session, then get the *copy*
of the bean and put that back in session.
But what I saw was that the copy of the update bean also contained any
modification.
That triggered my question about how deeply myfaces resolved variable
references.
I've since been told that I messed up by storing a copy of the bean in
itself;
I was storing only a reference to the bean, not a separate physical object
I could manipulate.
a simplified picture...
Class MyBean {
private String foo; //with getters and setters
private MyBean mybean; //with getters and setters
}
MyBean is the update bean in session.
After foo was initialized and before I put MyBean in session, I did
something like
myBean.setMyBean(myBean);
That's what I mean by a copy in itself, hoping to preserve the original
value of foo.
It's stupid I know, I was wrong and I've learned a good lesson.
Thanks to all.
Tom
"Dhananjay
Prasanna"
<[EMAIL PROTECTED] To
ncy.qld.gov.au> "MyFaces Discussion"
<[email protected]>
07/31/2006 08:49 cc
PM
Subject
RE: how deeply into a bean does
Please respond to myfaces update value references?
"MyFaces
Discussion"
<[EMAIL PROTECTED]
ache.org>
Hi Craig,
We've had this discussion regarding the $ separator on this list not long
ago.
I am aware of and have been using the spring resolver, however there is a
namespace collision between spring beans and jsf beans?the resolver will
prefer spring beans of the same id (assuming the spring delegating resolver
is first). There is no way to discriminate between them without ugly global
renames or naming policies that may be cumbersome to the business.
Admittedly (in the spring docs), the delegating resolver is quite a
rudimentary integration solution.
Tapestry 4 supports a "service protocol" where injection id's prefixed with
a service name will delegate to different resolver (i.e.: "spring:myBean"
as opposed to "myBean"). The naming convention is also elegant. Anyway it
is just a suggestion?if spring and other (seam?) integration compatibility
is going to be a consideration for jsf 1.3(?).
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig
McClanahan
There is no special support for "namespaces" in JSF 1.2 (the most recent
finalized spec), but nothing really stops you from simulating this. I tend
to use "$" instead of ":" as a separator, because it is a legal character
in identifiers so you don't have to go quoting things.
Or the more adventurous of us who want to try (or need) and delegate some
DI to spring or hivemind. ;)
I don't know of any Hivemind integration, but it's already there for
Spring. In 1.2.5 they started offering a custom variable resolver that can
use Spring to create singletons or a new bean on each request -- and it
happens transparently to your usage of value binding and method binding
expressions. In Spring 2, the story is even better since they've added the
concept of scopes, so you can tell Spring to create a new session scoped
bean. From the JSF perspective, you just use expressions like you always
have ... it's just that Spring will be used instead of managed beans to
construct and return the instances.
Craig
This correspondence is for the named persons only.
It may contain confidential or privileged information or both.
No confidentiality or privilege is waived or lost by any mis transmission.
If you receive this correspondence in error please delete it from your
system immediately and notify the sender.
You must not disclose, copy or relay on any part of this correspondence,
if you are not the intended recipient.
Any opinions expressed in this message are those of the individual sender
except where the sender expressly,
and with the authority, states them to be the opinions of the Department
of Emergency Services, Queensland.
This message is intended for the recipient only and is not meant to be
forwarded or distributed in any other format. This communication is for
informational purposes only. It is not intended as an offer or solicitation
for the purchase or sale of any financial instrument, or security, or as an
official confirmation of any transaction. Putnam does not accept purchase or
redemptions of securities, instructions, or authorizations that are sent via
e-mail. All market prices, data and other information are not warranted as to
completeness or accuracy and are subject to change without notice. Any
comments or statements made herein do not necessarily reflect those of Putnam,
LLC (DBA Putnam Investments) and its subsidiaries and affiliates. If you are
not the intended recipient of this e-mail, please delete the e-mail.
