Hi Carlos, math & reflect (I forgot about this one) are mandatory. util & collections can certainly be refactored in order to lower dependencies. I need to check about that but, basically, we are ready to contribute all required code.
Thanks for your feedback, Franck. 2012/10/3 Carlos Rovira <carlos.rov...@codeoscopic.com> > 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 >
