amfphp-cvs Mailing List for Amfphp (Page 18)

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

CVS commit by ktukker: 

Directory /cvsroot/amfphp/sources/examples/parkservice added to the repository

CVS commit by ktukker: 

Fixed import of mysql recordset

  M +1 -1      sources/flashservices/io/AMFSerializer.php   1.6

CVS commit by ktukker: 

Update debug facility
with $gateway->setDebugDirectory("/path/to/debug/dir/")
You can set the output directory for debugging purposes

Default dir is set to ../dump/

with debug("sometext") you can debug the progression in the Gateway class.
This will be appended to the file processing.txt in the debug-output-dir.

  M +28 -8     sources/flashservices/app/Gateway.php   1.4

CVS commit by ktukker: 

* Moved examples to example directory. More examples to be added
* Changed the way of usage of this package in PHP

Usage
=====
There are two ways to used this package. The first way is to put the flashservices into every directory you use it. This is usually done when the includepath of php only includes the local directory ( "." ) . The second way is when the flashservices library can be put into any directory that is in the includepath.

1. using local directory
------------------------
* Create a directory for your project under your Webserver documentroot. 
  This directory should be accessable from your webbrowser
  (for example myproject/ , this appears under /myproject/ under the webserver)
* Put the directory called "flashservices/" into the directory
* Copy the contents of the example you want to run into the directory 
  (for example examples/basic/)
* Call the sample from your client. 
  (for example http://host/myproject/discovery.php)

2. using php include_path
-------------------------
* Set the include_path of your php environment. This can be done in various ways.
  For example you can use the php.ini, setting the variables through your 
  apache configfiles, or use .htaccess (if allowed by the webserver) See PHP and/or
  apache docs for more info.
* put the flashservices/ directory into the include_path.
* copy the examples directory under your webserver
* call them from your client.
  (http://host/examples/basic/discovery.php)

The second way is preferred. In this way you can create multiple remoting gateways without duplicating the basic flashremoting code.

CHANGES
=======

* Changed includes of the files
* Changed <? to <?php (where this was still left)

TODO
====

* make sure this also works with php register_globals = off

  R            sources/flashservices/services/AliasedService.php   1.1.1.1
  R            sources/flashservices/services/DataEcho.php   1.1
  R            sources/flashservices/services/RegisteredService.php   1.1.1.1

CVS commit by ktukker: 

* Moved examples to example directory. More examples to be added
* Changed the way of usage of this package in PHP

Usage
=====
There are two ways to used this package. The first way is to put the flashservices into every directory you use it. This is usually done when the includepath of php only includes the local directory ( "." ) . The second way is when the flashservices library can be put into any directory that is in the includepath.

1. using local directory
------------------------
* Create a directory for your project under your Webserver documentroot. 
  This directory should be accessable from your webbrowser
  (for example myproject/ , this appears under /myproject/ under the webserver)
* Put the directory called "flashservices/" into the directory
* Copy the contents of the example you want to run into the directory 
  (for example examples/basic/)
* Call the sample from your client. 
  (for example http://host/myproject/discovery.php)

2. using php include_path
-------------------------
* Set the include_path of your php environment. This can be done in various ways.
  For example you can use the php.ini, setting the variables through your 
  apache configfiles, or use .htaccess (if allowed by the webserver) See PHP and/or
  apache docs for more info.
* put the flashservices/ directory into the include_path.
* copy the examples directory under your webserver
* call them from your client.
  (http://host/examples/basic/discovery.php)

The second way is preferred. In this way you can create multiple remoting gateways without duplicating the basic flashremoting code.

CHANGES
=======

* Changed includes of the files
* Changed <? to <?php (where this was still left)

TODO
====

* make sure this also works with php register_globals = off

  M +6 -5      sources/flashservices/app/Executive.php   1.4
  M +9 -9      sources/flashservices/app/Gateway.php   1.3

CVS commit by ktukker: 

* Moved examples to example directory. More examples to be added
* Changed the way of usage of this package in PHP

Usage
=====
There are two ways to used this package. The first way is to put the flashservices into every directory you use it. This is usually done when the includepath of php only includes the local directory ( "." ) . The second way is when the flashservices library can be put into any directory that is in the includepath.

1. using local directory
------------------------
* Create a directory for your project under your Webserver documentroot. 
  This directory should be accessable from your webbrowser
  (for example myproject/ , this appears under /myproject/ under the webserver)
* Put the directory called "flashservices/" into the directory
* Copy the contents of the example you want to run into the directory 
  (for example examples/basic/)
* Call the sample from your client. 
  (for example http://host/myproject/discovery.php)

2. using php include_path
-------------------------
* Set the include_path of your php environment. This can be done in various ways.
  For example you can use the php.ini, setting the variables through your 
  apache configfiles, or use .htaccess (if allowed by the webserver) See PHP and/or
  apache docs for more info.
* put the flashservices/ directory into the include_path.
* copy the examples directory under your webserver
* call them from your client.
  (http://host/examples/basic/discovery.php)

The second way is preferred. In this way you can create multiple remoting gateways without duplicating the basic flashremoting code.

CHANGES
=======

* Changed includes of the files
* Changed <? to <?php (where this was still left)

TODO
====

* make sure this also works with php register_globals = off

  R            sources/flashservices/discovery.php   1.1
  R            sources/flashservices/examples.fla   1.1
  R            sources/flashservices/examples.swf   1.1
  R            sources/flashservices/registered.php   1.1

CVS commit by ktukker: 

* Moved examples to example directory. More examples to be added
* Changed the way of usage of this package in PHP

Usage
=====
There are two ways to used this package. The first way is to put the flashservices into every directory you use it. This is usually done when the includepath of php only includes the local directory ( "." ) . The second way is when the flashservices library can be put into any directory that is in the includepath.

1. using local directory
------------------------
* Create a directory for your project under your Webserver documentroot. 
  This directory should be accessable from your webbrowser
  (for example myproject/ , this appears under /myproject/ under the webserver)
* Put the directory called "flashservices/" into the directory
* Copy the contents of the example you want to run into the directory 
  (for example examples/basic/)
* Call the sample from your client. 
  (for example http://host/myproject/discovery.php)

2. using php include_path
-------------------------
* Set the include_path of your php environment. This can be done in various ways.
  For example you can use the php.ini, setting the variables through your 
  apache configfiles, or use .htaccess (if allowed by the webserver) See PHP and/or
  apache docs for more info.
* put the flashservices/ directory into the include_path.
* copy the examples directory under your webserver
* call them from your client.
  (http://host/examples/basic/discovery.php)

The second way is preferred. In this way you can create multiple remoting gateways without duplicating the basic flashremoting code.

CHANGES
=======

* Changed includes of the files
* Changed <? to <?php (where this was still left)

TODO
====

* make sure this also works with php register_globals = off

  A            sources/examples/basic/services/AliasedService.php   1.1
  A            sources/examples/basic/services/DataEcho.php   1.1
  A            sources/examples/basic/services/RegisteredService.php   1.1

CVS commit by ktukker: 

* Moved examples to example directory. More examples to be added
* Changed the way of usage of this package in PHP

Usage
=====
There are two ways to used this package. The first way is to put the flashservices into every directory you use it. This is usually done when the includepath of php only includes the local directory ( "." ) . The second way is when the flashservices library can be put into any directory that is in the includepath.

1. using local directory
------------------------
* Create a directory for your project under your Webserver documentroot. 
  This directory should be accessable from your webbrowser
  (for example myproject/ , this appears under /myproject/ under the webserver)
* Put the directory called "flashservices/" into the directory
* Copy the contents of the example you want to run into the directory 
  (for example examples/basic/)
* Call the sample from your client. 
  (for example http://host/myproject/discovery.php)

2. using php include_path
-------------------------
* Set the include_path of your php environment. This can be done in various ways.
  For example you can use the php.ini, setting the variables through your 
  apache configfiles, or use .htaccess (if allowed by the webserver) See PHP and/or
  apache docs for more info.
* put the flashservices/ directory into the include_path.
* copy the examples directory under your webserver
* call them from your client.
  (http://host/examples/basic/discovery.php)

The second way is preferred. In this way you can create multiple remoting gateways without duplicating the basic flashremoting code.

CHANGES
=======

* Changed includes of the files
* Changed <? to <?php (where this was still left)

TODO
====

* make sure this also works with php register_globals = off

  A            sources/examples/basic/discovery.php   1.1
  A            sources/examples/basic/examples.fla   1.1
  A            sources/examples/basic/secured.php   1.1

CVS commit by ktukker: 

Directory /cvsroot/amfphp/sources/examples/basic/services added to the repository

CVS commit by ktukker: 

Directory /cvsroot/amfphp/sources/examples/basic added to the repository

CVS commit by ktukker: 

Directory /cvsroot/amfphp/sources/examples added to the repository

CVS commit by johncowen: 

Initial import of an example fla and a service for it to use

  A            sources/flashservices/examples.fla   1.1
  A            sources/flashservices/examples.swf   1.1

CVS commit by johncowen: 

Initial import of an example fla and a service for it to use

  A            sources/flashservices/services/DataEcho.php   1.1

CVS commit by johncowen: 

Initial import of an example fla and a service for it to use

  M +66 -66    sources/flashservices/util/AMFObject.php   1.2

CVS commit by johncowen: 

Removed examples for old version

  R            sources/flashservices/examples/services/myservice.php   1.1.1.1
  R            sources/flashservices/examples/services/typedservice.php   1.1.1.1

CVS commit by johncowen: 

Removed examples for old version

  R            sources/flashservices/examples/discovery.php   1.1.1.1
  R            sources/flashservices/examples/registered.php   1.1.1.1

CVS commit by johncowen: 

The Serializer wasn't serializing accented characters properly because of the utf8_encode, now it serializes properly..

  M +2 -2      sources/flashservices/io/AMFSerializer.php   1.5

CVS commit by ktukker: 

debug part removed
* $debug was never found, it was not made global in the function
* $this->saveRawData is not available here

obey error level:

from http://www.php.net/manual/en/function.error-reporting.php :

error_reporting() has no effect if you have defined your own error handler with set_error_handler() 

[Editor's Note: This is not quite accurate. 

E_ERROR, E_PARSE, E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR and E_COMPILE_WARNING error levels will be handled as per the error_reporting settings. 

All other levels of errors will be passed to the custom error handler defined by set_error_handler(). 

Zeev Suraski suggests that a simple way to use the defined levels of error reporting with your custom error handlers is to add the following line to the top of your error handling function: 

if (!($type & error_reporting())) return; 

  M +4 -5      sources/flashservices/exception/Exceptions.php   1.3

Hi,

After my holiday to Egypt, i bumped into a pile of work at work.. (as
usually). Now i've taken some time to look at the changes. They look fine to
me, although I have some questions.

Structure on filesystem
=================
I would like to use the flashservices as a "library". So I like to have it
once on my whole filesystem and then include and use it for my (multiple)
gateways. I imagine it like have an /home/httpd/include/ containing the
"flashservices" package.

The PHP include-path is set to ".:/home/httpd/include/" .
The code for a gateway would look like:

    include "flashservices/app/Gateway.php";
    $gateway = new Gateway();
    $gateway->setSafeExecution(true);
    $gateway->setInstanceName("SecuredWithName");
    $gateway->setBaseClassPath("services/");
    $gateway->service();

Although this include totally breaks everything. To make it work, i have to
put /home/httpd/include/flashservices/ into my include_path and say

    include "app/Gateway.php";

I don't think this is beautifyfull.
So my proposal is to set the "rule" to "put the flashservices/ dir into your
includepath and work like sample 1"
This means we have to fix the "includes" in the package accordingly.

I still can have my own BaseClassPath with services under the currentDir (as
long as you have "." in your include_path)

Safemode execution
==============
Justin introduced the "instance" key for the methodTable. With this, the
instanceName set by the gateway has to be the same as the instancename
mentioned in the methodTable. One line up it says setSafeExecution(true) .
The current behaviour won't allow you to set it to false. The Executive
class checks for one of both (SafeExecution or instance given)

(Executive.php:175)     if ($this->_safeExecution ||
isset($methodrecord['instance']))

To my oppinion, this should be changed to $this->_safeExection only.

Maybe I am wrong here and don't understand the security model here. It
probably depends on the contract between the gateway and the services given.
At the moment, I think, both are being programmed by the same developer. So
If he wants to turn of security, he only has to say
"setSafeExecution(false)" and all the checks (even the one for "instance")
are skipped.

WebServices proxy
==============
the CF and Java gateways allows flash to call the gateway using a given WSDL
file. I've sent a patch to this list based on the previous versoin. Ahmet
Zorlu has sent a proxy. The difference is that the first one worked like the
"Macromedia Style". The second one as another way of invocation.

The differences:
"Macromedian style"
-----------------------
NetServices.setDefaultGatewayURL("http://host/gateway.php");
	var conn = NetServices.createGatewayConnection();
	var myService = conn.getService("http://www.host.com/path/to/wsdl.wsdl",
this);

myService.sampleMethod(responder,arg1,arg2,arg3)

(see also:
http://www.evolt.org/article/Flash_Remoting_Demystified/17/48594/)

"Alternate style by Ahmet"
------------------------------
NetServices.setDefaultGatewayURL("http://host/gateway.php");
 var myService = conn.getService("WebServiceProxy", this);
var wsdlLoc = "http://live.capescience.com/wsdl/AirportWeather.wsdl";
	var operationName = "getSummary";
	var params = new Object();
 params.arg0 = sel.symbol ;
	myService.getMessage(wsdlLoc, operationName, params);

The second way is a "plugin" to the framework, but not standard style. The
first way has to be put into the framework. The problem here is to identify
that it is a webservice WSDL file (starting with http:// and ending with
wsdl ???). What will our way of working here?

"allow_call_time_pass_reference"
=========================
Finally, there is some "soon to be obsolete functionlity in PHP" in the
code.

If you have in your php.ini

allow_call_time_pass_reference = On

And you probably have, otherwise amfphp is not working

Comments from the same ini file:

; Whether to enable the ability to force arguments to be passed by reference
; at function call time.  This method is deprecated and is likely to be
; unsupported in future versions of PHP/Zend.  The encouraged method of
; specifying which arguments should be passed by reference is in the
function
; declaration.  You're encouraged to try and turn this option Off and make
; sure your scripts work properly with it in order to ensure they will work
; with future versions of the language (you will receive a warning each time
; you use this feature, and the argument will be passed by value instead of
by
; reference).

So we have to look at the code with the switch

allow_call_time_pass_reference = Off

Klaasjan

----- Original Message -----
From: "Justin Watkins" <ju...@24...>
To: <amf...@li...>
Sent: Friday, February 21, 2003 1:17 AM
Subject: [amfphp-cvs] updates

> As you can obviously see, I made quite a few changes.  Hopefully this
> is more along the lines of every one's visions.  Most of the developers
> should have recieved John's changes.  His changes are the complete base
> for the updates I made.  The log entry I put with the changes explains
> everything.  I haven't updated the examples yet, and I will work on
> that later.  I hope especially, Klaasjan, is ok with the changes.
>
> Our motivation for removing the including, initing and calling of the
> gateway from a registered service is: then that very precious code you
> wrote as the service can ONLY be used as a AMFPHP service.  Nothing
> else, you can never include it in another php app.  Now I know you
> could always build a facade of some sorts, but this way you don't have
> to do any of that, and can still have the seperation and control you
> had with the previous registered version with more abstraction from the
> gateway.
>
> I will work on getting the ServiceBrowser methods working, as that was
> the motivation for the subclassing of the service.
>
> There are about 1/2 dozen things I want to change still but I thought I
> would get this one out to everyone as soon as possible because it is a
> pretty big one.
>
> Justin
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
> The most comprehensive and flexible code editor you can use.
> Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
> www.slickedit.com/sourceforge
> _______________________________________________
> amfphp-cvs mailing list
> amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amfphp-cvs
>

CVS commit by justinwatkins: 

Started to add the support for the ServiceBrowser.  The gateway now understands the DescribeService Header and partially builds the lists necessary for the ServiceBrowser to map the methods.  Currently only, remote enabled methods will show, but argument lists are still non-functional.

Justin

  M +33 -5     sources/flashservices/util/RemotingService.php   1.2

CVS commit by justinwatkins: 

Started to add the support for the ServiceBrowser.  The gateway now understands the DescribeService Header and partially builds the lists necessary for the ServiceBrowser to map the methods.  Currently only, remote enabled methods will show, but argument lists are still non-functional.

Justin

  M +26 -4     sources/flashservices/app/Executive.php   1.3
  M +16 -6     sources/flashservices/app/Gateway.php   1.2

As you can obviously see, I made quite a few changes.  Hopefully this 
is more along the lines of every one's visions.  Most of the developers 
should have recieved John's changes.  His changes are the complete base 
for the updates I made.  The log entry I put with the changes explains 
everything.  I haven't updated the examples yet, and I will work on 
that later.  I hope especially, Klaasjan, is ok with the changes.

Our motivation for removing the including, initing and calling of the 
gateway from a registered service is: then that very precious code you 
wrote as the service can ONLY be used as a AMFPHP service.  Nothing 
else, you can never include it in another php app.  Now I know you 
could always build a facade of some sorts, but this way you don't have 
to do any of that, and can still have the seperation and control you 
had with the previous registered version with more abstraction from the 
gateway.

I will work on getting the ServiceBrowser methods working, as that was 
the motivation for the subclassing of the service.

There are about 1/2 dozen things I want to change still but I thought I 
would get this one out to everyone as soon as possible because it is a 
pretty big one.

Justin

CVS commit by justinwatkins: 

1.  Greatly modified the Executive to change how the registered method works, as well as change how the loading of the class works.  There is now a basic class named RemotingService that dynamically extends the designated class.  This done to add some additional functionality for the Flash Service Browser and some other possible future implementations.
2.  Now the service classes HAVE to have a constructor.  And in the constructor they must define a $this->methodTable array.  The array contains a list of any methods that are to be enabled or described.  All methods are now disabled from flash remoting by default and you have to explicity define a method's access as remote.
3.  I also changed how the registered version worked.  Before registered classes became VERY AMF specific.  They always generated AMF regardless of where you called them.  I changed the model so there is now an instance name negotiation.  If the gateway is set to safeExecution mode, the executive will check to see if the gateway's name (set with setInstanceName) is the same as the service class method's instance name.  See the example files.  Also if a service method has an instance name defined, the discovery gateway will NOT be able to use it.  

I think this accomplishes all of the needs by the registered service.  It definitely makes the classes created for remoting much more versatile.  Now there is nothing remoting specific other than the methodTable array, in either the registered and discovery mode classes.

BTW, most of these ideas were developed by John.  He has spent a ton of time trying to make the classes developed for remoting more flexible.  He originally had each class inheriting from the RemotingService class.  I added the dynamic subclassing instead and the methodTable in the constructor. As well as the support for the registered approach via instance names.

Justin

  A            sources/flashservices/util/RemotingService.php   1.1
  R            sources/flashservices/util/PHPRemoting.php   1.1.1.1

CVS commit by justinwatkins: 

1.  Greatly modified the Executive to change how the registered method works, as well as change how the loading of the class works.  There is now a basic class named RemotingService that dynamically extends the designated class.  This done to add some additional functionality for the Flash Service Browser and some other possible future implementations.
2.  Now the service classes HAVE to have a constructor.  And in the constructor they must define a $this->methodTable array.  The array contains a list of any methods that are to be enabled or described.  All methods are now disabled from flash remoting by default and you have to explicity define a method's access as remote.
3.  I also changed how the registered version worked.  Before registered classes became VERY AMF specific.  They always generated AMF regardless of where you called them.  I changed the model so there is now an instance name negotiation.  If the gateway is set to safeExecution mode, the executive will check to see if the gateway's name (set with setInstanceName) is the same as the service class method's instance name.  See the example files.  Also if a service method has an instance name defined, the discovery gateway will NOT be able to use it.  

I think this accomplishes all of the needs by the registered service.  It definitely makes the classes created for remoting much more versatile.  Now there is nothing remoting specific other than the methodTable array, in either the registered and discovery mode classes.

BTW, most of these ideas were developed by John.  He has spent a ton of time trying to make the classes developed for remoting more flexible.  He originally had each class inheriting from the RemotingService class.  I added the dynamic subclassing instead and the methodTable in the constructor. As well as the support for the registered approach via instance names.

Justin

  A            sources/flashservices/app/Gateway.php   1.1
  M +201 -195  sources/flashservices/app/Executive.php   1.2

CVS commit by justinwatkins: 

1.  Greatly modified the Executive to change how the registered method works, as well as change how the loading of the class works.  There is now a basic class named RemotingService that dynamically extends the designated class.  This done to add some additional functionality for the Flash Service Browser and some other possible future implementations.
2.  Now the service classes HAVE to have a constructor.  And in the constructor they must define a $this->methodTable array.  The array contains a list of any methods that are to be enabled or described.  All methods are now disabled from flash remoting by default and you have to explicity define a method's access as remote.
3.  I also changed how the registered version worked.  Before registered classes became VERY AMF specific.  They always generated AMF regardless of where you called them.  I changed the model so there is now an instance name negotiation.  If the gateway is set to safeExecution mode, the executive will check to see if the gateway's name (set with setInstanceName) is the same as the service class method's instance name.  See the example files.  Also if a service method has an instance name defined, the discovery gateway will NOT be able to use it.  

I think this accomplishes all of the needs by the registered service.  It definitely makes the classes created for remoting much more versatile.  Now there is nothing remoting specific other than the methodTable array, in either the registered and discovery mode classes.

BTW, most of these ideas were developed by John.  He has spent a ton of time trying to make the classes developed for remoting more flexible.  He originally had each class inheriting from the RemotingService class.  I added the dynamic subclassing instead and the methodTable in the constructor. As well as the support for the registered approach via instance names.

Justin

  A            sources/flashservices/discovery.php   1.1
  A            sources/flashservices/registered.php   1.1
  R            sources/flashservices/gateway.php   1.2

2003	Jan (14)	Feb (14)	Mar (58)	Apr (6)	May (61)	Jun (30)	Jul (21)	Aug (7)	Sep	Oct	Nov (10)	Dec (1)
2004	Jan	Feb (11)	Mar (16)	Apr	May	Jun (1)	Jul	Aug	Sep	Oct	Nov	Dec (85)
2005	Jan (31)	Feb (5)	Mar (18)	Apr (7)	May (1)	Jun (13)	Jul (33)	Aug	Sep	Oct	Nov	Dec
2006	Jan (1)	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2007	Jan (1)	Feb (2)	Mar	Apr	May	Jun	Jul	Aug	Sep (1)	Oct	Nov	Dec
2008	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug (1)	Sep	Oct	Nov	Dec
2010	Jan	Feb (2)	Mar (21)	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec

amfphp-cvs Mailing List for Amfphp (Page 18)

amfphp-cvs — CVS list for the AMF-PHP development