Service that implement interfaces?

[simonslaws-gM/Ye1E23mwN+]

It would seem to be the case that if you implement a service using a
class that implements an interface then SCA doesn't recognize it as a
service. For example, with the service:

/**
* @service
* @binding.restresource
* @types urn::orderNS Orders.xsd
*/
class Orders implements SCA_Bindings_restresource_ResourceTemplate
{

I get the

SCA::initComponent - included by a client script that is not a
component In the log. Am just investigating now but I'm assuming this
is not by design.

Simon


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa-/***@public.gmane.org
To unsubscribe from this group, send email to phpsoa-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[simonslaws-gM/Ye1E23mwN+]

Post by simonslaws-gM/Ye1E23mwN+
It would seem to be the case that if you implement a service using a
class that implements an interface then SCA doesn't recognize it as a
/**
*/
class Orders implements SCA_Bindings_restresource_ResourceTemplate
{
I get the
SCA::initComponent - included by a client script that is not a
component In the log. Am just investigating now but I'm assuming this
is not by design.
Simon

An update...

It seems that PHP does not recognize a class that implements an
interface as declared in the code before the class declaration is
placed [1]. As our SCA.php include comes before the class declaration
the class_exists test in the
_includedByAClientScriptThatIsNotAComponent() funtion is bailing out.

The use of an interface in my example is not mandatory, just a
convenience. The immediate solutions are to either

- Stop using the interface
- move the SCA.php include to the bottom of the file

Both provide satisfaction but reduce flexibility for the user. Anyone
know how to get round this class_exists issue?

[1] - http://php.benscom.com/manual/en/language.oop5.interfaces.php
search for class_exists


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa-/***@public.gmane.org
To unsubscribe from this group, send email to phpsoa-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[Caroline Maynard]

Post by simonslaws-gM/Ye1E23mwN+

Post by simonslaws-gM/Ye1E23mwN+
It would seem to be the case that if you implement a service using a
class that implements an interface then SCA doesn't recognize it as a
/**
*/
class Orders implements SCA_Bindings_restresource_ResourceTemplate
{
I get the
SCA::initComponent - included by a client script that is not a
component In the log.

It seems that PHP does not recognize a class that implements an
interface as declared in the code before the class declaration is
placed [1]. As our SCA.php include comes before the class declaration
the class_exists test in the
_includedByAClientScriptThatIsNotAComponent() function is bailing out.
The use of an interface in my example is not mandatory, just a
convenience. The immediate solutions are to either
- Stop using the interface
- move the SCA.php include to the bottom of the file
Both provide satisfaction but reduce flexibility for the user. Anyone
know how to get round this class_exists issue?

Simon, is there a reason why you cannot include >just< the interface you
need, rather than the whole of SCA.php? Or is it going to get dragged in
anyway?

One thing that might help is to look at adding an spl_autoload usage
into SCA. There's already a dependency on spl, so it wouldn't be
introducing a new one. And spl_autoload is better than the basic
__autoload, because it doesn't hijack the "classpath", it chains it
through subsequent spl_autoload_register()s.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa-/***@public.gmane.org
To unsubscribe from this group, send email to phpsoa-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[Graham Charters]

I don't have any thoughts on solutions at this time, but I do have a
comment on the "by design". You are right that it is not by design
that interfaces are excluded. Determining the service 'interface'
from a class's public methods is a convenience. We do want to support
explicit use of an interface.

Post by Caroline Maynard

Post by simonslaws-gM/Ye1E23mwN+

Post by simonslaws-gM/Ye1E23mwN+
It would seem to be the case that if you implement a service using a
class that implements an interface then SCA doesn't recognize it as a
/**
*/
class Orders implements SCA_Bindings_restresource_ResourceTemplate
{
I get the
SCA::initComponent - included by a client script that is not a
component In the log.

It seems that PHP does not recognize a class that implements an
interface as declared in the code before the class declaration is
placed [1]. As our SCA.php include comes before the class declaration
the class_exists test in the
_includedByAClientScriptThatIsNotAComponent() function is bailing out.
The use of an interface in my example is not mandatory, just a
convenience. The immediate solutions are to either
- Stop using the interface
- move the SCA.php include to the bottom of the file
Both provide satisfaction but reduce flexibility for the user. Anyone
know how to get round this class_exists issue?

Simon, is there a reason why you cannot include >just< the interface you
need, rather than the whole of SCA.php? Or is it going to get dragged in
anyway?
One thing that might help is to look at adding an spl_autoload usage
into SCA. There's already a dependency on spl, so it wouldn't be
introducing a new one. And spl_autoload is better than the basic
__autoload, because it doesn't hijack the "classpath", it chains it
through subsequent spl_autoload_register()s.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa-/***@public.gmane.org
To unsubscribe from this group, send email to phpsoa-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---