You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Howard M. Lewis Ship (JIRA)" <ta...@jakarta.apache.org> on 2005/08/23 19:02:10 UTC
[jira] Updated: (TAPESTRY-157) Make it easier to subclass DirectService

     [ http://issues.apache.org/jira/browse/TAPESTRY-157?page=all ]

Howard M. Lewis Ship updated TAPESTRY-157:
------------------------------------------

    Bugzilla Id:   (was: 28381)
        Summary: Make it easier to subclass DirectService  (was: support for subclassing in DirectService)
    Description: 
I'd like to subclass DirectService by slightly modifying the behaviour of the 
service() method but leaving the getLink() method untouched. I have the 
following problems with this:
- DirectService.STATEFUL_ON and DirectService.STATEFUL_OFF are private, so I 
cannot copy-paste the code from the original service() method to my subclass
- Of course it would be much better to prevent copy-paste. For example the 
service() method should be cut into at least two separate methods: extracting 
parameters and executing service related tasks. This is necessary to execute 
the service without a RequestContext (for testing or internal invocation).
- the above subclassing problem is true for all services

All the above is irrelevant if default Tapestry services are not intended to be 
(easily) subclassed (but I think they should be).

Thanks,
Norbi

  was:
I'd like to subclass DirectService by slightly modifying the behaviour of the 
service() method but leaving the getLink() method untouched. I have the 
following problems with this:
- DirectService.STATEFUL_ON and DirectService.STATEFUL_OFF are private, so I 
cannot copy-paste the code from the original service() method to my subclass
- Of course it would be much better to prevent copy-paste. For example the 
service() method should be cut into at least two separate methods: extracting 
parameters and executing service related tasks. This is necessary to execute 
the service without a RequestContext (for testing or internal invocation).
- the above subclassing problem is true for all services

All the above is irrelevant if default Tapestry services are not intended to be 
(easily) subclassed (but I think they should be).

Thanks,
Norbi

        Version: 4.0
    Environment: 
Operating System: Other
Platform: Other

  was:
Operating System: Other
Platform: Other

      Assign To: Howard M. Lewis Ship  (was: Tapestry Developer List)
       Priority: Minor

Obviously, much has changed between 3.0 and 4.0.  Most of the constants are now public (and in a seperate file).  I've made the fields containing injected services protected instead of private.

> Make it easier to subclass DirectService
> ----------------------------------------
>
>          Key: TAPESTRY-157
>          URL: http://issues.apache.org/jira/browse/TAPESTRY-157
>      Project: Tapestry
>         Type: Bug
>   Components: Framework
>     Versions: 3.0, 4.0
>  Environment: Operating System: Other
> Platform: Other
>     Reporter: Norbert P.
>     Assignee: Howard M. Lewis Ship
>     Priority: Minor

>
> I'd like to subclass DirectService by slightly modifying the behaviour of the 
> service() method but leaving the getLink() method untouched. I have the 
> following problems with this:
> - DirectService.STATEFUL_ON and DirectService.STATEFUL_OFF are private, so I 
> cannot copy-paste the code from the original service() method to my subclass
> - Of course it would be much better to prevent copy-paste. For example the 
> service() method should be cut into at least two separate methods: extracting 
> parameters and executing service related tasks. This is necessary to execute 
> the service without a RequestContext (for testing or internal invocation).
> - the above subclassing problem is true for all services
> All the above is irrelevant if default Tapestry services are not intended to be 
> (easily) subclassed (but I think they should be).
> Thanks,
> Norbi

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


---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org