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
