On Saturday, August 11, 2012 12:26:31 PM UTC+2, Arash wrote:
>
> Hi,
>
> There seem to be similar issues posted previously but none of them
> explains this seem to be very trivial scenario. I have the typical
> Person/Address relationship in my entities. The person's address can be
> null but if there is an address, the city and zip can not be null (please
> take a look at the entities below). I utilize RequestFactoryEditorDriver to
> display/edit the person and address utilizing PersonEditor and
> AddressEditor respectively. I have to mention editing an existing Person
> with an Address works just fine so the editors are working and implemented
> somewhat properly.
> Creating a person get done by: request.persist().using(person). If I
> don't provide an address before starting the driver(setValue is called with
> null), the PersonEditor does its job but AddressEditor's value gets ignored
> which is expected but not desired. If I create an address (via the same
> requestContext) and assign it to the person (as commented out) before
> creating my persist context and starting the driver, then I "have to" have
> an address. If I leave the city/zip empty, the editors validation detects
> the error and demands the fields to be set. But what if I just want to
> ignore the address for some persons and provide one for others.
> Basically I want to choose creating an addressProxy and attaching it to
> the context. If the AddressEditor is empty then there is no need to create
> an AddressProxy, but if there is a value in the AddressEditor then the
> validation and flush need to work as expected.
> /*
> AddressProxy address = request.create(AddressProxy.class);
> proxy.setAddress(address);
> */
> request.persist().using(person);
>
> here's the jest of AddressEditor
> public class AddressEditor extends Composite implements
> HasRequestContext<AddressProxy>,
> ValueAwareEditor<AddressProxy>, LeafValueEditor<AddressProxy>,
> HasEditorErrors<AddressProxy> {
> ....
> }
> I tried the OptionalFieldEditor in AddressEditor as follow but I wasn't
> sure if I should utilize it in PersonEditor or AddressEditor
>
> interface Driver
> extends
> RequestFactoryEditorDriver<AddressProxy,
> OptionalFieldEditor<AddressProxy, AddressEditor>> {
> }
>
> public class Person{
> @NotNull
> @Size(min = 3, max = 30)
> @Column(name = "first_name")
> private String firstName;
>
> @NotNull
> @Size(min = 3, max = 30)
> @Column(name = "last_name")
> private String lastName;
>
> @OneToOne(cascade = CascadeType.ALL, fetch = FetchType.EAGER)
> @JoinColumn(name = "address_id", unique = true)
> private Address address;
> }
>
> public class Address{
> @Size(min = 3, max = 64, message = "Street lenght needs to be between
> 3 to 64 chars")
> @Column(name = "street")
> private String street;
>
> @NotNull
> @Size(min = 3, max = 30)
> @Column(name = "city")
> private String city;
>
> @NotNull
> @Size(min = 5, max = 10)
> @Column(name = "zip")
> private String zip;
> }
> As you can tell, I have exhausted my options by implementing every
> possible editor interfaces and testing different scenarios.
> Any help would be greatly appreciated.
> Arash
>
Basically, you want to always have an AddressProxy instance, so first start
by ensuring the edited value is never 'null'.
Next, in case the user empties the fields, you don't want to send an empty
AddressProxy to the server as it'll fail validation, even if it's not
"attached" to the PersonProxy.
For now, RF will send all created/edited objects to the server, regardless
of whether they're actually "used" (passed as arguments to service methods
or referenced by other proxies). I have a TODO to fix this (and reduce the
payload size) but there was a a "feature" of RF where you could edit/create
proxies and send them to the server without any service method call, just
to validate them and be a no-op if they're valid, so it's not as easy as it
sounds. In the mean time, that means you have to make sure the AddressProxy
is always valid, particularly if not used.
This all boils down then to create an AddressProxy in all cases, but make
sure it's not empty before fire()ing the RequestContext.
I can think of two ways to always have an AddressProxy: create one in the
RequestContext, or create an object that implements AddressProxy and
replace it with a "real" proxy just before fire()ing iff the "fake" proxy
is not empty.
And I can think of 2 places to do that:
- Create the proxy and assign it (if needed) before edit()ing the
PersonProxy, and then "validate" it and "fix" it (reset the address of the
person to 'null' iff empty, and if the AddressProxy is a "real" proxy then
put dummy data so it'll validate on the server-side; the dummy data won't
be used as the Address is no longer attached to the Person) after
flush()ing the EditorDriver but before fire()ing the RequestContext.
- Extend OptionalFieldEditor and override getValue and setValue. In
setValue, if the value is null, create the AddressProxy and pass it to
super.setValue; in getValue, if the address is empty, return null (and if
it's a "real" proxy, put dummy data into it)
Much simpler though, you could consider an empty Address as the equivalent
of "no address at all" in your validation logic.
Well, simpler on the client side, probably not on the server side…
One possibility is to avoid validating the Address at the
RequestFactoryServlet level (create it with a ServiceLayerDecorator that
implements the validate() method to validate only some specific validation
groups, or special-case the Address object) and instead either validate it
as part of validating the Person (using a custom validator on the 'address'
field) or validate it as part of the saving process (explicitly validate
it, using some specific validation groups for instance, in your persist()
service method).
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/google-web-toolkit/-/QEKeshZNbWYJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
