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
