I have very few work days until the 15th. I doubt I’m going to work more on validation until then.
If someone else wants to do work on it before that, it’s fine with me… > On Oct 2, 2017, at 8:46 PM, Alex Harui <[email protected]> wrote: > > I didn't look at the Validation commit too closely because I saw commit > comments that it was work in progress and need refactoring into beads and > PAYG. So work with Herbs and others to figure out a better implementation > that takes into account different validation implementations. Although > I'd prefer that any refactoring for Validation happens before or after the > big rename. > > Lately, I've been thinking that Core should be mostly interfaces and > relatively few concrete classes, and a pile of common utility functions, > so I agree that the actual Validators might be better off in another SWC. > It would be great if all implementations could share interfaces, if any > interfaces are needed. Maybe they just watch events. > > My 2 cents, > -Alex > > On 10/2/17, 2:38 AM, "[email protected] > <mailto:[email protected]> on behalf of Carlos Rovira" > <[email protected] <mailto:[email protected]> on behalf of > [email protected] <mailto:[email protected]>> wrote: > >> Hi, >> >> I notice Harbs was including one of the missing parts in Royale: >> Validation. >> >> So great, since that is something very needed to get 1.0 state. >> >> I'd want to understand about the implementation. I suppose is based on the >> Flex Validator implementation to use it in MXML. Is that right? When it's >> finished it would be something similar to what we had in old Flex SDK? >> >> I want as well to expose some thoughts as I started to saw it: >> >> 1.- I see the code is inside "Core" project (inside utils folder) and not >> in a new "Validation" project. Is this something temporal? I was expecting >> this to be as others projects (i.e: Formatters) and be a PAYG piece. >> (don't >> know if this was already discussed) >> >> 2.- Since Royale is strongly PAYG based my expectations in the future >> would >> be to have the old Flex sdk implementation and another completly different >> that IMHO had a more modern and better approach, and was what I end using. >> I'm talking about GDS Validation framework: >> >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co >> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co> >> m%2Fgraniteds%2Fgraniteds%2Ftree%2Fmaster%2Fgranite-client-flex-advanced%2 >> Fsrc%2Fmain%2Fflex%2Forg%2Fgranite%2Fvalidation&data=02%7C01%7C%7Cf26e2f91 >> bfd64050087b08d509797243%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6364 >> 25339574436323&sdata=f1kmFyuw6WHSgUJI%2F72gZGBH%2FhojiXQN7I3M7zLtFpk%3D&re >> served=0 >> >> This GDS implementation used annotations (that in our case could be beads >> although I like annotations in AS3 Value Objects and I think we should not >> lose that since is very powerful) >> >> The main way of thinking here was to separate validation from the UI >> control used and be able to make validations in controller's method , for >> example before sending some Value Object to the server. >> >> Resuming: For me old Flex SDK validators are need for migration. New >> people >> would want new modern options, and I think this would be along other >> things >> what make a difference between Royale and competitors. >> >> Hope we could discuss this since I thing it's an important subject. >> >> Thanks. >> >> >> -- >> Carlos Rovira >> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2 >> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2> >> Fcarlosrovira&data=02%7C01%7C%7Cf26e2f91bfd64050087b08d509797243%7Cfa7b1b5 >> a7b34438794aed2c178decee1%7C0%7C0%7C636425339574436323&sdata=Gi1T4Hhu5EhJJ >> 4h2scRqaEKAm%2FBphfseI0Ap87tKD%2FM%3D&reserved=0
