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, 26 Sep 2012 10:07:00 GMT
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