RFCs

RFC #0210: Separate contrib & framework versions - vote please!

at 2012-02-01 in RFCs, 5.9-SERIES by friebe

We've worked on RFC #0210: Separate contrib and framework versions, the goal of which is to separate framework and contrib. library versions. While today, all libraries are versioned alongside the framework, e.g. xp-rt-5.8.4 and xp-contrib.stomp-5.8.4, the libraries will have separate versions in the future and instead a pointer to the framework version (range) they depend on. We've therefore gathered all the current libraries inside the xp.contrib repository and have reconstructed their changelog from SVN and Git commit history. The RFC includes these and the version numbers we can derive from that for each library.

Now while we were doing that, we also noticed quite a bunch of deprecated, badly named, unmaintained and otherwise outdated libraries. For the most obvious, we've created RFCs on how to further proceed with them. Please give your votes by adding "+1" or "-1" (and optionally, a reason) as to these proposals in the issue comments.

Thanks!

RFC #0218: Parameter annotations

at 2012-01-28 in 5.9-SERIES, RFCs by friebe

Scope of Change
Annotations on method parameters will be allowed.

Rationale
Originally motivated from XP Framework's pull request #33 - Stubbles IoC container and dependency injection.

Read the full RFC here.

RFC #0231: Remove xp.contrib's "dba" module

at 2012-01-22 in 5.8-SERIES, 5.9-SERIES, RFCs by friebe

Scope of Change
The module "dba" will be completely removed.

Rationale
The io.dba classes where deprecated in the 5.8-SERIES and moved to the ports repository (what is now "xp.contrib") for backwards compatibility on 2010-02-14, almost two years ago at the time of writing.

Read the full RFC here

RFC #0184: Drop SAPI feature alltogether

at 2012-01-21 in 5.9-SERIES, RFCs by friebe

Rationale
The sapi feature was initially introduced to offer a way to extend the XP framework's core code, provided by lang.base.php, in a manner similar to that file, eg. without having to encapsulate that code in a class.

Now, we think code should always be loaded as a class, which bring several features like having an associated classloader.

Functionality
Functionality provided by one of the XP framework's sapi files will be migrated to be provided by regular classes, preferrably backwards compatible.

Read the full RFC here

PHP Namespaces and the XP Framework

at 2012-01-06 in RFCs, PHP5, Examples, 5.9-SERIES by friebe

With the implementation of RFC #0222, we have added optional PHP namespaces support to the XP Framework. Optional means the XP Framework itself will neither depend on PHP 5.3 (still supporting PHP 5.2.10 upward at least for the 5.9-SERIES) nor will it change any of its classes to use them. That doesn't mean you can't use them, though

Here's a quick-start guide:

PHP namespaces use the backslash (\). These translate 1:1 to the package separator in the XP Framework, the dot (.).
Classes with PHP namespaces, fully-qualified and non-qualified XP classes may be mixed in one project. The XP group recommends migrating complete packages.
Inside classes using PHP namespaces, other XP classes need to be either addressed by their absolute fully-qualified names (e.g. \lang\Object) or imported via the use statement by their fully-qualified names; uses() may not be used there.
Inside classes not using PHP namespaces, namespaced classes must be added to the uses() list and addressed in their namespaced version.

As an example, if we have the following in de/thekid/tools/SQL.class.php:

  namespace de\thekid\tools;
  use rdbms\DriverManager;
  
  class SQL extends \lang\Object {
    public static function main(array $args) {
      $conn= DriverManager::getConnection($args[0]);
      // ...
    }
  }

To run this class, use xp de.thekid.tools.SQL ... as you would with a non-namespaced class.

RFC #0222: Optional support for PHP 5.3 namespaces

at 2011-12-23 in 5.9-SERIES, PHP5, RFCs by friebe

Scope of Change
Support for writing and using classes within PHP 5.3 namespaces will be added to the XP Framework's core. Because PHP namespaces are only available with PHP >= 5.3.0, support will be optional - using XP with PHP 5.2.x just will not offer the feature.

Rationale
Add benefit of using namespaces in classes. Namespaces allow reusing class names in a separate context, removing the need of class name prefixes and thus increasing overall code readability.

Read the full RFC here

RFC #0221: Allow combining application properties from multiple sources

at 2011-12-20 in RFCs by friebe

Scope of Change
The util.Properties API will be extended so it is possible to combine multiple Properties objects into one when querying property settings.

Rationale
Often, settings need to extend or modify a set of basic settings, while overwriting or completeing or resetting values. Two examples for this rationale:

different web application profiles (dev, qa, prod) usually share most data, except connection DSNs and log settings.
an application could choose to inherit database DSNs settings from a global Properties file, so there's no need to duplicate them.

Read the full RFC here

RFCs now on GitHub

at 2011-10-20 in RFCs, Announcements by friebe

The XP Framework's RFCs have all been migrated to our new home over at GitHub. Unfortunately, GitHub doesn't offer an importing facility, and the regular API calls neither allow impersonation nor setting dates backwards, so we've lost a bit of information here. In the long run, we believe this isn't going to play much of a role; and since the benefits outweigh the downsides. For example, this way, we now make creating RFCs accessible to the general coding public - your ideas are welcome!

You can find the RFCs in the issue list of our rfc repository.

Enlighten us

RFC #0216 - REST server API implementation

at 2011-10-17 in RFCs by friebe

Scope of Change
Beside of other types of webserives (e.g. SOAP, JSON) support for REST, which is a resource based type of webservice, will be added to the framework.

Rationale
Currently few types of webservices are supported but the standard for webservices is now REST: it's flexible, it's simple and easy to use.

Read the full RFC

RFC #0205: All exceptions can be chained optionally

at 2011-02-26 in RFCs by friebe

Scope of Change
Existing functionality of the lang.ChainedException will be moved into the XP framework's base exception class lang.Throwable. As result, all exceptions can have an optional causing exception attached to them.

Rationale
Only when every exception can have a causing exception attached to it, one can easily make use of it in all circumstances. By now, when such funcionality is required, the exception class in question must be modified to inherit lang.ChainedException. Most of the time, it cannot be fore- seen whether this is required or not at the time of writing the exception class.

Read the full RFC here

You can subscribe to the XP framework's news by using RSS syndication.