Just a quick status update... I've done the code to optionally allow an interface to be specified and tested this independent of a protocol binding and all works fine. Unfortunately, when called from a remote invocation, the classexists tests for the service implementation fails. Get_declared_classes() confirms that it does not have the definition and get_declared_interfaces() confirms that it knows about the interfaces. Removing the interfaces makes everything work as before, so it appears to be a PHP nit.
I'm going to try to create a little test case to reproduce this outside SCA. If anyone has heard of anything which might be relevant, please let me know. Graham. On 3 Sep, 13:18, Graham Charters <[EMAIL PROTECTED]> wrote: > It sounds like we may have consensus. To summarise: > > 1. We should add the ability to specify an optional interface for the > service on the @service annotation (e.g. @service > MyServiceInterface). This would only be used to limit the methods > exposed by the service, so we would not look for any other metadata in > the interface (we could support this later). > 2. We should not include methods in service descriptions which have > not been appropriately documented (this is to avoid generating duff > services descriptions, and is not meant to be used as a means of > controlling the service interface). > > Hopefully I'll be able to take a look at 1 sometime towards the end of > this week, unless someone else is itching to do it :-D > > Graham. > > On 31 Aug, 15:03, Matthew Schultz <[EMAIL PROTECTED]> wrote:> Actually after > a second glance, I see all annotations are still set in > > the class. It probably wouldn't make any sense to have SCA parse > > annotations in the interface. > > > Matt > > > On 31 Aug, 06:20, Graham Charters <[EMAIL PROTECTED]> wrote:> Comments > > inlined below... > > > > On 31 Aug, 11:35, [EMAIL PROTECTED] wrote: > > > > > Hi Graham > > > > > Some more comments in line... > > > > > On 31 Aug, 11:26, Graham Charters <[EMAIL PROTECTED]> wrote: > > > > > > Hi Simon, thanks for the rapid comments. Here's my thoughts on the > > > > > two issues you identified: > > > > > > > 1/ What should SCA do if it finds a method without annotations, i.e. > > > > > > no type information > > > > > > This probably depends on the type of service. Service types which > > > > > don't have a service description (e.g. local, REST and Atom), don't > > > > > require this information to be specified. Service types which do have > > > > > service descriptions (soap, json-rpc, xml-rpc), do (to varying > > > > > degrees). > > > > > > I think if the binding type requires documentation then we should warn > > > > > and not generate (rather than generating something which is of no > > > > > use). If the binding type doesn't require documentation then it's > > > > > included. > > > > > > > 2/ How can methods be omitted from the service interface, i.e. we > > > > > > just > > > > > > don't want to expose the method > > > > > > I don't think the absence of comments should be used as a control > > > > > mechanism for the reason you and Matt have already highlighted (might > > > > > want to document something but still not have it on the service > > > > > interface). > > > > > > I quite like the idea of using interfaces to add this level of > > > > > control. It would also be consistent with SCA (SCA Java does this and > > > > > also supports the same class implementation approach we use (i.e. > > > > > where there is no interface)). How about something like: > > > > > > /** > > > > > * Scaffold implementation for a remote StockQuote Web service. > > > > > * > > > > > * @service StockQuoteInterface > > > > > * @binding.soap > > > > > * > > > > > */ > > > > > StockQuoteImpl implements StockQuoteInterface, ANOtherInterface { > > > > > ... > > > > > > } > > > > > So I like @service StokeQuoteInterface > > > > > If you are suggesting that we can parse the StockQuoteInterface to > > > > pull out the method names which should be provided as service > > > > interfaces (without the need for further annotation on the interface > > > > itself) then this could work. My approach was a contraction of this by > > > > just providing the method names after the interface name in the > > > > annotation but your approach is more forward thinking. > > > > We should be able to update this in SCA_AnnotationReader.php. I > > > believe all the information is available through Reflection. You can > > > call getInterfaces() on the ReflectionClass, which returns an array of > > > ReflectionClass objects, one for each interface. I don't think we > > > would require further annotations in the interface, but we will need > > > to decided whether to use annotations/documentation in an interface if > > > it is provided. > > > > > Presumably the default would be to provide all methods if no interface > > > > is described. > > > > Yes, so this would be backwards compatible. > > > > > > This would be taken to mean that only those methods defined on > > > > > StockQuoteInterface are part of the soap service. Those in > > > > > ANOtherInterface or just in StockQuoteImpl would be excluded. I'd > > > > > prefer to pursue this approach rather than creating a new annotations > > > > > which may go away in the near future. > > > > > > Does this make sense and seem sensible? > > > > > > On 31 Aug, 09:30, [EMAIL PROTECTED] wrote: > > > > > > > On 31 Aug, 08:42, Graham Charters <[EMAIL PROTECTED]> wrote: > > > > > > > > Pecl Request #11944 (http://pecl.php.net/bugs/bug.php?id=11944) is > > > > > > > asking for finer-grained control over the methods which are > > > > > > > surfaced > > > > > > > on a service interface. We currently just use class visibility > > > > > > > (i.e. > > > > > > > all public methods) to control this. > > > > > > > > There's a small amount of discussion in the request, but I > > > > > > > thought it > > > > > > > would be good to raise it here to get greater visibility and > > > > > > > gather > > > > > > > more options/opinions. > > > > > > > > Graham. > > > > > > > Following up on the comments made in the feature request... > > > > > > > It is true that in the Java SCA implementation the @Service > > > > > > information is associated with interfaces so a class will > > > > > > implementat > > > > > > one, or more, interfaces and this tells the runtime which methods of > > > > > > the class should be treated as service methods. > > > > > > > This is not currently how the PHP SCA implementation works. All > > > > > > annotations are placed on the class itself. This leads to a level of > > > > > > simplicity in service construction but we pay for this in lack of > > > > > > flexibility, for example, in excluding some methods from the service > > > > > > interface. At least given the set of annotations we have at the > > > > > > moment. > > > > > > > Having said this I'm not convinced that the use of unannotated (is > > > > > > that a word?) methods as part of the service interface makes a lot > > > > > > of > > > > > > sense give the way that the implementation works at the moment. If > > > > > > you > > > > > > look at what is actually generated in the WSDL in the case of the > > > > > > method "function foo($bar)" in the feature request it doesn't seem > > > > > > to > > > > > > be that useful. I.e. it defines null input and output types. I > > > > > > assume > > > > > > this is because there are no annotations for SCA to use for typing > > > > > > the > > > > > > interface. Fine for PHP but not so great for a service interface. > > > > > > > So there are two issues here > > > > > > > 1/ What should SCA do if it finds a method without annotations, i.e. > > > > > > no type information > > > > > > 2/ How can methods be omitted from the service interface, i.e. we > > > > > > just > > > > > > don't want to expose the method > > > > > > > As first suggested we could omit methods that don't have comments at > > > > > > all.. However this is problematic for issue 2 as annotations may > > > > > > have > > > > > > been included for producing the documentation that the annotations > > > > > > were originally designed for. However I think we should consider > > > > > > omitting methods without annotations due to issue 1 so this could > > > > > > be a > > > > > > short term solution 2. > > > > > > > Following the conversation on for issue 2. Maybe, as an alternative > > > > > > to > > > > > > @scaExcludeMethod we could defined some new annotation for the > > > > > > header > > > > > > block that works as an alternative to defining an interface (we > > > > > > should > > > > > > look whether interfaces could be made to work), e.g. > > > > > > > /** > > > > > > * Scaffold implementation for a remote StockQuote Web service. > > > > > > * > > > > > > * @service > > > > > > * @serviceinterface GetQuote getQuote > > > > > > * @binding.soap > > > > > > * > > > > > > */ > > > > > > > If these don't appear then the default would be to operate as now > > > > > > with all of the (annotated) methods being parsed. The intention here > > > > > > being to replace/augment this with annotations on interfaces > > > > > > if/'when > > > > > > they work. > > > > > > > Regards > > > > > > > Simon --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "phpsoa" group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~----------~----~----~----~------~----~------~--~---