incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Rovira <carlos.rov...@codeoscopic.com>
Subject Re: Proposal for contributing code from GraniteDS
Date Wed, 03 Oct 2012 10:49:01 GMT
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
View raw message