2:44 p.m.
Hi all,
As the title says: should we provide a way to access configured group
conversions via the meta-data API?
I'm undecided, I don't really see where this would be useful, OTOH we've
exposed all BV-related configurations via the meta-data API so far, so I
guess we probably should for the sake of completeness.
Thoughts?
--Gunnar
5:45 p.m.
We should.
The reason the metadata API is complete is so that non Java system can propagate the
constraints and logic of validation. Client side presentation framework was the canonical
example.
On 17 janv. 2013, at 21:44, Gunnar Morling <gunnar(a)hibernate.org> wrote:
Hi all,
As the title says: should we provide a way to access configured group conversions via the
meta-data API?
I'm undecided, I don't really see where this would be useful, OTOH we've
exposed all BV-related configurations via the meta-data API so far, so I guess we probably
should for the sake of completeness.
Thoughts?
--Gunnar
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
2:35 a.m.
We should.
Ok, I've created https://hibernate.onjira.com/browse/BVAL-361 for this.
--Gunnar
2013/1/18 Emmanuel Bernard <emmanuel(a)hibernate.org>
We should.
>
> The reason the metadata API is complete is so that non Java system can
> propagate the constraints and logic of validation. Client side presentation
> framework was the canonical example.
>
> On 17 janv. 2013, at 21:44, Gunnar Morling <gunnar(a)hibernate.org> wrote:
>
> > Hi all,
> >
> > As the title says: should we provide a way to access configured group
> conversions via the meta-data API?
> >
> > I'm undecided, I don't really see where this would be useful, OTOH
we've
> exposed all BV-related configurations via the meta-data API so far, so I
> guess we probably should for the sake of completeness.
> >
> > Thoughts?
> >
> > --Gunnar
> >
> > _______________________________________________
> > beanvalidation-dev mailing list
> > beanvalidation-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
3:39 p.m.
Hi all,
I think one natural way for representing group conversions in the metadata
API would be to add a method
Map<Class<?>, Class<?>> getGroupConversions()
to ParameterDescriptor, ReturnValueDescriptor and PropertyDescriptor
(that's also how conversions are represented internally in the RI).
Any thoughts on that, or other suggestions? If no one objects, I'd move
forward and add the method to the spec and API.
--Gunnar
2013/1/18 Gunnar Morling <gunnar(a)hibernate.org>
> We should.
Ok, I've created https://hibernate.onjira.com/browse/BVAL-361 for this.
--Gunnar
2013/1/18 Emmanuel Bernard <emmanuel(a)hibernate.org>
> We should.
>
> The reason the metadata API is complete is so that non Java system can
> propagate the constraints and logic of validation. Client side presentation
> framework was the canonical example.
>
> On 17 janv. 2013, at 21:44, Gunnar Morling <gunnar(a)hibernate.org> wrote:
>
> > Hi all,
> >
> > As the title says: should we provide a way to access configured group
> conversions via the meta-data API?
> >
> > I'm undecided, I don't really see where this would be useful, OTOH
> we've exposed all BV-related configurations via the meta-data API so far,
> so I guess we probably should for the sake of completeness.
> >
> > Thoughts?
> >
> > --Gunnar
> >
> > _______________________________________________
> > beanvalidation-dev mailing list
> > beanvalidation-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
6:09 a.m.
I'd rather have a GroupConversionDescriptor representing the from / to.
My reason is that if we add a new attribute to @ConvertGroup later, we
will be able to add it on the descriptor as well.
I think we tend to use a Set for the collection of elements in the spec.
So that would become a Set<GroupConvertionDescriptor>.
Emmanuel
On Wed 2013-01-30 22:39, Gunnar Morling wrote:
Hi all,
I think one natural way for representing group conversions in the metadata
API would be to add a method
Map<Class<?>, Class<?>> getGroupConversions()
to ParameterDescriptor, ReturnValueDescriptor and PropertyDescriptor
(that's also how conversions are represented internally in the RI).
Any thoughts on that, or other suggestions? If no one objects, I'd move
forward and add the method to the spec and API.
--Gunnar
2013/1/18 Gunnar Morling <gunnar(a)hibernate.org>
> > We should.
>
> Ok, I've created https://hibernate.onjira.com/browse/BVAL-361 for this.
>
> --Gunnar
>
>
> 2013/1/18 Emmanuel Bernard <emmanuel(a)hibernate.org>
>
>> We should.
>>
>> The reason the metadata API is complete is so that non Java system can
>> propagate the constraints and logic of validation. Client side presentation
>> framework was the canonical example.
>>
>> On 17 janv. 2013, at 21:44, Gunnar Morling <gunnar(a)hibernate.org> wrote:
>>
>> > Hi all,
>> >
>> > As the title says: should we provide a way to access configured group
>> conversions via the meta-data API?
>> >
>> > I'm undecided, I don't really see where this would be useful, OTOH
>> we've exposed all BV-related configurations via the meta-data API so far,
>> so I guess we probably should for the sake of completeness.
>> >
>> > Thoughts?
>> >
>> > --Gunnar
>> >
>> > _______________________________________________
>> > beanvalidation-dev mailing list
>> > beanvalidation-dev(a)lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>
>
>
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
6:43 a.m.
Yeah, that's a good point of course. I liked using a map as it very
naturally expressed that there may be only one rule per "from" type, but
making the API evolvable is more important I guess.
How about using ConvertGroup directly, i.e. return a Set<ConvertGroup>? In
that context the name doesn't read that well, but OTOH
GroupConvertionDescriptor
would more or less resemble ConvertGroup. WDYT?
2013/1/31 Emmanuel Bernard <emmanuel(a)hibernate.org>
I'd rather have a GroupConversionDescriptor representing the from
/ to.
My reason is that if we add a new attribute to @ConvertGroup later, we
will be able to add it on the descriptor as well.
I think we tend to use a Set for the collection of elements in the spec.
So that would become a Set<GroupConvertionDescriptor>.
Emmanuel
On Wed 2013-01-30 22:39, Gunnar Morling wrote:
> Hi all,
>
> I think one natural way for representing group conversions in the
metadata
> API would be to add a method
>
> Map<Class<?>, Class<?>> getGroupConversions()
>
> to ParameterDescriptor, ReturnValueDescriptor and PropertyDescriptor
> (that's also how conversions are represented internally in the RI).
>
> Any thoughts on that, or other suggestions? If no one objects, I'd move
> forward and add the method to the spec and API.
>
> --Gunnar
>
>
>
> 2013/1/18 Gunnar Morling <gunnar(a)hibernate.org>
>
> > > We should.
> >
> > Ok, I've created https://hibernate.onjira.com/browse/BVAL-361 for
this.
> >
> > --Gunnar
> >
> >
> > 2013/1/18 Emmanuel Bernard <emmanuel(a)hibernate.org>
> >
> >> We should.
> >>
> >> The reason the metadata API is complete is so that non Java system can
> >> propagate the constraints and logic of validation. Client side
presentation
> >> framework was the canonical example.
> >>
> >> On 17 janv. 2013, at 21:44, Gunnar Morling <gunnar(a)hibernate.org>
wrote:
> >>
> >> > Hi all,
> >> >
> >> > As the title says: should we provide a way to access configured
group
> >> conversions via the meta-data API?
> >> >
> >> > I'm undecided, I don't really see where this would be useful,
OTOH
> >> we've exposed all BV-related configurations via the meta-data API so
far,
> >> so I guess we probably should for the sake of completeness.
> >> >
> >> > Thoughts?
> >> >
> >> > --Gunnar
> >> >
> >> > _______________________________________________
> >> > beanvalidation-dev mailing list
> >> > beanvalidation-dev(a)lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >>
> >> _______________________________________________
> >> beanvalidation-dev mailing list
> >> beanvalidation-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >>
> >
> >
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
9:49 a.m.
I'm not sure. I think the annotation EG consider it bad practice and
implementation detail abouse to use the annotations as glorified interfaces.
In your case that's ok-ish (minor the XML DD) but if we want to add
behavior later on we might be stuck.
On Thu 2013-01-31 13:43, Gunnar Morling wrote:
Yeah, that's a good point of course. I liked using a map as it
very
naturally expressed that there may be only one rule per "from" type, but
making the API evolvable is more important I guess.
How about using ConvertGroup directly, i.e. return a Set<ConvertGroup>? In
that context the name doesn't read that well, but OTOH
GroupConvertionDescriptor
would more or less resemble ConvertGroup. WDYT?
2013/1/31 Emmanuel Bernard <emmanuel(a)hibernate.org>
> I'd rather have a GroupConversionDescriptor representing the from / to.
> My reason is that if we add a new attribute to @ConvertGroup later, we
> will be able to add it on the descriptor as well.
>
> I think we tend to use a Set for the collection of elements in the spec.
>
> So that would become a Set<GroupConvertionDescriptor>.
>
> Emmanuel
>
> On Wed 2013-01-30 22:39, Gunnar Morling wrote:
> > Hi all,
> >
> > I think one natural way for representing group conversions in the
> metadata
> > API would be to add a method
> >
> > Map<Class<?>, Class<?>> getGroupConversions()
> >
> > to ParameterDescriptor, ReturnValueDescriptor and PropertyDescriptor
> > (that's also how conversions are represented internally in the RI).
> >
> > Any thoughts on that, or other suggestions? If no one objects, I'd move
> > forward and add the method to the spec and API.
> >
> > --Gunnar
> >
> >
> >
> > 2013/1/18 Gunnar Morling <gunnar(a)hibernate.org>
> >
> > > > We should.
> > >
> > > Ok, I've created https://hibernate.onjira.com/browse/BVAL-361 for
> this.
> > >
> > > --Gunnar
> > >
> > >
> > > 2013/1/18 Emmanuel Bernard <emmanuel(a)hibernate.org>
> > >
> > >> We should.
> > >>
> > >> The reason the metadata API is complete is so that non Java system
can
> > >> propagate the constraints and logic of validation. Client side
> presentation
> > >> framework was the canonical example.
> > >>
> > >> On 17 janv. 2013, at 21:44, Gunnar Morling
<gunnar(a)hibernate.org>
> wrote:
> > >>
> > >> > Hi all,
> > >> >
> > >> > As the title says: should we provide a way to access configured
> group
> > >> conversions via the meta-data API?
> > >> >
> > >> > I'm undecided, I don't really see where this would be
useful, OTOH
> > >> we've exposed all BV-related configurations via the meta-data API
so
> far,
> > >> so I guess we probably should for the sake of completeness.
> > >> >
> > >> > Thoughts?
> > >> >
> > >> > --Gunnar
> > >> >
> > >> > _______________________________________________
> > >> > beanvalidation-dev mailing list
> > >> > beanvalidation-dev(a)lists.jboss.org
> > >> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> > >>
> > >> _______________________________________________
> > >> beanvalidation-dev mailing list
> > >> beanvalidation-dev(a)lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> > >>
> > >
> > >
>
> > _______________________________________________
> > beanvalidation-dev mailing list
> > beanvalidation-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
9:55 a.m.
Ok, then
Set<GroupConversionDescriptor> getGroupConversions()
it is.
Thanks,
--Gunnar
2013/1/31 Emmanuel Bernard <emmanuel(a)hibernate.org>
I'm not sure. I think the annotation EG consider it bad practice
and
implementation detail abouse to use the annotations as glorified
interfaces.
In your case that's ok-ish (minor the XML DD) but if we want to add
behavior later on we might be stuck.
On Thu 2013-01-31 13:43, Gunnar Morling wrote:
> Yeah, that's a good point of course. I liked using a map as it very
> naturally expressed that there may be only one rule per "from" type, but
> making the API evolvable is more important I guess.
>
> How about using ConvertGroup directly, i.e. return a Set<ConvertGroup>?
In
> that context the name doesn't read that well, but OTOH
> GroupConvertionDescriptor
> would more or less resemble ConvertGroup. WDYT?
>
>
> 2013/1/31 Emmanuel Bernard <emmanuel(a)hibernate.org>
>
> > I'd rather have a GroupConversionDescriptor representing the from / to.
> > My reason is that if we add a new attribute to @ConvertGroup later, we
> > will be able to add it on the descriptor as well.
> >
> > I think we tend to use a Set for the collection of elements in the
spec.
> >
> > So that would become a Set<GroupConvertionDescriptor>.
> >
> > Emmanuel
> >
> > On Wed 2013-01-30 22:39, Gunnar Morling wrote:
> > > Hi all,
> > >
> > > I think one natural way for representing group conversions in the
> > metadata
> > > API would be to add a method
> > >
> > > Map<Class<?>, Class<?>> getGroupConversions()
> > >
> > > to ParameterDescriptor, ReturnValueDescriptor and PropertyDescriptor
> > > (that's also how conversions are represented internally in the RI).
> > >
> > > Any thoughts on that, or other suggestions? If no one objects, I'd
move
> > > forward and add the method to the spec and API.
> > >
> > > --Gunnar
> > >
> > >
> > >
> > > 2013/1/18 Gunnar Morling <gunnar(a)hibernate.org>
> > >
> > > > > We should.
> > > >
> > > > Ok, I've created https://hibernate.onjira.com/browse/BVAL-361
for
> > this.
> > > >
> > > > --Gunnar
> > > >
> > > >
> > > > 2013/1/18 Emmanuel Bernard <emmanuel(a)hibernate.org>
> > > >
> > > >> We should.
> > > >>
> > > >> The reason the metadata API is complete is so that non Java
system can
> > > >> propagate the constraints and logic of validation. Client side
> > presentation
> > > >> framework was the canonical example.
> > > >>
> > > >> On 17 janv. 2013, at 21:44, Gunnar Morling
<gunnar(a)hibernate.org>
> > wrote:
> > > >>
> > > >> > Hi all,
> > > >> >
> > > >> > As the title says: should we provide a way to access
configured
> > group
> > > >> conversions via the meta-data API?
> > > >> >
> > > >> > I'm undecided, I don't really see where this would
be useful,
OTOH
> > > >> we've exposed all BV-related configurations via the meta-data
API
so
> > far,
> > > >> so I guess we probably should for the sake of completeness.
> > > >> >
> > > >> > Thoughts?
> > > >> >
> > > >> > --Gunnar
> > > >> >
> > > >> > _______________________________________________
> > > >> > beanvalidation-dev mailing list
> > > >> > beanvalidation-dev(a)lists.jboss.org
> > > >> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> > > >>
> > > >> _______________________________________________
> > > >> beanvalidation-dev mailing list
> > > >> beanvalidation-dev(a)lists.jboss.org
> > > >> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> > > >>
> > > >
> > > >
> >
> > > _______________________________________________
> > > beanvalidation-dev mailing list
> > > beanvalidation-dev(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >
> > _______________________________________________
> > beanvalidation-dev mailing list
> > beanvalidation-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
4347
days inactive
4361
days old
beanvalidation-dev@lists.jboss.org
7 comments
2 participants
participants (2)
-
Emmanuel Bernard -
Gunnar Morling