incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Franck Wolff <franck.wo...@graniteds.org>
Subject Re: Proposal for contributing code from GraniteDS
Date Wed, 03 Oct 2012 11:03:57 GMT
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.rovira@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 <bigosmallm@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.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
> >>
>
>
>
> --
> 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
>

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