incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Om <bigosma...@gmail.com>
Subject Re: Proposal for contributing code from GraniteDS
Date Fri, 09 Nov 2012 00:49:07 GMT
Franck,

Sorry it a while for me to respond. I am assuming you are still interested
in contributing the validation framework to Apache Flex.  Please let me
know how you would like to proceed.  I have some free cycles and I can help
committing it to the codebase.

Thanks,
Om

On Wed, Oct 3, 2012 at 5:56 AM, Franck Wolff <franck.wolff@graniteds.org>wrote:

> 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