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 Tue, 13 Nov 2012 17:49:11 GMT
Om,

Yes we are.

I think the best would be to commit our sources in the
trunk/frameworks/projects/experimental/src/ directory, changing our package
names to:

org.apache.flex.math (BigDecimal implementation)
org.apache.flex.reflect (Reflection API)
org.apache.flex.validation (Bean Validation implementation)

We would also need to change our headers, reflecting the Apache License (as
well as filling some legal forms I guess).

Then, the community could review the new source code and test a build
including the experimental new code. I'm not very familiar with the Apache
vote process but this submission could be accepted (or rejected) through a
vote and then included into the general framework release.

Does it sound reasonable? Would it be possible to get a full SVN access
during this process?

Thanks,
Franck.


2012/11/8 Om <bigosmallm@gmail.com>

> 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
> > >
> >
>



-- 
Franck Wolff
Granite Data Services Inc.
CEO & Founder

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message