PEPr: Latest proposals with status Proposed

PEPr Proposal [556]: Payment::Payment_PayPalSoap

2008-04-28T19:32:33-05:00

Proposed package: Payment::Payment_PayPalSoap

Proposer: Michael Gauthier

This package provides an easy-to-use wrapper of PHP 5's SOAP client

for use with the PayPal SOAP API.

By itself, this package isn't very useful. It should be used in combination with the documentation provided by PayPal at https://www.paypal.com/en_US/pdf/PP_APIReference.pdf. This package makes it easier to get up and running, and allows you to begin integration by making requests rather than by figuring out how to set SOAP authentication headers.

This package requires PHP 5.1.0 or greater, built with the SOAP extension enabled.

PEPr Proposal [553]: System::Daemon

2008-04-19T10:45:37-05:00

Proposed package: System::Daemon

Proposer: Kevin van Zonneveld

System_Daemon turns PHP-CLI scripts into daemons (background processes on Linux).

Some features:

Support for PEAR's Log package
Simple syntax
Methods to determine OS and write startup files (init.d)
Can run with or without PEAR (PEAR adds more elegance & functionality)
Default signal handlers, but optionally reroute signals to your own handlers.
Log levels comply with PEAR_LOG_ levels but are called SYSTEM_DAEMON_LOG_ for (in)dependency reasons
Set options like max RAM usage

Minimalistic Usage Example:




<?php


require_once "System/Deamon.php";





// Set at least these properties


System_Daemon::$appName = "simple";


System_Daemon::$appDir   = dirname(__FILE__);





System_Daemon::log(1, "Daemon not yet summoned. Writing this to STDOUT");





// Spawn Deamon!


System_Daemon::start();


System_Daemon::log(1, "Daemon: 'simple' summoned! Writing this to /var/log/simple.log");





// Your normal PHP code goes here. Only now the code will run in the


// background so you can close your terminal session, and the application 


// will still run.





System_Daemon::stop();


?>

PEPr Proposal [552]: Networking::Net_GPS

2008-04-15T07:50:28-05:00

Proposed package: Networking::Net_GPS

Proposer: Horikita Kei

This package provides GPS (Global Positioning System) information based on HTTP_USER_AGENT strings of (mainly Japanese) mobile HTTP user agents.

It creates url to access to the GPS and provides a method to parse the response.

PEPr Proposal [547]: Database::SimpleDAO

2008-04-02T19:24:59-05:00

Proposed package: Database::SimpleDAO

Proposer: Huilen Abed Moure

SimpleDAO is a Data Access Object generator for PHP 5 and MySQL applications.

PEPr Proposal [538]: RFC::Coding standard enhancements

2008-03-07T11:34:53-05:00

Proposed package: RFC::Coding standard enhancements

Proposer: Christian Weiske

Table of Contents

Introduction

Split function definitions onto several lines

Split function call on several lines

Split long assigments onto several lines

Split long if statements onto several lines

Alignment of function parameters

Alignment of assignments

Introduction

This RFC defines changes and enhancements to the current Coding Standards (CS) in PEAR. They are neccessary because the standards are not clear in some cases. With applications like PHP_CodeSniffer being used, is is important that those issues are worked out and tools can deliver reliable warnings and CS errors.

Split function definitions onto several lines

Functions with many parameters need to be split onto several lines to keep the 80 chars/line limit.

The first parameters may be put onto the same line as the function name if there is enough space.

Subsequent parameters on following lines are to be indented 4 spaces. The closing parenthesis and the opening brace are to be put onto the next line, on the same indentation level as the "function" keyword.

Example:



<?php



function someFunctionWithAVeryLongName($firstParameter = 'something', $secondParameter = 'booooo',

    $third = null, $fourthParameter = false, $fifthParameter = 123.12,

    $sixthParam = true

) {

    //....

?>

Split function call on several lines

The CS require lines to have a maximum length of 80 chars.

Calling functions or methods with many parameters while adhering to CS is impossible in that cases. It should be allowed to split parameters in function calls onto several lines.

Example:



<?php



$this->someObject->subObject->callThisFunctionWithALongName(

    $parameterOne, $parameterTwo,

    $aVeryLongParameterThree

);

?>

Several parameters per line should be allowed. Parameters need to be indented 4 spaces compared to the level of the function call. The opening parenthesis is to be put at the end of the function call line, the closing parenthesis gets its own line at the end of the parameters. This shows a visual end to the parameter indentations and follows the opening/closing brace rules for functions and conditionals. (See bug #11562)

The same applies not only for parameter variables, but also for nested function calls.

Example:



<?php



$this->someObject->subObject->callThisFunctionWithALongName(

    $this->someOtherFunc(

        $this->someEvenOtherFunc(),

        $this->someEvenOtherFunc()

    ),

    $this->wowowowowow(12)

);

?>

Nesting those function parameters is allowed if it helps to make the code more readable, not only when it is necessary when the characters per line limit is reached.

Split long assigments onto several lines

Assigments may be split onto several lines when the character/line limit would be exceeded. The equal sign has to be positioned onto the following line, and indented 4 characters.

Example:



<?php



$GLOBALS['TSFE']->additionalHeaderData[$this->strApplicationName]

    = $this->xajax->getJavascript(t3lib_extMgm::siteRelPath('nr_xajax'));

?>

Split long if statements onto several lines

Long if statements may be split onto several lines when the character/line limit would be exceeded. The conditions have to be positioned onto the following line, and indented 4 characters. The logical operators (&&, ||, etc.) should be at the beginning of the line to make it easier to comment (and exclude) the condition. The closing parenthesis and opening brace get their own line at the end of the conditions.

Example:



<?php



if (($condition1

    || $condition2)

    && $condition3

    && $condition4

) {

    //code here

} 

?>

The first condition may be aligned to the others.

Example:



<?php



if (   $condition1

    || $condition2

    || $condition3

) {

    //code here

}

?>

Alignment of function parameters

To support readability, parameters in subsequent calls to the same function/method may be aligned by parameter name:



<?php



$this->callSomeFunction('param1',     'second',        true);

$this->callSomeFunction('parameter2', 'third',         false);

$this->callSomeFunction('3',          'verrrrrrylong', true);

?>

Alignment of assignments

To support readability, the equal signs should be aligned in block-related assignments:



<?php



$short  = foo($bar);

$longer = foo($baz);

?>

the rule may be broken when the length of the variable name is at least 8 characters longer/shorter than the previous one:



<?php



$short = foo($bar);

$thisVariableNameIsVeeeeeeeeeeryLong = foo($baz);

?>

PEPr Proposal [536]: Streams::Stream_Iterate

2008-03-05T14:04:19-05:00

Proposed package: Streams::Stream_Iterate

Proposer: Philippe Jausions [Wishlist]

Overview

Here's a little class to allow accessing a traversable variable (array, Iterator, etc...) as a stream using callbacks. The variable is transversed and each key/value is passed to the callback(s) to be transformed into a string to be piped into the stream. The stream is read forward-only, and has an undetermined length.

I first developed this class to use with MDB2_Iterator and HTTP_Download (note that HTTP_Download needs the patch of bug #13125 to handle undetermined content size.)

With PHP 5.3+ there will be stream context support for copy(). That will allow to very easily dump data to file (see example)

Code Sample



<?php



require_once 'Stream/Iterate.php';



// Register class as "foreach" protocol

$protocol = Stream_Iterate::register('foreach');



// Some data we can iterate over with foreach (array, Traversable, etc...)

// We'll assume $db MDB2 connection is configured somewhere else

$data = new MDB2_Iterate($db->query('SELECT * FROM sometable'));



// Callback to convert the data into a string that will be

// piped into the stream (any valid callback will do)

$callback = create_function('$key, $value', 'return $key."=".implode(',', $value)."\r\n";');



// Create the context for the stream

$context = stream_context_create(array($protocol => array('subject' => $data, 'callback' => $callback)));



$fp = fopen($protocol.'://subject', 'r', false, $context);



HTTP_Download::staticSend(array('resource' => $fp));



?>

URL Examples

(assuming "foreach" is the name of the registered protocol):

"key" and "value" specify which of the key and value should be passed to the callback and in which order.

foreach://key:value@subject

foreach://value:key@subject

foreach://key@subject

foreach://value@subject

foreach://subject

If not specified, "key:value" will be assumed. So protocol://subject

is equivalent to protocol://key:value@subject

Callback / Method in URL

To each of the URL examples above you can append a query string made up of. These substitute for the context options, possibly leading to more self-explanatory URLs.

callback=function_name

callback=class::method

method=method_name (method will be called only if value is an object)

Example: foreach://value@subject?callback=serialize

TODO

* Possibly move the generic code from Stream_Iterate::register() / unregiter() methods to a PHP_Stream helper class/package to use as stream protocol registry.

* Documentation / examples (besides the test suite)

PEPr Proposal [534]: HTML::HTML_Form_Error

2008-03-02T04:14:55-05:00

Proposed package: HTML::HTML_Form_Error

Proposer: Jacopo Andrea Nuzzi

With this application you can easily validate fields of your form.

This class could also be used to validate query strings.

You can use HTML_Form_Error with several languages:

* English

* Italian

If you are interested to implement/improve or add a new translation feel free to send an email to jacoz@php.net

PEPr Proposal [532]: Validate::Validate_IT

2008-02-23T09:36:16-05:00

Proposed package: Validate::Validate_IT

Proposer: Jacopo Andrea Nuzzi

Validation class for Italy.

This class provides methods to validate:

Postal code (CAP)
Telephone number (and prefix)
Mobile number (and prefix)
Regions (and regions code)
Cities (and cities code)
Fiscal code

PEPr Proposal [523]: Web Services::Plesk

2008-01-06T22:53:12-05:00

Proposed package: Web Services::Plesk

Proposer: Pedro Padron

Plesk is a webhosting control panel. This package provides access to the Plesk API, using PHP Arrays to make the requests (XML strings are also accepted).

The package must be used to send requests according to the official Plesk API RPC documentation. With it you can get domain data, create new accounts, manage services and many other operations.

It will receive a well-formed request Array, convert it to XML and perform the request to the Plesk Agent.

If the request was made using an Array, the response will be returned also as an Array. If it was sent using a XML string, the response will be returned as string also.

Why this package uses Arrays? Arrays in PHP are flexible and easy to manipulate. Please refer to the package documentation to see what it's all about.

This package IS NOT an implementation of Plesk API. This means you won’t find methods such as getAllDomains().

The reason why this package is not a full implementation of Plesk API is because of the flexibility that the API provides. In a single request you can perform several operations, which would save a precious time, and by creating a getAllDomains() method, for example, that flexibility would be lost.

Different applications have different integration needs, so the goal of Services_Plesk is to provide the lower layer of communication between the application and a Plesk server. This way, I recommend you to create your own functions using Services_Plesk to handle the requests to the Plesk server.

PEPr Proposal [514]: XML::SvgGrapher

2007-10-23T06:43:33-05:00

Proposed package: XML::SvgGrapher

Proposer: Guillaume Luchet

This package permit to create SVG 1.1 graph.

Some functionalities (like curve filter, curve marker, curve visuals...) are customizable with plugins.

Currently the following visuals are managed:

line
polyline (a set of connected straight line segments)
bar
circle
3d pie