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 >
