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 12:56:36 GMT
The goal is of course to give the validation framework with the less
possible dependencies. Refactoring is an option but it should be minimal in
order to preserve the current stability of our code (which is very good so
far). We don't want to contribute an untested, deeply modified and
potentially unstable piece of code to Apache.

Franck.

2012/10/3 Carlos Rovira <carlos.rovira@codeoscopic.com>

> Hi Franck,
>
> IMHO the only problem I see is that user could end with dependent
> frameworks that could be removed if some refactor is applyed, in this
> case with reflect classes from granite and other microframework like
> swiz, parsley or other.
>
> Maybe reflect classes could be cut to the minimun in order to drop
> weight to minimum. Maybe math classes could be cut in the same way. In
> both cases event refactored to be plug into other frameworks...
>
>
> 2012/10/3 Franck Wolff <franck.wolff@graniteds.org>:
> > 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
> >>
>
>
>
> --
> 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