royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harbs <>
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

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 <> 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, " <>
on behalf of Carlos Rovira"
> < <> on behalf of
<>> 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:
>> <>
>> 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
>> <>
>> Fcarlosrovira&data=02%7C01%7C%7Cf26e2f91bfd64050087b08d509797243%7Cfa7b1b5
>> a7b34438794aed2c178decee1%7C0%7C0%7C636425339574436323&sdata=Gi1T4Hhu5EhJJ
>> 4h2scRqaEKAm%2FBphfseI0Ap87tKD%2FM%3D&reserved=0

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