You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@beehive.apache.org by "Kyle Marvin (JIRA)" <be...@incubator.apache.org> on 2005/02/25 21:38:48 UTC
[jira] Created: (BEEHIVE-364) Enable classes to be used as contextual services for controls
Enable classes to be used as contextual services for controls
-------------------------------------------------------------
Key: BEEHIVE-364
URL: http://issues.apache.org/jira/browse/BEEHIVE-364
Project: Beehive
Type: Improvement
Components: Controls
Versions: V1Beta
Reporter: Kyle Marvin
Assigned to: Kyle Marvin
Fix For: V1Beta
Currently, the Controls annotation processor requires that any field annotated by @Context be of an interface (not a class) type. There is really no reason why a class can't act as a contextual service... the base JavaBeans contextual service model upon which this is built does not require this.
Rich Feit would like to expose PageFlowController for controls running inside of a pageflow, but it is a class.
The core issue here is that APT control processing uses AptControlInterface for both control and context fields... but the validation rules actually need to differ.
The right thing is to add an intermediate abstract AptEventSource that represents a type that can declare (and deliver events) and then have AptControlInterface and AptContextType that derive from it. So a little refactoring should enable it to be fixed.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Updated: (BEEHIVE-364) Enable classes to be used as contextual services for controls
Posted by "Kyle Marvin (JIRA)" <be...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/BEEHIVE-364?page=all ]
Kyle Marvin updated BEEHIVE-364:
--------------------------------
type: Bug (was: Improvement)
Reclassifying as a bug since this is actually blocking a desired use case for Pageflows.
> Enable classes to be used as contextual services for controls
> -------------------------------------------------------------
>
> Key: BEEHIVE-364
> URL: http://issues.apache.org/jira/browse/BEEHIVE-364
> Project: Beehive
> Type: Bug
> Components: Controls
> Versions: V1Beta
> Reporter: Kyle Marvin
> Assignee: Kyle Marvin
> Fix For: V1
>
> Currently, the Controls annotation processor requires that any field annotated by @Context be of an interface (not a class) type. There is really no reason why a class can't act as a contextual service... the base JavaBeans contextual service model upon which this is built does not require this.
> Rich Feit would like to expose PageFlowController for controls running inside of a pageflow, but it is a class.
> The core issue here is that APT control processing uses AptControlInterface for both control and context fields... but the validation rules actually need to differ.
> The right thing is to add an intermediate abstract AptEventSource that represents a type that can declare (and deliver events) and then have AptControlInterface and AptContextType that derive from it. So a little refactoring should enable it to be fixed.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (BEEHIVE-364) Enable classes to be used as contextual services for controls
Posted by "Eddie O'Neil (JIRA)" <be...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/BEEHIVE-364?page=all ]
Eddie O'Neil closed BEEHIVE-364:
--------------------------------
Closing as per Jacob's comment.
> Enable classes to be used as contextual services for controls
> -------------------------------------------------------------
>
> Key: BEEHIVE-364
> URL: http://issues.apache.org/jira/browse/BEEHIVE-364
> Project: Beehive
> Type: Bug
> Components: Controls
> Versions: V1Beta
> Reporter: Kyle Marvin
> Assignee: Kyle Marvin
> Fix For: v1m1
>
> Currently, the Controls annotation processor requires that any field annotated by @Context be of an interface (not a class) type. There is really no reason why a class can't act as a contextual service... the base JavaBeans contextual service model upon which this is built does not require this.
> Rich Feit would like to expose PageFlowController for controls running inside of a pageflow, but it is a class.
> The core issue here is that APT control processing uses AptControlInterface for both control and context fields... but the validation rules actually need to differ.
> The right thing is to add an intermediate abstract AptEventSource that represents a type that can declare (and deliver events) and then have AptControlInterface and AptContextType that derive from it. So a little refactoring should enable it to be fixed.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (BEEHIVE-364) Enable classes to be used as contextual services for controls
Posted by "Kyle Marvin (JIRA)" <be...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/BEEHIVE-364?page=history ]
Kyle Marvin updated BEEHIVE-364:
--------------------------------
Fix Version: V1
(was: V1Beta)
> Enable classes to be used as contextual services for controls
> -------------------------------------------------------------
>
> Key: BEEHIVE-364
> URL: http://issues.apache.org/jira/browse/BEEHIVE-364
> Project: Beehive
> Type: Improvement
> Components: Controls
> Versions: V1Beta
> Reporter: Kyle Marvin
> Assignee: Kyle Marvin
> Fix For: V1
>
> Currently, the Controls annotation processor requires that any field annotated by @Context be of an interface (not a class) type. There is really no reason why a class can't act as a contextual service... the base JavaBeans contextual service model upon which this is built does not require this.
> Rich Feit would like to expose PageFlowController for controls running inside of a pageflow, but it is a class.
> The core issue here is that APT control processing uses AptControlInterface for both control and context fields... but the validation rules actually need to differ.
> The right thing is to add an intermediate abstract AptEventSource that represents a type that can declare (and deliver events) and then have AptControlInterface and AptContextType that derive from it. So a little refactoring should enable it to be fixed.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Commented: (BEEHIVE-364) Enable classes to be used as contextual services for controls
Posted by "Jacob Danner (JIRA)" <be...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/BEEHIVE-364?page=comments#action_12319334 ]
Jacob Danner commented on BEEHIVE-364:
--------------------------------------
I think this can be closed
-Jacobd
> Enable classes to be used as contextual services for controls
> -------------------------------------------------------------
>
> Key: BEEHIVE-364
> URL: http://issues.apache.org/jira/browse/BEEHIVE-364
> Project: Beehive
> Type: Bug
> Components: Controls
> Versions: V1Beta
> Reporter: Kyle Marvin
> Assignee: Kyle Marvin
> Fix For: v1m1
>
> Currently, the Controls annotation processor requires that any field annotated by @Context be of an interface (not a class) type. There is really no reason why a class can't act as a contextual service... the base JavaBeans contextual service model upon which this is built does not require this.
> Rich Feit would like to expose PageFlowController for controls running inside of a pageflow, but it is a class.
> The core issue here is that APT control processing uses AptControlInterface for both control and context fields... but the validation rules actually need to differ.
> The right thing is to add an intermediate abstract AptEventSource that represents a type that can declare (and deliver events) and then have AptControlInterface and AptContextType that derive from it. So a little refactoring should enable it to be fixed.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Resolved: (BEEHIVE-364) Enable classes to be used as contextual services for controls
Posted by "Kyle Marvin (JIRA)" <be...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/BEEHIVE-364?page=all ]
Kyle Marvin resolved BEEHIVE-364:
---------------------------------
Resolution: Fixed
Relaxed error checking rules in AptControlInterface so it could also be used to model the case of contextual services that are classes (not interfaces). Resolved by svn 165217.
> Enable classes to be used as contextual services for controls
> -------------------------------------------------------------
>
> Key: BEEHIVE-364
> URL: http://issues.apache.org/jira/browse/BEEHIVE-364
> Project: Beehive
> Type: Bug
> Components: Controls
> Versions: V1Beta
> Reporter: Kyle Marvin
> Assignee: Kyle Marvin
> Fix For: V1
>
> Currently, the Controls annotation processor requires that any field annotated by @Context be of an interface (not a class) type. There is really no reason why a class can't act as a contextual service... the base JavaBeans contextual service model upon which this is built does not require this.
> Rich Feit would like to expose PageFlowController for controls running inside of a pageflow, but it is a class.
> The core issue here is that APT control processing uses AptControlInterface for both control and context fields... but the validation rules actually need to differ.
> The right thing is to add an intermediate abstract AptEventSource that represents a type that can declare (and deliver events) and then have AptControlInterface and AptContextType that derive from it. So a little refactoring should enable it to be fixed.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira