incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Om <bigosma...@gmail.com>
Subject Re: Proposal for contributing code from GraniteDS
Date Tue, 02 Oct 2012 21:36:16 GMT
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.wolff@graniteds.org>wrote:

> Om,
>
> 2012/9/25 Om <bigosmallm@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.wolff@graniteds.org>
> > wrote:
> >
> > > Hi Carlos,
> > >
> > > 2012/9/24 Carlos Rovira <carlos.rovira@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.wolff@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message