Forgive me if this issue has been discussed elsewhere (I couldn't find
anything in the archive), but I am trying to get my head wrapped
around writing SCA services servers. I like the simple include "SCA/
SCA.php"; structure which makes for a very easy server build out.
However, I am also finding that this structure is also very
inflexible. For example, I am looking to integrate SCA into a PEAR
like structured application.
1) I have all my library files in a separate library directory. All
libraries adhere to PEAR naming conventions, and directory placement
2) I have a bootstrap include that sets up my environment (include
paths, error handlers)
3) My public facing php files reference libraries behind what is
publicly exposed via the web server
On point 1 and 3, what I am wanting to do is have a simple public
facing php script that inits my bootstrap, and includes a class within
my library. The library then includes SCA. SCA then chokes on it's
assumptions of what the class should be named (file name != class
name). There doesn't appear to be a way that I can override how
SCA.php kicks off SCA::initComponent(), which does not groove with my
deployment layout. I'd like to avoid modifying the distributed SCA
On point 2, if I don't move my service class outside of the public PHP
script, I cannot include the bootstrap file at the top, followed by an
include of SCA.php. SCA.php then assumes that my bootstrap script
contains my class for service binding.
Is there something that I am missing with how I should be massaging
SCA.php, or is my implementation choice just not jiving with how SCA
is intended on working?
You received this message because you are subscribed to the Google Groups
To post to this group, send email to firstname.lastname@example.org
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at