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 > > >
