Hi Franck, I was looking at the validation source in graniteds and I see that dependencies are a bit more complex. From what I see those are the packages needed:
* math * reflect * util * collections maybe some other class could be needed... Maybe some refactor could be done to avoid overhead of classes that really are not used/needed Best, Carlos 2012/10/2 Om <bigosma...@gmail.com>: > Thanks for the detailed responses, Franck. I think this could work and > would make a great addition to Flex. > > PPMC folks, any objections? Or should we take a formal vote on this? > > What should be the next steps? > > Thanks, > Om > > On Wed, Sep 26, 2012 at 3:07 AM, Franck Wolff > <franck.wo...@graniteds.org>wrote: > >> Om, >> >> 2012/9/25 Om <bigosma...@gmail.com> >> >> > Franck, >> > >> > My initial reaction after reading the documentation is that this would >> be a >> > great addition to the Flex framework. >> > >> > If you don't mind, maybe you could address these concerns I have? >> > >> > 1. Can we make sure that this approach does not tie Flex to specific >> > server side solution (Java in this case)? >> > >> >> The validation can be used standalone, without any server-side counterpart: >> you can manually annotate your AS3 beans and run a pure client-side >> validation process. Usually, these annotations are generated by Gas3, based >> on Java annotations you put on your Java entity beans, but this is just a >> typical JavaEE usage: the framework doesn't depend on any specific server >> implementation (Java or not). >> >> However, I realized after sending my last email that the bean validation >> framework relies on our BigDecimal implementation: the DecimalMax/Min, >> Digits and Max/Min constraints annotations make internal use of BigDecimal >> values in order to check the validity of a given field (which can be a >> String, a Number, an int/uint or a BigDecimal). The purpose of this >> dependency is to stick, as much as possible, to the JSR-303 specification >> and to make sure that the validation on the Flex side is consistent with >> the validation on the Java side. As a result, we must contribute both the >> Bean Validation and Big Numbers implementations... But even with this >> addition, there is no dependency to GraniteDS. >> >> To summarize: >> >> 1. The Bean Validation in AS3 doesn't depend on GraniteDS or any Java >> server-side solution: it comes from a specification written for Java EE >> developers, it is often used with our code generation tool (Gas3), but >> you >> can use it without any specific server side solution (it can be PHP or >> whatever you want). >> 2. It does depend on our BigDecimal implementation, which comes >> originally from a Java class but serves a general purpose for handling >> numbers with arbitrary scale and precision. If you don't explicitly use >> BigDecimal in your code, and more specifically, if you don't try to >> serialize this kind of value, there is again no dependency to any >> specific >> server side solution. If you intend to serialize BigDecimal values, the >> server, whatever it is, has to handle an "externalization" of the >> BigDecimal value as a String, which is not a big deal and follows the >> AMF3 >> specification (ie: org.granite.math.BigDecimal implements >> flash.utils.IExternalizable). There is of course a built-in support for >> that in GraniteDS, but it is just related to a (de)serialization which >> not >> all used in the Bean Validation framework. >> >> >> 2. Do you think this could go in the SDK itself or would it go into an >> > ancilliary library, but still part of Flex. Can you suggest a package >> > structure? >> > >> >> Our current packages structure is: >> >> org.granite.validation (Bean Validation) >> org.granite.math (BigDecimal) >> >> It could be whatever you want. It can go into an ancillary library, but it >> would be simpler for users to be able to use it without any specific >> configuration. Again, it's up to you. >> >> >> > 3. What happens to JSR 303 if/when you contribute the AS3 portion of the >> > implementation? Obviously we can't guarantee that Apache Flex will >> follow >> > that standard always. >> > >> >> An implementation of any JSR doesn't have to follow its evolution. At the >> time we wrote this code and because we are from the Java "world", we tried >> to follow the specification as far as possible and to guaranty that the >> Java validation would be consistent with the Flex one. It would be of >> course great to keep this tight compatibility, but the Flex implementation >> can evolve its own way, by adding specific features or even breaking the >> requisite of being a "certified" JSR-303 implementation. Any sound >> evolution is welcomed, we are not specification fundamentalists ;) >> >> >> > 4. What sort of performance implications can we expect with this >> > approach? Also, would it help if we make changes to the Flex compiler >> for >> > this to perform better? >> > >> >> As far as we know from our users, performances are very good. I don't see >> any compiler change that could specifically benefit to this framework: the >> only performance issue with BigDecimal is that it relies on 32-bits >> integers and computations would have been easier to implement and better >> performing if we could have used 64-bits long types. But this rather a >> Flash VM issue than a compiler one if I'm right. >> >> Thanks a lot for offering to contribute to Apache Flex! >> > >> >> You're welcome, thanks for your interest in our contribution offer. >> Franck. >> >> >> > >> > Regards, >> > Om >> > On Sep 24, 2012 7:40 AM, "Franck Wolff" <franck.wo...@graniteds.org> >> > wrote: >> > >> > > Hi Carlos, >> > > >> > > 2012/9/24 Carlos Rovira <carlos.rov...@codeoscopic.com> >> > > >> > > > Hi Franck, >> > > > >> > > > I think it would be great. I was in the way to make some >> > > > implementation some time ago since flex view validation is >> problematic >> > > > when you try to use MVC but I never get to far. In flex the problem >> is >> > > > that validation and view controls are dependent and it would be great >> > > > to have bean validation in order to validate data and have real >> > > > separation from the view. This brings the problem on how to show the >> > > > errors in controls to let the user now about a failed validation. I >> > > > suppose that is solved in GDS. >> > > > >> > > >> > > Yes, we have a specific component called FormValidator which displays >> > > errors in real-time, based on the user input. >> > > >> > > >> > > > So I think bean validation would be a great improvement in flex SDK >> > > > and annotations would make it more usable. >> > > > >> > > > For BigDecimal and others classes could be great as well, but I don't >> > > > have clear how could be donate to sdk...maybe it could go to an >> > > > extension package or something like that and get some externalization >> > > > base implementation... >> > > > >> > > >> > > An extension package is of course an option. >> > > >> > > Thanks for your quick feedback, >> > > Franck. >> > > >> > > 2012/9/24 Franck Wolff <franck.wo...@graniteds.org>: >> > > > > Hi All, >> > > > > >> > > > > We, at Granite Data Services <http://www.graniteds.org>, are >> > > considering >> > > > > contributing part of our Flex client code to this Apache project. >> Our >> > > > first >> > > > > thought is to contribute our Bean Validation (aka JSR-303) >> > > implementation >> > > > > in ActionScript3: this framework gives an easy and powerful way to >> > > > validate >> > > > > ActionScript beans based on constraint annotations (see >> documentation >> > > > > here< >> > > > >> > > >> > >> http://www.graniteds.org/public/docs/2.3.2/docs/reference/en-US/html/graniteds.validation.html >> > > > >). >> > > > > This framework can be used standalone, with no specific dependency >> to >> > > > rest >> > > > > of the GraniteDS platform, but is usually best used together with >> > Gas3 >> > > > (our >> > > > > code generation tool) which replicates Java entities annotated with >> > > > > constraint annotations in ActionScript3, with the same constraints. >> > The >> > > > > validation process can then be executed on the Flex, replicating >> what >> > > > Java >> > > > > is doing on its part, and can display error messages on the fly, >> > while >> > > > the >> > > > > user is filling out a Flex form. >> > > > > >> > > > > What do you think about such contribution? We could also contribute >> > > later >> > > > > our Flex implementation of the BigDecimal, BigInteger and Long >> > classes >> > > > (see >> > > > > documentation here< >> > > > >> > > >> > >> http://www.graniteds.org/public/docs/2.3.2/docs/reference/en-US/html/graniteds.bignumbers.html >> > > > >), >> > > > > but this implementation has a dependency on some externalization >> > > features >> > > > > specific to GraniteDS. >> > > > > >> > > > > Regards, >> > > > > -- >> > > > > Franck Wolff / William Draï >> > > > > Granite Data Services >> > > > >> > > > >> > > > >> > > > -- >> > > > Carlos Rovira >> > > > Director de Tecnología >> > > > M: +34 607 22 60 05 >> > > > F: +34 912 35 57 77 >> > > > CODEOSCOPIC S.A. >> > > > Avd. del General Perón, 32 >> > > > Planta 10, Puertas P-Q >> > > > 28020 Madrid >> > > > >> > > >> > > >> > > >> > > -- >> > > Franck Wolff >> > > Granite Data Services Inc. >> > > CEO & Founder >> > > >> > >> >> >> >> -- >> Franck Wolff >> Granite Data Services Inc. >> CEO & Founder >> -- Carlos Rovira Director de Tecnología M: +34 607 22 60 05 F: +34 912 35 57 77 CODEOSCOPIC S.A. Avd. del General Perón, 32 Planta 10, Puertas P-Q 28020 Madrid
