Re: Cross field validation on client

Hi Thomas,

Thanks for your detailed answer, here are my thoughts:

 

If it's the case, this could be a performance problem since we might have some complex validation processes that we want to execute only when we call some service methods (in a perfect world we would be able to decide on the client or server side if we want to execute a validation or skip it).

The idea is that you only validate those things that MUST be validated (and for that, you just put them in the default group, and other constraints in other groups; or you put them in a specific group and you use a ServiceLayerDecorator with an overridden validate() method to validate only that specific group).

To be more specific, I have to check two shops don't enter the same name. This happens only when the user activates a special Ui to change his shop name (not a frequent operation by nature). Therefore I was surprized we cannot configure which group has to be associated with which service (I understand that by default it's automatically the default group that has to be triggered, it's useless to configure each service to use the default group validation), but at some point we should be able to decide that a given service has to work with another group. A better solution would be to have a single check point façade that can be configured on server side that dynamically decides whether validation must occur and with which group (the default implementation would always point to the default group, but that would be an extention point). 

Do you think I should enter a feature request with this or is there already something happening in GWT internally?

 

 

this is really an issue because RequestFactory is thought as a rigid architecture : the user entered data can be reused only if the validation failed (otherwise the EntityProxy becomes frozen, and there's no easy way to duplicate an EntityProxy). So the best way to check a precondition constraint is in the validation process. The issue is that you have the choice between two scenarios: 

• You can do your checks in a specific service method, throw an exception and handle that in the onFailure() client side method. But!!! you cannot reuse the EntityProxy anymore since it's frozen
  
• You can do your checks in the validation phase, so you can keep your EntityProxy reuasable, But!!! the validation is made each time you send data to the server (which can be a hard resource consumption issue)

So the question is: is there a way to controle whether the server side validation process has to be made? (a per service method configuration or a runtime check switch)?

I'm sure you can come up with clever tricks to pass some value down to a ServiceLayerDecorator's validate() method (e.g. through a request header, or appending data to the payload and stripping it in a servlet filter).

Sure I can come up with something, but in my opinion it's over engeneering for a small benefit (especially that this will at best "impact performance", and at worse "insert hard to detect/fix bugs to the entire app"). It's like asking a car driver to use a screwdriver to set up the position of his seat :)

 

I'm rather supportive of RF but it doesn't fit everyone's use-case (well, using only ValueProxies makes it a good replacement for GWT-RPC with an added batching feature, at the expense of bigger payloads but without the hassle of serialization policies).

Wrt validation, RF works best if you restrict validation to "per field" (value ranges, patterns, etc.) or otherwise fast checks, and allow invalid data (wrt. other (business) constraint violations) to be persisted, along with a valid/invalid flag of some sort. Then depending on the valid/invalid flag you can decide whether some actions on the persisted data are possible or not. Actually, that's the approach that best fits "the web", because you don't want to "get in the way" of the user and risk all his "work" to be lost (browser crash, broken connectivity, etc.): when I tell you to save, just save, when I tell you to "act", feel free to refuse if the saved data is wrong. It generally requires totally rethinking the way you work with data and the way you store it, so it might only be possible in greenfield projects with enough budget and sufficiently skilled architects/developers.

The alternative is to "flush" data (and edit()) into your proxies only when needed; that way you can just "flush" again in newly-edit()ed proxies should an error happen (if you use the Editor framework, that means *not* using the RequestFactoryEditorDriver; you could use "edit on write" proxies that read from frozen RF proxies and only edit() and write into RF proxies on flush; or you could copy data from the RF proxies to "view model" objects, and then edit the RF proxies and copy back again just before fire()ing the request)

I think this is not tied to RF globally but rather to RF's validation module specifically, which can be improoved. Actually since validation happens server side, it's better to configure it on the server side too, there's no need to send addition data from the client to say how something should be validated. If a special case raises, the client developer can still create a new service method for that specific need.

 

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.