Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of frawolff@gmail.com designates
 209.85.216.175 as permitted sender)
MIME-Version: 1.0
Sender: frawolff@gmail.com
In-Reply-To: 
 <CAMFKFRj+QHo-kn3qLm1iu7o95Y0=e9ezVQTuBtFwi2M7gOJ6Xw@mail.gmail.com>
References: 
 <CAHo_kB6cMczHxz1_xzE+uivMVnby_5Ce4XqFYcUxruRqQAiCDg@mail.gmail.com>
	<CAMFKFRgvQM29rHsHP8bxW4yqTAtgBxbYghCmiR_xD_Gt_FuD6g@mail.gmail.com>
	<CAHo_kB5jUJqcUzKYUxZYEO6Hi8kw8F8vqbhHwFp_OqXjAO_aqw@mail.gmail.com>
	<CACK5iZcWYL4kJptBufx-vB9gnsYOPjTcTpPCXvU+rxQSBqByBA@mail.gmail.com>
	<CAHo_kB6XKmNDkescUov7zpVzQoR6BX=CAttp5ZWEedaTBqsTag@mail.gmail.com>
	<CACK5iZe=mJ8jctbhZvmcUM8mwaqBf7r_AWqsNr4XCDpEh5MkOQ@mail.gmail.com>
	<CAMFKFRj+QHo-kn3qLm1iu7o95Y0=e9ezVQTuBtFwi2M7gOJ6Xw@mail.gmail.com>
Date: Wed, 3 Oct 2012 13:03:57 +0200
Message-ID: 
 <CAHo_kB7TUQK=_eXfX9szexxiia=y5FbX6JdKbejaqeXG+vLMVA@mail.gmail.com>
Subject: Re: Proposal for contributing code from GraniteDS
From: Franck Wolff <franck.wolff@graniteds.org>
To: flex-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=00248c7117c76335c704cb2598dc

--00248c7117c76335c704cb2598dc
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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 wou=
ld
> >> 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 specifi=
c
> >> > 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 jus=
t
> 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 validati=
on
> >> 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 wi=
th
> >> 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 Ja=
va
> >>    server-side solution: it comes from a specification written for Jav=
a
> 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 t=
he
> >> 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 a=
n
> >> > 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, bu=
t
> 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 o=
f
> 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 th=
e
> >> 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 t=
he
> >> 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 bett=
er
> >> 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 wa=
y
> 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/gran=
iteds.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, replicati=
ng
> >> what
> >> > > > Java
> >> > > > > is doing on its part, and can display error messages on the fl=
y,
> >> > 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/gran=
iteds.bignumbers.html
> >> > > > >),
> >> > > > > but this implementation has a dependency on some externalizati=
on
> >> > > features
> >> > > > > specific to GraniteDS.
> >> > > > >
> >> > > > > Regards,
> >> > > > > --
> >> > > > > Franck Wolff / William Dra=EF
> >> > > > > Granite Data Services
> >> > > >
> >> > > >
> >> > > >
> >> > > > --
> >> > > > Carlos Rovira
> >> > > > Director de Tecnolog=EDa
> >> > > > M: +34 607 22 60 05
> >> > > > F:  +34 912 35 57 77
> >> > > > CODEOSCOPIC S.A.
> >> > > > Avd. del General Per=F3n, 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=EDa
> M: +34 607 22 60 05
> F:  +34 912 35 57 77
> CODEOSCOPIC S.A.
> Avd. del General Per=F3n, 32
> Planta 10, Puertas P-Q
> 28020 Madrid
>

--00248c7117c76335c704cb2598dc--