That's similar to what we've got in mind :) Cheers! On Thu, Mar 6, 2008 at 12:08 AM, <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 05, 2008 at 09:34:58AM +1000, Josh McDonald wrote: > > > We don't want business rules duplicated in Flex, that's what Oracle > SOA's > > for. And the business rules depend on variables and conditions that the > flex > > app will not and should not have access to. I mean, how would it even be > > possible if certain business rules are say, time-dependent? > > I've been leading my dev team with the idea that the service needs to > implement all validation rules. The client can re-implement them, for > convenience, particularly in cases like the aforementioned date range > validations. In our implementation, if the server-side validation fails, the > > service returns it's own fault block with a code, message, and token. The > token is typically the name of the element that contains the data that > failed validation, or in the case of multiple elements with validation > dependancies, the "most significant" element. The Flex client looks at the > returned token and uses this to back the UI up to the correct screen and > highlight the potentially erroneous field. > > We did not design this solution to deal with duplicate elements located in > different parts of the XML tree. We deal with this in a ghetto manner by > ensuring that our fault tokens are not duplicated (thus they do not always > match element names), but it would certainly be posible to implement > something that returned the xml path to the failed element. > > -Jeff > > -- "Therefore, send not to know For whom the bell tolls, It tolls for thee." :: Josh 'G-Funk' McDonald :: 0437 221 380 :: [EMAIL PROTECTED]
