You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@beehive.apache.org by Antony Chien <an...@gmail.com> on 2006/03/20 12:07:09 UTC
Control Versioning
Hi,
Reading controls javadoc, it comes to me that Control can be versioned.
However, there is currently no documentation, hence no way to play with it.
Can someone direct me on how to use Control versioning?
--
Regards,
Antony Chien
Re: Control Versioning
Posted by Antony Chien <an...@gmail.com>.
This is a great feature! We should market this feature, since this is what
Spring IOC is lacking.....
2006/3/29, Kenneth Tam <ke...@gmail.com>:
>
> Hi Anthony,
>
> Control interfaces (annotated with @ControlInterface) can have a
> version # associated with them, using the @Version annotation.
> Control authors are expected to define version #s for interfaces in
> terms of the semantics of the interface; ie, each distinct version #
> is defined by a particular set of semantic behaviours.
>
> Things that have a consumption dependency on control interfaces, such
> as field references (@Control) and control extensions
> (@ControlExtension) can use the @VersionRequired annotation which is
> says that they _require_ a certain version of the control interface
> (or greater) in order to get the semantics that they need.
>
> Things that have an implementation dependency on control interfaces,
> ie, control implementations (@ControlImplementation), can use the
> @VersionSupported annotation, which says that this implementation
> _supports_ the semantics defined by a certain version of the control
> interface (or less).
>
> Consider this example:
>
> @ControlInterface
> @Version( major=1 )
> public interface Account
> {
> // Semantics of v1 are that this method returns first name/last name
> String getCustomerFullName();
> }
>
> @ControlInterface
> @Version( major=2 )
> public interface Account
> {
> // Semantics of v2 are that this method returns first name/middle
> name/last name
> String getCustomerFullName();
> }
>
> @ControlImplementation
> @VersionSupported( major=1 )
> public class AccountImpl implements Account
> {
> String getCustomerFullName() { return _firstName + " " + _lastName; }
> }
>
> @ControlImplementation
> @VersionSupported( major=2 )
> public class AccountImpl implements Account
> {
> String getCustomerFullName() { return _firstName + " " + _midName
> + " " + _lastName; }
> }
>
> // Client code needs to get the middle name if it's present, thus
> requires v2 semantics
> ...
> @Control
> @VersionRequired( major=2)
> public Account _account;
> ...
>
> Now, if the client is compiling against an old distribution of the
> control interface which only has the v1 version, then it'll get a
> versioning error. If it compiles against the v2 version, but at
> deployment time is given only the v1 impl, it'll also get a versioning
> error.
>
> On 3/20/06, Antony Chien <an...@gmail.com> wrote:
> > Hi,
> > Reading controls javadoc, it comes to me that Control can be versioned.
> > However, there is currently no documentation, hence no way to play with
> it.
> > Can someone direct me on how to use Control versioning?
> >
> > --
> > Regards,
> > Antony Chien
> >
> >
>
--
Regards,
Antony Chien
Re: Control Versioning
Posted by Kenneth Tam <ke...@gmail.com>.
Hi Anthony,
Control interfaces (annotated with @ControlInterface) can have a
version # associated with them, using the @Version annotation.
Control authors are expected to define version #s for interfaces in
terms of the semantics of the interface; ie, each distinct version #
is defined by a particular set of semantic behaviours.
Things that have a consumption dependency on control interfaces, such
as field references (@Control) and control extensions
(@ControlExtension) can use the @VersionRequired annotation which is
says that they _require_ a certain version of the control interface
(or greater) in order to get the semantics that they need.
Things that have an implementation dependency on control interfaces,
ie, control implementations (@ControlImplementation), can use the
@VersionSupported annotation, which says that this implementation
_supports_ the semantics defined by a certain version of the control
interface (or less).
Consider this example:
@ControlInterface
@Version( major=1 )
public interface Account
{
// Semantics of v1 are that this method returns first name/last name
String getCustomerFullName();
}
@ControlInterface
@Version( major=2 )
public interface Account
{
// Semantics of v2 are that this method returns first name/middle
name/last name
String getCustomerFullName();
}
@ControlImplementation
@VersionSupported( major=1 )
public class AccountImpl implements Account
{
String getCustomerFullName() { return _firstName + " " + _lastName; }
}
@ControlImplementation
@VersionSupported( major=2 )
public class AccountImpl implements Account
{
String getCustomerFullName() { return _firstName + " " + _midName
+ " " + _lastName; }
}
// Client code needs to get the middle name if it's present, thus
requires v2 semantics
...
@Control
@VersionRequired( major=2)
public Account _account;
...
Now, if the client is compiling against an old distribution of the
control interface which only has the v1 version, then it'll get a
versioning error. If it compiles against the v2 version, but at
deployment time is given only the v1 impl, it'll also get a versioning
error.
On 3/20/06, Antony Chien <an...@gmail.com> wrote:
> Hi,
> Reading controls javadoc, it comes to me that Control can be versioned.
> However, there is currently no documentation, hence no way to play with it.
> Can someone direct me on how to use Control versioning?
>
> --
> Regards,
> Antony Chien
>
>
Re: Control Versioning
Posted by Kenneth Tam <ke...@gmail.com>.
Hi Anthony,
Control interfaces (annotated with @ControlInterface) can have a
version # associated with them, using the @Version annotation.
Control authors are expected to define version #s for interfaces in
terms of the semantics of the interface; ie, each distinct version #
is defined by a particular set of semantic behaviours.
Things that have a consumption dependency on control interfaces, such
as field references (@Control) and control extensions
(@ControlExtension) can use the @VersionRequired annotation which is
says that they _require_ a certain version of the control interface
(or greater) in order to get the semantics that they need.
Things that have an implementation dependency on control interfaces,
ie, control implementations (@ControlImplementation), can use the
@VersionSupported annotation, which says that this implementation
_supports_ the semantics defined by a certain version of the control
interface (or less).
Consider this example:
@ControlInterface
@Version( major=1 )
public interface Account
{
// Semantics of v1 are that this method returns first name/last name
String getCustomerFullName();
}
@ControlInterface
@Version( major=2 )
public interface Account
{
// Semantics of v2 are that this method returns first name/middle
name/last name
String getCustomerFullName();
}
@ControlImplementation
@VersionSupported( major=1 )
public class AccountImpl implements Account
{
String getCustomerFullName() { return _firstName + " " + _lastName; }
}
@ControlImplementation
@VersionSupported( major=2 )
public class AccountImpl implements Account
{
String getCustomerFullName() { return _firstName + " " + _midName
+ " " + _lastName; }
}
// Client code needs to get the middle name if it's present, thus
requires v2 semantics
...
@Control
@VersionRequired( major=2)
public Account _account;
...
Now, if the client is compiling against an old distribution of the
control interface which only has the v1 version, then it'll get a
versioning error. If it compiles against the v2 version, but at
deployment time is given only the v1 impl, it'll also get a versioning
error.
On 3/20/06, Antony Chien <an...@gmail.com> wrote:
> Hi,
> Reading controls javadoc, it comes to me that Control can be versioned.
> However, there is currently no documentation, hence no way to play with it.
> Can someone direct me on how to use Control versioning?
>
> --
> Regards,
> Antony Chien
>
>