RE: [JBoss-dev] Feature request, dev assignments
OK, you're the chief, I trust you!
> -Message d'origine-
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]De la part de Dain
> Sundstrom
> Envoye : mercredi, 29 janvier 2003 18:49
> A : [EMAIL PROTECTED]
> Objet : Re: [JBoss-dev] Feature request, dev assignments
>
>
> I don't know, but we could create our own listener to support modifying
> the value. I'll have to think about the implications that. We plan on
> supporting notifications from the backend also, so changing the value
> may be problematic. You will also be able to have many entities fields
> mapped to the same column. . . . Maybe we should have two listener
> interfaces: one for local changes and one for backend changes. Anyway,
> I simply prefer a listener approach to an implicit method call.
>
> -dain
>
> On Wednesday, January 29, 2003, at 11:40 AM, Sacha Labourey wrote:
>
> > But would this allow some observer to modify the actual content of
> > what is
> > set (setter) or returned (getters)? This is the second part of the
> > interest
> > IMHO.
> >
> >> -Message d'origine-
> >> De : [EMAIL PROTECTED]
> >> [mailto:[EMAIL PROTECTED]]De la part de
> >> Dain
> >> Sundstrom
> >> Envoye : mercredi, 29 janvier 2003 18:35
> >> A : [EMAIL PROTECTED]
> >> Objet : Re: [JBoss-dev] Feature request, dev assignments
> >>
> >>
> >> Sacha,
> >>
> >> What you suggest would require rewriting the byte code generator,
> >> which
> >> I didn't write. Currently all the implementation of the abstract
> >> methods does is call an invocation handler.
> >>
> >> I do really like the idea of the PropertyChange[Veto]Listener and have
> >> already added it to the task list. This fits into our (the cmp team)
> >> plans to add change notification (observer pattern).
> >>
> >> -dain
> >>
> >> On Wednesday, January 29, 2003, at 01:45 AM, Sacha Labourey wrote:
> >>
> >>> Dain,
> >>>
> >>> I agree, this is some of a hack, but any trick would be hack because
> >>> it
> >>> requires the container to implicitly do some call. What your
> >>> container
> >>> bytecode implementation generates is something like that (very
> >>> pseudo-code
> >>> as we all know it is something like "invoke"):
> >>>
> >>> public void setXXX (Object bla)
> >>> {
> >>> doMyPersistenceThingForXXX();
> >>> }
> >>>
> >>> I was only suggesting something like:
> >>>
> >>> public void setXXX (Object bla)
> >>> {
> >>> if (XXXSeterImplementedBySuperClass())
> >>> super.setXXX(bla);
> >>> doMyPersistenceThingForXXX();
> >>> }
> >>>
> >>> Pro:
> >>> - very simple for both your code and the developer code
> >>> - no need to have 2x the same setters (or getter if you
> >> want to decode
> >>> stuff)
> >>>
> >>> Cons:
> >>> - proprietary
> >>> - you could just (setters) deny access by throwing an exception but
> >>> not
> >>> modify the actual content of what is stored. This is a real miss. The
> >>> Veto
> >>> thing would also need to be extended for this. Some people have to
> >>> trim
> >>> white spaces for example.
> >>>
> >>> Nothing magic here.
> >>>
> >>> cheers
> >>>
> >>> sacha
> >>>
> >>>> -Message d'origine-
> >>>> De : [EMAIL PROTECTED]
> >>>> [mailto:[EMAIL PROTECTED]]De la part de
> >>>> Dain
> >>>> Sundstrom
> >>>> Envoye : mardi, 28 janvier 2003 01:56
> >>>> A : [EMAIL PROTECTED]
> >>>> Objet : Re: [JBoss-dev] Feature request, dev assignments
> >>>>
> >>>>
> >>>> I never really liked this idea. I think you should provide a
> >>>> concrete
> >>>> setPostalCode (String code) method and if the data is valid you
> >>>> would
> >>>> call setPostalCodeField (String code) or setPostalCode_(String
> >>>> code).
> >>>> I think this type of validation is part of the business logic.
> >>>> Alternatively, there are types
Re: [JBoss-dev] Feature request, dev assignments
I don't know, but we could create our own listener to support modifying
the value. I'll have to think about the implications that. We plan on
supporting notifications from the backend also, so changing the value
may be problematic. You will also be able to have many entities fields
mapped to the same column. . . . Maybe we should have two listener
interfaces: one for local changes and one for backend changes. Anyway,
I simply prefer a listener approach to an implicit method call.
-dain
On Wednesday, January 29, 2003, at 11:40 AM, Sacha Labourey wrote:
But would this allow some observer to modify the actual content of
what is
set (setter) or returned (getters)? This is the second part of the
interest
IMHO.
-Message d'origine-
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]De la part de
Dain
Sundstrom
Envoye : mercredi, 29 janvier 2003 18:35
A : [EMAIL PROTECTED]
Objet : Re: [JBoss-dev] Feature request, dev assignments
Sacha,
What you suggest would require rewriting the byte code generator,
which
I didn't write. Currently all the implementation of the abstract
methods does is call an invocation handler.
I do really like the idea of the PropertyChange[Veto]Listener and have
already added it to the task list. This fits into our (the cmp team)
plans to add change notification (observer pattern).
-dain
On Wednesday, January 29, 2003, at 01:45 AM, Sacha Labourey wrote:
Dain,
I agree, this is some of a hack, but any trick would be hack because
it
requires the container to implicitly do some call. What your
container
bytecode implementation generates is something like that (very
pseudo-code
as we all know it is something like "invoke"):
public void setXXX (Object bla)
{
doMyPersistenceThingForXXX();
}
I was only suggesting something like:
public void setXXX (Object bla)
{
if (XXXSeterImplementedBySuperClass())
super.setXXX(bla);
doMyPersistenceThingForXXX();
}
Pro:
- very simple for both your code and the developer code
- no need to have 2x the same setters (or getter if you
want to decode
stuff)
Cons:
- proprietary
- you could just (setters) deny access by throwing an exception but
not
modify the actual content of what is stored. This is a real miss. The
Veto
thing would also need to be extended for this. Some people have to
trim
white spaces for example.
Nothing magic here.
cheers
sacha
-Message d'origine-
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]De la part de
Dain
Sundstrom
Envoye : mardi, 28 janvier 2003 01:56
A : [EMAIL PROTECTED]
Objet : Re: [JBoss-dev] Feature request, dev assignments
I never really liked this idea. I think you should provide a
concrete
setPostalCode (String code) method and if the data is valid you
would
call setPostalCodeField (String code) or setPostalCode_(String
code).
I think this type of validation is part of the business logic.
Alternatively, there are types of validation that are really an
aspect
(deployment environment specific). For example, a company specific
mail route field. The validation of this field would depend on the
deployment environment (which company it is deployed at). In this
case
I see an interceptor, possibly a Bean Scripting Framework
interceptor.
What I am getting at is I think this proposed solution is a hack
and I
personally would not accept the patch, but the user community has
convinced me to include things I consider hacks.
-dain
On Monday, January 27, 2003, at 08:31 AM, Themba Mbatha wrote:
Hi all;
What would be the procedure if one is interested in implementing a
feature request? There is a feature request (647669) that I also
need
a.s.a.p. and I'm prepared to contribute the implementation once I'm
done.
Regards.
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2
See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld
RE: [JBoss-dev] Feature request, dev assignments
But would this allow some observer to modify the actual content of what is
set (setter) or returned (getters)? This is the second part of the interest
IMHO.
> -Message d'origine-
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]De la part de Dain
> Sundstrom
> Envoye : mercredi, 29 janvier 2003 18:35
> A : [EMAIL PROTECTED]
> Objet : Re: [JBoss-dev] Feature request, dev assignments
>
>
> Sacha,
>
> What you suggest would require rewriting the byte code generator, which
> I didn't write. Currently all the implementation of the abstract
> methods does is call an invocation handler.
>
> I do really like the idea of the PropertyChange[Veto]Listener and have
> already added it to the task list. This fits into our (the cmp team)
> plans to add change notification (observer pattern).
>
> -dain
>
> On Wednesday, January 29, 2003, at 01:45 AM, Sacha Labourey wrote:
>
> > Dain,
> >
> > I agree, this is some of a hack, but any trick would be hack because it
> > requires the container to implicitly do some call. What your container
> > bytecode implementation generates is something like that (very
> > pseudo-code
> > as we all know it is something like "invoke"):
> >
> > public void setXXX (Object bla)
> > {
> > doMyPersistenceThingForXXX();
> > }
> >
> > I was only suggesting something like:
> >
> > public void setXXX (Object bla)
> > {
> > if (XXXSeterImplementedBySuperClass())
> > super.setXXX(bla);
> > doMyPersistenceThingForXXX();
> > }
> >
> > Pro:
> > - very simple for both your code and the developer code
> > - no need to have 2x the same setters (or getter if you
> want to decode
> > stuff)
> >
> > Cons:
> > - proprietary
> > - you could just (setters) deny access by throwing an exception but
> > not
> > modify the actual content of what is stored. This is a real miss. The
> > Veto
> > thing would also need to be extended for this. Some people have to trim
> > white spaces for example.
> >
> > Nothing magic here.
> >
> > cheers
> >
> > sacha
> >
> >> -Message d'origine-
> >> De : [EMAIL PROTECTED]
> >> [mailto:[EMAIL PROTECTED]]De la part de
> >> Dain
> >> Sundstrom
> >> Envoye : mardi, 28 janvier 2003 01:56
> >> A : [EMAIL PROTECTED]
> >> Objet : Re: [JBoss-dev] Feature request, dev assignments
> >>
> >>
> >> I never really liked this idea. I think you should provide a concrete
> >> setPostalCode (String code) method and if the data is valid you would
> >> call setPostalCodeField (String code) or setPostalCode_(String code).
> >> I think this type of validation is part of the business logic.
> >> Alternatively, there are types of validation that are really an aspect
> >> (deployment environment specific). For example, a company specific
> >> mail route field. The validation of this field would depend on the
> >> deployment environment (which company it is deployed at). In this
> >> case
> >> I see an interceptor, possibly a Bean Scripting Framework interceptor.
> >>
> >> What I am getting at is I think this proposed solution is a hack and I
> >> personally would not accept the patch, but the user community has
> >> convinced me to include things I consider hacks.
> >>
> >> -dain
> >>
> >> On Monday, January 27, 2003, at 08:31 AM, Themba Mbatha wrote:
> >>
> >>> Hi all;
> >>>
> >>> What would be the procedure if one is interested in implementing a
> >>> feature request? There is a feature request (647669) that I also need
> >>> a.s.a.p. and I'm prepared to contribute the implementation once I'm
> >>> done.
> >>>
> >>> Regards.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> ---
> >>> This SF.NET email is sponsored by:
> >>> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> >>> http://www.vasoftware.com
> >>> ___
> >>> Jboss-development mailing list
> >>> [EMAIL PROTECTED]
> >>> https://lists.sourceforge.net/lists/listinfo/jboss-development
> >>
> >>
> >>
> >> --
Re: [JBoss-dev] Feature request, dev assignments
Sacha,
What you suggest would require rewriting the byte code generator, which
I didn't write. Currently all the implementation of the abstract
methods does is call an invocation handler.
I do really like the idea of the PropertyChange[Veto]Listener and have
already added it to the task list. This fits into our (the cmp team)
plans to add change notification (observer pattern).
-dain
On Wednesday, January 29, 2003, at 01:45 AM, Sacha Labourey wrote:
Dain,
I agree, this is some of a hack, but any trick would be hack because it
requires the container to implicitly do some call. What your container
bytecode implementation generates is something like that (very
pseudo-code
as we all know it is something like "invoke"):
public void setXXX (Object bla)
{
doMyPersistenceThingForXXX();
}
I was only suggesting something like:
public void setXXX (Object bla)
{
if (XXXSeterImplementedBySuperClass())
super.setXXX(bla);
doMyPersistenceThingForXXX();
}
Pro:
- very simple for both your code and the developer code
- no need to have 2x the same setters (or getter if you want to decode
stuff)
Cons:
- proprietary
- you could just (setters) deny access by throwing an exception but
not
modify the actual content of what is stored. This is a real miss. The
Veto
thing would also need to be extended for this. Some people have to trim
white spaces for example.
Nothing magic here.
cheers
sacha
-Message d'origine-
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]De la part de
Dain
Sundstrom
Envoye : mardi, 28 janvier 2003 01:56
A : [EMAIL PROTECTED]
Objet : Re: [JBoss-dev] Feature request, dev assignments
I never really liked this idea. I think you should provide a concrete
setPostalCode (String code) method and if the data is valid you would
call setPostalCodeField (String code) or setPostalCode_(String code).
I think this type of validation is part of the business logic.
Alternatively, there are types of validation that are really an aspect
(deployment environment specific). For example, a company specific
mail route field. The validation of this field would depend on the
deployment environment (which company it is deployed at). In this
case
I see an interceptor, possibly a Bean Scripting Framework interceptor.
What I am getting at is I think this proposed solution is a hack and I
personally would not accept the patch, but the user community has
convinced me to include things I consider hacks.
-dain
On Monday, January 27, 2003, at 08:31 AM, Themba Mbatha wrote:
Hi all;
What would be the procedure if one is interested in implementing a
feature request? There is a feature request (647669) that I also need
a.s.a.p. and I'm prepared to contribute the implementation once I'm
done.
Regards.
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Feature request, dev assignments
Dain,
I agree, this is some of a hack, but any trick would be hack because it
requires the container to implicitly do some call. What your container
bytecode implementation generates is something like that (very pseudo-code
as we all know it is something like "invoke"):
public void setXXX (Object bla)
{
doMyPersistenceThingForXXX();
}
I was only suggesting something like:
public void setXXX (Object bla)
{
if (XXXSeterImplementedBySuperClass())
super.setXXX(bla);
doMyPersistenceThingForXXX();
}
Pro:
- very simple for both your code and the developer code
- no need to have 2x the same setters (or getter if you want to decode
stuff)
Cons:
- proprietary
- you could just (setters) deny access by throwing an exception but not
modify the actual content of what is stored. This is a real miss. The Veto
thing would also need to be extended for this. Some people have to trim
white spaces for example.
Nothing magic here.
cheers
sacha
> -Message d'origine-
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]De la part de Dain
> Sundstrom
> Envoye : mardi, 28 janvier 2003 01:56
> A : [EMAIL PROTECTED]
> Objet : Re: [JBoss-dev] Feature request, dev assignments
>
>
> I never really liked this idea. I think you should provide a concrete
> setPostalCode (String code) method and if the data is valid you would
> call setPostalCodeField (String code) or setPostalCode_(String code).
> I think this type of validation is part of the business logic.
> Alternatively, there are types of validation that are really an aspect
> (deployment environment specific). For example, a company specific
> mail route field. The validation of this field would depend on the
> deployment environment (which company it is deployed at). In this case
> I see an interceptor, possibly a Bean Scripting Framework interceptor.
>
> What I am getting at is I think this proposed solution is a hack and I
> personally would not accept the patch, but the user community has
> convinced me to include things I consider hacks.
>
> -dain
>
> On Monday, January 27, 2003, at 08:31 AM, Themba Mbatha wrote:
>
> > Hi all;
> >
> > What would be the procedure if one is interested in implementing a
> > feature request? There is a feature request (647669) that I also need
> > a.s.a.p. and I'm prepared to contribute the implementation once I'm
> > done.
> >
> > Regards.
> >
> >
> >
> >
> >
> > ---
> > This SF.NET email is sponsored by:
> > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> > http://www.vasoftware.com
> > ___
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
>
> ---
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Feature request, dev assignments
On Tuesday, January 28, 2003, at 01:52 AM, Themba Mbatha wrote: I never really liked this idea. By this I'm assuming you are referring to the JavaBean listener interfaces (PropertyChangeListener and PropertyVetoChangeListener) as a possible solution. No, that would be super cool. I just don't like the idea of us automatically calling a validateMyAttribute method. This is a great idea. We can implement this just like we do the Synchronization interface for stateful session beans; if it is there we notify the implementation. -dain --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Feature request, dev assignments
> I never really liked this idea. By this I'm assuming you are referring to the JavaBean listener interfaces (PropertyChangeListener and PropertyVetoChangeListener) as a possible solution. > I think you should provide a concrete > setPostalCode (String code) method and if the data is valid you would > call setPostalCodeField (String code) or setPostalCode_(String code). The are two limitations that make this impossible currently: - JBoss doesn't generate code that extend the abstract entity beans for the creation of instances later. My understanding is that it introspect them and create a property set of key/value which then intercepts invocations for the contained entity beans. - The spec requires CMPs to be abstract objects and enable the container to provide an implementation of each bean. > Alternatively, there are types of validation that are really an aspect > (deployment environment specific). For example, a company specific > mail route field. The validation of this field would depend on the > deployment environment (which company it is deployed at). In this case > I see an interceptor, possibly a Bean Scripting Framework interceptor. I will study this further, it should add great dynamism onto the entire implementation. > What I am getting at is I think this proposed solution is a hack and I > personally would not accept the patch, but the user community has > convinced me to include things I consider hacks. Let's give it a try, critic it, improve it further. It might become a nice feature. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Feature request, dev assignments
I never really liked this idea. I think you should provide a concrete setPostalCode (String code) method and if the data is valid you would call setPostalCodeField (String code) or setPostalCode_(String code). I think this type of validation is part of the business logic. Alternatively, there are types of validation that are really an aspect (deployment environment specific). For example, a company specific mail route field. The validation of this field would depend on the deployment environment (which company it is deployed at). In this case I see an interceptor, possibly a Bean Scripting Framework interceptor. What I am getting at is I think this proposed solution is a hack and I personally would not accept the patch, but the user community has convinced me to include things I consider hacks. -dain On Monday, January 27, 2003, at 08:31 AM, Themba Mbatha wrote: Hi all; What would be the procedure if one is interested in implementing a feature request? There is a feature request (647669) that I also need a.s.a.p. and I'm prepared to contribute the implementation once I'm done. Regards. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Feature request, dev assignments
Hi all; What would be the procedure if one is interested in implementing a feature request? There is a feature request (647669) that I also need a.s.a.p. and I'm prepared to contribute the implementation once I'm done. Regards. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
