royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harbs <harbs.li...@gmail.com>
Subject Re: [Discussion] About validation
Date Mon, 02 Oct 2017 22:22:45 GMT
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 <aharui@adobe.com.INVALID> 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, "carlos.rovira@gmail.com <mailto:carlos.rovira@gmail.com>
on behalf of Carlos Rovira"
> <carlos.rovira@gmail.com <mailto:carlos.rovira@gmail.com> on behalf of carlosrovira@apache.org
<mailto:carlosrovira@apache.org>> 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


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message