Om, Yes we are.
I think the best would be to commit our sources in the trunk/frameworks/projects/experimental/src/ directory, changing our package names to: org.apache.flex.math (BigDecimal implementation) org.apache.flex.reflect (Reflection API) org.apache.flex.validation (Bean Validation implementation) We would also need to change our headers, reflecting the Apache License (as well as filling some legal forms I guess). Then, the community could review the new source code and test a build including the experimental new code. I'm not very familiar with the Apache vote process but this submission could be accepted (or rejected) through a vote and then included into the general framework release. Does it sound reasonable? Would it be possible to get a full SVN access during this process? Thanks, Franck. 2012/11/8 Om <bigosma...@gmail.com> > Franck, > > Sorry it a while for me to respond. I am assuming you are still interested > in contributing the validation framework to Apache Flex. Please let me > know how you would like to proceed. I have some free cycles and I can help > committing it to the codebase. > > Thanks, > Om > > On Wed, Oct 3, 2012 at 5:56 AM, Franck Wolff <franck.wo...@graniteds.org > >wrote: > > > The goal is of course to give the validation framework with the less > > possible dependencies. Refactoring is an option but it should be minimal > in > > order to preserve the current stability of our code (which is very good > so > > far). We don't want to contribute an untested, deeply modified and > > potentially unstable piece of code to Apache. > > > > Franck. > > > > 2012/10/3 Carlos Rovira <carlos.rov...@codeoscopic.com> > > > > > Hi Franck, > > > > > > IMHO the only problem I see is that user could end with dependent > > > frameworks that could be removed if some refactor is applyed, in this > > > case with reflect classes from granite and other microframework like > > > swiz, parsley or other. > > > > > > Maybe reflect classes could be cut to the minimun in order to drop > > > weight to minimum. Maybe math classes could be cut in the same way. In > > > both cases event refactored to be plug into other frameworks... > > > > > > > > > 2012/10/3 Franck Wolff <franck.wo...@graniteds.org>: > > > > 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 > > > >> > > > > > > > > > > > > -- > > > 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
