text:
<ac:macro ac:name="toc"><ac:parameter ac:name="maxLevel">2</ac:parameter></ac:macro>

This document serves as several proposals combined, and consists of the

An overview of various issues and requirements

Requirements (as bullet points)

Proposed Interfaces

Use Cases

The focus of this proposal is on the following:

Basic interfaces for the ZF2 MVC

How these interfaces may interact

It is not intended to discuss the following:

Where code will exist within the filesystem in projects

Final MVC implementations. We will create separate proposals for the default implementations once this proposal is accepted.

In this proposal, we are specifically keeping the following themes from the ZF2 requirements in mind:

General goals:

Easing the learning curve

Improving baseline performance

Make extending the framework (trivially) simple

Developer goals:

Programming by contract

Favoring of the explicit

The primary takeaways from this proposal (or set of proposals) should be that the ZF2 MVC:

must be built with both simplicity and extensibility in mind.

should provide the basic building blocks for creating custom MVC layers; other systems utilizing those building blocks should retain compatibility with these systems and shipped implementations.

will provide a simple, standard MVC solution (though details on that will come in later proposals).

ZF's MVC has grown organically. While the basic, shipped MVC works for many, there are number of limitations that cause issues for those wanting to deviate from the standard workflow.

Page Controllers

In some cases, page controllers (vs. a front controller with many action controllers) are desired. In this paradigm, a separate end-point would be created for a particular controller (or multiple endpoints for multiple controllers), and it would then handle all requests to that end-point. (Page controllers were especially common pre-frameworks.)

Currently, ZF1 is not terribly friendly in this regard. While action controllers can be instantiated on their own, there are a number of soft dependencies on the front controller – e.g. redirects and URL generation typically require pulling the router from the front controller, layout rendering assumes a front controller plugin, etc. While many of these obstacles may be overcome, page controllers should be much easier to create than they currently are.

No Action Controller Interface

If you wish to attach a controller to the MVC, it must extend Zend_Controller_Action, as that's the type tested against, and provides the only blueprint or abstract implementation of a controller in the framework. This is problematic on many levels:

If you do not want the various features of Zend_Controller_Action – action helper integration, _forward(), _redirect(), front controller parameter injection, etc. – there's no way to disable that functionality, as it's baked in. You cannot simply substitute an alternate implementation.

If you want to alter how action dispatching works, you must fight both the dispatcher and the action controller.

The dispatcher sends an "action" argument to the action controller's dispatch() method – but it's actually a method name; you have to pull the actual action name from the request object. This means, again, fighting the framework. This smells of poor interface definition.

A number of developers and organizations have requested the ability to pass arguments to action controllers. This is actually possible – but, again, not easily achievable due to the structure of the framework. In this case, the abstract controller is too limiting for those extending the framework, and smells of restrictive interface definition.

If you want to use a different convention than <action>Action() for dispatchable methods, again, you must pull the action name from the request object. This makes it difficult to mix-in existing service objects and/or controllers from other MVC frameworks.

Basically, we need some sort of action controller interface that allows for both the default, defined use case, as well as alternate implementations to exist side-by-side.

Poorly Composed Responsibilities

Continuing on the subject of Zend_Controller_Action, the class currently has too many responsibilities:

View composition, initialization, and rendering

Forwarding additional controllers

Helper broker (this is actually not terrible, as it composes the helper broker; however, access to the broker is not ideal)

Composition of application parameters

Hook management and lifecycle

Action dispatch

The base action controller interface should only define the minimum requirements for executing an action controller, and everything else should be either:

Composed in (either via controller or setter injection)

Part of application logic

At its basic level, an action controller is a Strategy or Command pattern – the front controller executes the action controller and returns a response. As such, anything outside that scope is likely suspect in terms of design.

ZF1 created a number of server classes: AMF, JSON, XML-RPC, SOAP (we won't talk about REST). These all follow the PHP SoapServer API:

<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
$server = new Server;
$server->setClass($classOrObject, $optionalNamespace); // optionally multiple times
$server->addFunction($functionName, $optionalNamespace); // optionally multiple times
$response = $server->handle();
echo $response;

This API is simple and effective. We've discovered one or two limitations – it would be better to always require a request object to `handle()`, for instance, but overall, it works.

There are some cases, however, where the approach is limited:

Request/Response objects in the services are limited in functionality; if you need to set or get additional headers, you're on your own.

Authentication and Authorization are items often automated in the MVC – which leads to writing extra code for service endpoints in order to make use of these.

No hooks. Having the ability to tie into things like pre/post-handle would be useful for automating things such as authentication/authorization. Currently, while you can program around these, there's no easily re-usable, pluggable way of doing so.

Inability to configure; setting classes/objects/functions, request and response classes, etc. all must be done manually, instead of via options and/or configuration classes.

These often lead to developers wrapping services within the ZF MVC layer. This, however, leads to additional issues:

Each server is basically an MVC in its own right. This leads to duplication of objects (request, response), duplication of logic (dispatching controller + dispatching service), and degradation of performance (Often 5-20x better performance is had by using a standalone service).

No ties/hooks into MVC; you end up needing to disable things like layouts, views, etc. manually.

Making services capable of being configurable, first-class citizens of the MVC would simplify service creation and exposure within applications.

Zend_Controller_Dispatcher_Standard is, frankly, an atrocity. While a dispatcher interface is defined, the front controller, the dispatcher itself, and several other classes all utilize methods that are not part of the interface. This makes it incredibly difficult to drop in alternate dispatch mechanisms.

Why would you want to do that?

Micro-MVCs, or performance-optimized MVCs. Often, a business need may require performance optimizations that the default ZF MVC is simply incapable of providing.

Alternate controller strategies. If you don't want to follow the convention of <name>Controller::<name>Action(), you have to replace both the dispatcher and action controller strategies – and modifying the dispatcher is difficult.

One use case for changing the strategy is RESTful controllers. It doesn't make much sense to have separate actions for each request method – a switch statement and an interface for resources could accomplish this much more quickly.

If you replace the dispatcher mechanism, this means you cannot re-use action controllers between projects, as one may assume the standard dispatcher, the other a custom dispatcher.

In order to be re-usable, the dispatcher interface must contain only the methods necessary for dispatching, and a way to configure itself.

Too Many Hook Points

Right now, we have three layers of hooks within the ZF MVC (from outside -> in):

Front Controller plugins

Action Helper hooks

Action Controller hooks

One common issue on the ZF mailing lists is when and where to register automated processes. There are four answers:

Front Controller plugins, if they don't need to be aware of the action controller, and need to be run on every request.

Action Helper hooks, if they may need to be aware of the action controller, and likely need to be run on every request.

A base action controller extension class, in the init() or pre/postDispatch() hook methods, if action controller awareness must be present, and you want to selectively apply hooks to all or some controllers.

A specific action controller's hook methods, for ultimate specificity.

This presents a number of problems:

Education. Developers must learn the entire life cycle of the standard MVC in order to make good use of it.

Different mechanisms have different specificity. This can be a good thing, but it can also lead to edge cases quite quickly.

Each registers with the system in a different way.

must be standardized:

must allow opt-in behavior. One controller may require hooks, while another might not. An example: service end-points likely may not need view and layout automation, while normal controllers might.

must be implemented in a way that they may be composed in. In other words, neither front nor action controllers should require methods for registering hooks, but rather utilize a collaborator to do so. This allows easy mocking, the ability to setup hooks via extension classes, or runtime configurability.

Usage outside ZF applications

Related to page controllers, it's often useful to integrate Zend Framework within other systems, such as WordPress, Drupal, Joomla, TikiWiki, etc. These systems often provide hook systems that allow you to execute code on-demand. As many ZF applications may utilize a full variety of MVC features, including views, request and response headers, etc., embedding and wrapping the ZF MVC within hooks can be an expedient way to accomplish this task. However, this tends to:

introduce negative performance impact

introduce complicated configuration and setup

Wrapping ZF MVC functionality should be easy to accomplish.

Alternate View Strategies

Currently, ZF only offers a single view strategy, based on using PHP as a template language. Alternate view strategies may be utilized by implementing Zend_View_Interface, but, as with the dispatcher, many methods assume and call more functionality than the view interface defines.

Additionally, some strategies are not easily supported:

"Code-Behind". In this paradigm, individual template pages are called by the front controller, and the templates "wire in" code that will handle specific events, usually through tags:
<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
<% Page CodeFile="Application/Controller/Service.php"
inherits="Application\Controller\Service" %>
This would load the appropriate file, inherit code, and execute it. Currently, this sort of strategy is impossible without introducing an entirely new MVC layer.

Hierarchical MVC. HMVC's primary strength is that it allows for creation of complex content by executing many different MVC triads. As an example, a call to one controller may initiate calls to two additional controllers, each of which may also execute additional controllers; the results will then be aggregated and passed to a view. This is different than "forwarding" in the current system, as the entire request/response cycle of a given controller happens within the body of a single action. This allows manipulating the response to determine what is relevant to the current request.

Strict segregation of templates from development. The default MVC keeps all view scripts under the same tree as the given module. This means that it's more difficult to segregate access easily for designers. Often, it would be easier to put all view scripts for the entire application under a single directory, and give designers access only to that directory. While possible with the view renderer, it's non-trivial.

Additionally, using PHP as the templating language is not optimal for many designers; the ability to utilize a standard template engine would often be easier for purposes of training.

Transform views are not supported currently. Transform views are an alternative to Two Step Views, and often simpler for designers to utilize.

Configuration and Injection of Resources

How do resources make their way into controllers, views, etc.? This question was largely answered in ZF1 with the introduction of Zend_Application. However, this integration is incomplete.

The bootstrap is injected into the front controller singleton

The front controller injects the bootstrap into controllers

All other classes retrieve the bootstrap from the front controller singleton

Two solutions present themselves:

A dependency injection container

A service locator

Either solution is possible with the current implementation of Zend_Application_Bootstrap; it does not specify what type of "container" is used internally.

The question is fundamentally this, however: how should controllers, models, and views get their dependencies/resources? Should we expect the front controller/dispatcher to inject them, or to pass a service locator to them so that they may pull them themselves?

Alternately, should the ZF MVC interfaces care?

ZF's MVC performance has (mostly) steadily declined since the 1.0 release (with the exception of the 1.7 release, when a performance audit was performed). In large part, this is due to additional functionality:

Adding layouts added another view rendering phase to the typical request

Adding Zend_Application and the bootstrap lifecycle

In performance profiling, the ZF team has discovered that the primary source of the bottlenecks is in the !PluginLoader implementation, which (a) has many stat calls, (b) doesn't cache between instances, and (c) differs between components. We have done a large amount of work during the Autoloading & Plugin Loading milestone to correct this situation, but are looking for additional areas we can improve performance in the MVC layer.

The current approach to modules in ZF is very much "tacked on". Due to how they work, it's quite difficult to simply "drop in" third-party code and expect it to work. While this is somewhat better since the introduction of Zend_Application, the requirement to execute a bootstrap for each module that requires autoloading leads to additional performance degradation.

Modules should be considered "first-class citizens" of Zend Framework.

The basic building blocks of the MVC must include standard Request and Response interfaces.

The default implementation must provide HTTP-aware implementations of the Request and Response interfaces.

The basic responsibility of the MVC and Server classes must be to convert a Request object into a Response object.

The primary goals are to:

Create interfaces and loosely coupled objects for creating MVC implementations; and

Create one or more default implementations.

Request object

Must handle both request metadata and optionally content.

Must provide an HTTP-aware Request implementation:

Aware of Request-Method

Aware of Superglobals ($_GET, $_POST, $_SERVER, $_ENV, $_FILES, cookies, sessions, etc.)

Aware of HTTP request headers

Should be aware enough of Content-Type and Request-Method to be able to auto-populate $_PUT and $_POST from the raw request body for any format supported by Zend\Serializer.

Response object

Must handle both response content an optionally metadata.

Must provide an HTTP-aware Response implementation:

Must be capable of aggregating and emitting HTTP response headers and status codes.

Should be capable of manipulating Cache-Control headers

Should be capable of aggregating and emitting cookies

Might be "View-aware", such that getting a View Model or View Renderer as the content would auto-render the view when the response is emitted.

Must provide interfaces and implementations for representing invidivual HTTP headers as well as collections of headers

Should provide interfaces and implementations for representing cookies and collections of cookies

Must provide interfaces and implementations for representing metadata objects (including the superglobals).

The Parameters interface must allow for array access of metadata.

Page Controllers:

Must be able to create page controllers with ZF.

Must be able to utilize page controllers outside the front controller paradigm.

URL generation should be de-coupled from the front controller

Controller "redirection" and/or "forwarding" must be de-coupled from the front controller

Must be able to configure services/resources and inject easily, preferably via the constructor.

Ideally, Action Controllers should be re-usable as standalone Page controllers.

Action Controllers

ZF2 must offer a simple, strong interface for action controllers.

The action controller interface must not require front controller interaction.

Action controller dependencies must be injectable, either through explicit setters or the constructor; the interface should not dictate anything that would prevent this.

The action controller interface must specify a single method for dispatching itself.

Action controllers must allow the flexibility to re-define the conventions for resolving actions.

ZF2 must offer a default implementation with the recommended convention

Action controllers must allow the flexibility to determine whether or not action methods will expect arguments.

Action controllers should optionally allow lifecycle management, preferably via signal slots and/or action helpers.

The default implementation should allow configuring lifecycle management both statically and via constructor injection.

Server classes

Must implement the same basic interface as action controllers, in order to allow them to be composed as part of an MVC application.

Must utilize the same base Request and Response interfaces, and should decorate these in order to allow de/serialization of the protocol format.

Should provide lifecycle hooks, likely in the form of !SignalSlots.

Hooks should be injectable/configurable

Hooks should allow static configuration as well as per-instance.

Hooks for servers should not utilize the same signals as action controllers, to help prevent things such as View/Layout injection.

The basic "Route" interface must:

Provide the ability to match a Request object to metadata tokens.

Provide the ability to assemble a URL/Request based on metadata.

A new "RouteStack" interface should be developed, allowing the ability to provide a stack of routes to test for matches.

Routing could write matched metadata to the Request object metadata.

This is under debate. However, doing so would simplify most workflows for the MVC. The main question is whether this should overwrite such metadata, or whether the RouteStack implementation would return a "RouteResult" object that it would then register as a single metadatum of the result.

Must follow the same basic interface as action controllers and server implementations.

The dispatcher must be responsible for mapping a controller name to a class that will handle it, and optionally injecting configuration.

The dispatcher may be omitted, depending on the MVC created.

Should return a response as soon as it has one.

Front Controller

Must not implement a singleton pattern.

Should be responsible simply for:

Router management

Dispatcher management

Dispatching the request

Application Configuration should be injected into the child objects.

Should provide lifecycle hooks around the router and dispatcher.

Should return a response as soon as it has one.

Lifecycle hooks

All areas where hooks are used must use the same mechanism

In most cases, static configuration as well as per-instance configuration should be supported.

Application configuration

Application-wide (or commonly used) resources must be configurable

Dispatchable objects (controllers, dispatchers, servers, etc.) should accept application configuration, and "wire themselves" based on that configuration.

Configuration management must handle dependencies.

Configuration management must lazy load when requested (i.e., it should not preload all resources)

Performance of the MVC layer must be as fast as possible, while still supporting required features such as layouts, lifecycle management, and application configuration.

Design of any shipped MVC implementations must encourage module re-use, and must support modules as basic MVC infrastructure.

Proposed Interfaces

In examining the requirements, a standard interface for page/action controllers, dispatchers, service providers, and front controllers emerged, essentially a Command pattern:

<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
interface Dispatchable
- Dispatch a request
- Typically, if something dispatchable returns a Response object, that
- Response will be used. Systems could be built, however, that introspect
- the return value in order to determine what type of Response to build.
- On the other end of the spectrum, we could pass a Response object, and
- expect the code to interact with and populate it.
- @return mixed
public function dispatch(Request $request, Response $response = null);

Basically, by making each of these components "dispatchable", we get a number of advantages:

Controllers may be used either standalone, or within a larger application context (cronjobs, message handlers that consume controllers, etc.). This provides the ability to create standalone page controllers,

Server classes may be configured and attached to a front controller. In this case, they can become first-class citizens of the MVC, instead of something tacked on or wrapped.

A front controller implementation need only offer the ability to broker controllers to dispatch. This leads to the ability to slipstream custom implementations that are tuned for specific needs.

To this end, we propose the following interfaces:

Message interface (metadata and body content)

Request interface (extends Message)

Response interface (extends Message, provides a way to emit itself)

Dispatchable interface (takes a Request object, and optimally returns a Response object)

Route interface (takes a request, and decomposes it into a Result)

The basic use case then becomes:

<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
$dispatchable = new DispatchableObject();
$response = $dispatchable->dispatch(new Request, Response $response = null);

Interface definitions have been written and committed to the following repository:

https://github.com/weierophinney/fig-library

with concrete implementations in the "Zend" tree of the "feature/zf-implementation" branch. Below are the basic definitions.

<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
interface Message
public function setMetadata($spec, $value = null);
public function getMetadata($key = null);
public function setContent($content);
public function getContent();
<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
interface Request extends Message { }
<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
interface Response extends Message
public function emit();
<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
interface Dispatchable
- Ideally, returns a Response object.
public function dispatch(Request $request);

Additionally, HTTP-aware versions of the Request and Response interfaces are proposed:

<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
namespace Fig\Http;
use Fig\Request;
interface HttpRequest extends Request
/* accessors for various superglobals */
public function query($name = null, $default = null);
public function post($name = null, $default = null);
public function cookie($name = null, $default = null);
public function file($name = null);
public function server($name = null, $default = null);
public function env($name = null, $default = null);
public function headers($name = null);
/* URI decomposition */
public function getRequestUri(); // Return a URI instance
/* script name */
public function getScriptName();
/* Capabilities
- These may be pushed into an additional interface.
public function getMethod();
public function getETags();
public function getPreferredLanguage(array $locales = null);
public function getLanguages();
public function getCharsets();
public function getAcceptableContentTypes();
public function isNoCache();
public function isFlashRequest();
public function isSecure();
public function isXmlHttpRequest();
/* potential method tests */
public function isDelete();
public function isGet();
public function isHead();
public function isOptions();
public function isPost();
public function isPut();
<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
namespace Fig\Http;
use Fig\Parameters;
interface ModifiableHttpRequest extends HttpRequest
/* mutators for various superglobals */
public function setQuery(Parameters $query);
public function setPost(Parameters $post);
public function setCookies(Parameters $cookies);
public function setFiles(Parameters $files); // Maybe separate component for Files?
public function setServer(Parameters $server);
public function setEnv(Parameters $env);
public function setHeaders(HttpRequestHeaders $headers);
public function setRawBody($string);
/* Capabilities
- These may be pushed into an additional interface.
public function setMethod($method);
/* creational capabilities */
public static function create(Uri $uri, $method = 'get' /** .. more args */);
<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
namespace Zend\Uri;
class Uri
public function getScheme();
public function getHost();
public function getPort();
public function getPath();
public function getQueryString();
public function getBaseUrl();
public function setScheme($scheme);
public function setHost($host);
public function setPort($port);
public function setPath($path);
public function setQueryString($stringOrArray);
public function setBaseUrl(Uri $uri);
public function isValid();
public function __toString();
<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
namespace Fig\Http;
use Fig\Response;
interface HttpResponse extends Response
public function __construct($content = '', $status = 200, $headers = null);
public function sendHeaders();
public function sendContent();
// public function emit(); // send both headers and content; defined in Fig\Response
/* mutators and accessors */
public function getHeaders();
public function setHeaders(HttpResponseHeaders $headers);
<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
namespace Fig\Http;
use Iterator,
- In most cases, extend SplQueue, and then override where necessary
interface HttpHeaders extends Iterator, ArrayAccess, Countable
- General mutators and accessors
- These are items that are technically part of the response headers, but
- not individual headers themselves.
public function getProtocolVersion(); // HTTP 1.0, 1.1
public function setProtocolVersion($version);
- Adding headers
- Also: requires overriding push, unshift to ensure values are of correct
- type.
- Typically, $header will be of type HttpHeader, but this allows addHeader()
- to operate as a factory. Suggestion is to allow HttpHeader objects, arrays,
- or all 3 arguments.
- @param string|array|HttpHeader $header
- @param null|string $content
- @param bool $replace
- @return HttpHeaders
public function addHeader($header, $content = null, $replace = false);
- Allow adding multiple headers at once
- Implementation can vary – could be key/value pairs, array of HttpHeader
- objects, array of arrays, etc – or combination thereof.
- @param mixed $headers
- @return HttpHeaders
public function addHeaders($headers);
- Retrieve named header; returns either false or a queue of headers.
- has() tests for headers
public function get($type);
public function has($type);
- Representation of headers as string
public function __toString();
- Populate object and headers from string
- Accepts text representing all headers, and splits it into either a
- status or request line and all provided headers.
- @param string $string
- @return HttpHeaders
public function fromString($string);
<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
namespace Fig\Http;
interface HttpHeader
public function __construct($header, $value = null, $replace = false);
/* mutators */
public function setType($type);
public function setValue($value);
public function replace($flag = null); // also acts as mutator
/* accessors */
public function getType();
public function getValue();
/* behaviors */
public function send();
public function __toString();
<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
namespace Fig\Http;
interface HttpRequestHeaders extends HttpHeaders
/* Request-Line-related accessors/mutators */
public function getMethod(); // GET, POST, PUT, etc.
public function getUri();
public function setMethod($method); // GET, POST, PUT, etc.
public function setUri($uri);
public function renderRequestLine(); // render the "request line" portion of the header
<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
namespace Fig\Http;
- Represents the HTTP Response headers
- Describes a collection of response headers. As such, it also ensures a status
- code and optional status message.
interface HttpResponseHeaders extends HttpHeaders
public function getStatus(); // Returns HttpStatus instance
/* Sending headers, and testing sent status */
public function send(); // actually send headers
public function sent(); // return boolean headers sent status
/* Specialized response header(s) */
public function setRedirect($url, $code = 302);
/* Methods occurring below here need to be discussed */
/* Potential specialized mutators * /
public function expire();
public function setClientTtl($seconds);
public function setEtag($etag = null, $weak = false);
public function setExpires($date = null);
public function setLastModified($date = null);
public function setMaxAge($value);
public function setNotModified();
public function setPrivate($value);
public function setSharedMaxAge($value);
public function setTtl($seconds);
public function setVary($headers, $replace = true);
/* Potential specialized conditionals * /
public function hasVary(); // Vary header present? (should )
public function isCacheable();
public function isFresh();
public function isNotModified(HttpRequest $request);
public function isValidateable();
public function mustRevalidate();
/* Potential specialized accessors * /
public function getAge() ;
public function getEtag();
public function getExpires();
public function getLastModified();
public function getMaxAge();
public function getTtl();
public function getVary();
<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
namespace Fig\Http;
interface HttpStatus
public function getStatusCode(); // 200, 301, etc.
public function getStatusMessage();
public function setStatusCode($code, $text = null);
/* Testing header status */
public function isRedirect(); // 3XX status and/or Location header?
public function isClientError(); // 4XX status?
public function isEmpty(); // 201, 204, or 304 status?
public function isForbidden(); // 403 status?
public function isInformational(); // 1XX status?
public function isInvalid(); // <100 or >= 600 status?
public function isNotFound(); // 404 status?
public function isOk(); // 200 status?
public function isServerError(); // 5XX status?
public function isSuccessful(); // 2XX status?
<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
namespace Fig;
use ArrayAccess,
- Basically, an ArrayObject. You could simply define something like:
- class QueryParams extends ArrayObject implements Parameters {}
- and have 90% of the functionality
interface Parameters extends ArrayAccess, Countable, Serializable, Traversable
public function __construct(array $values = null);
/* Allow deserialization from standard array */
public function fromArray(array $values);
/* Allow deserialization from raw body; e.g., for PUT requests */
public function fromString($string);
/* Allow serialization back to standard array */
public function toArray();
/* Allow serialization to query format; e.g., for PUT or POST requests */
public function toString();

Routing is an aspect of the MVC that would be affected by these interfaces. The following interfaces would be used within the routing subcomponent:

<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
interface Route
public function setRequest(Request $request);
public function match(Request $request);
public function assemble($name, array $params = array(), array $options = array());
<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
- An implementation would likely extend SplStack and/or Iterator + ArrayAccess
interface RouteStack extends Route
public function setRequest(Request $request);
public function addRoute(Route $route);
public function addRoutes($routes);
public function getCurrentRoute();

Use Cases

The following are examples covering a variety of use cases.

We are discussing currently what exact form $options will take. It will be a service locator of some sort; we are split on whether it will also be a dependency injection container (even if we don't, we will likely make the definition flexible enough to allow using one). For now, focus on the use cases surrounding the interfaces.

Page Controller

One often requested feature is the ability to use action controllers as standalone page controllers. As the Dispatchable interface simply requires that a Request object be passed, this becomes a trivial use case.

<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
$request = new Request();
$request->setMetadata('action', 'foo');
$controller = new SomePageController($options);
$response = $controller->dispatch($request);

Front Controller

The Zend Framework 1.0 front controller is actually relatively simple. It's dispatch() method currently simply routes and then dispatches the request. That paradigm could be used again to provide a simple ZF1 emulation layer:

<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
$controller = new FrontController($options);
$response = $controller->dispatch(new Request);

In the above, the assumption is that $options would contain dependencies – such as a dispatcher, router, etc – and that these would be configured as well. The dispatcher would look like this:

<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
$dispatcher = new Dispatcher($options);
return $dispatcher->dispatch($request);

In other words, it, too, would implement the Dispatchable interface, and be responsible for determining what Dispatchable objects attached to it should be invoked.

This leaves great flexibility of implementation – anything Dispatchable can be used as an action controller.

Internally, plugins would be swapped out in favor of SignalSlots, giving some additional flexibility of implementation, as well as simplifying the front controller implementation.

<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
$controller->signals()->connect('router.start', new RouteInitializer())
->connect('router.stop', new ModuleInitializer())
->connect('dispatch.start', new LayoutSwitcher());

Basically, the front controller would simply become a Facade for managing the workflow of other objects.

Server Classes

ZF currently provides a number of Server classes: Zend_Json_Server, Zend_XmlRpc_Server, Zend_Amf_Server, etc. These would all follow the same interface:

<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
$server = new Server($options);
$response = $server->dispatch($request);

These would likely use either extensions to the base Request/Response classes provided, or decorate them in order to provide de/serialization of the protocol for which they are responsible. (Decoration offers the most flexibility for differing use cases.)

Because they implement Dispatchable, they could be mixed in as just another dispatchable within a Front Controller implementation, or executed in standalone endpoints:

<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
$server = new SoapServer($options);
$server->setClass($someClass, $namespace);
// Tell the dispatcher that the "soap" controller refers to the $server instance
$mvc->getDispatcher()->register('soap', $server);

Micro or Custom MVC stacks

When dealing with either small sites, or large sites with specific performance requirements, rolling a custom MVC stack is often useful. The current ZF1 implementation does not make this easy. The proposed interfaces do, however. Consider the following, callback-oriented dispatcher implementation:

<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
use Zend\Stdlib\Dispatchable,
Zend\Http\Response as HttpResponse,
class Dispatcher extends Dispatchable
protected $controllers;
public function attach($spec, $callback = null)
if (is_array($spec) || $spec instanceof \Traversable) {
foreach ($spec as $controller => $callback)
return $this;
if (!is_scalar($spec))
if (!is_callable($callback))
$this->controllers[$spec] = $callback;
return $this;
- Dispatch a request
- @param Request $request
- @return Response
public function dispatch(Request $request)
if (!$controller = $request->getMetadata('controller'))Unknown macro: { return new PageNotFoundResponse( '
Page not found
' ); }
if (!array_key_exists($controller, $this->controllers))
$handler = $this->controllers[$controller];
$response = $handler($request);
if (is_string($response))
if (!is_object($response))
if (!$response instanceof Response) {
if (!method_exists($response, '__toString'))
return new HttpResponse($response->__toString());
return $response;

Don't worry about the various objects referenced; the main thing to understand is that it's using those same MVC building blocks: Request, Response, Dispatchable. In action, it looks like this:

<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
use Zend\Controller\Router,
$request = new Request;
$router = new Router;
- Configure some routes here. We'll assume we've somehow configured routes
- mapping the following controllers:
- - homepage
- - foo
- - rest
- - foobar
$dispatcher = new Dispatcher();
->attach('homepage', function($request) {
// Simply returning a string:
return '
Welcome

Welcometo our site!
';
->attach('foo', function($request) {
// Simply returning a string:
return '
Foo!
';
->attach('rest', function($request) {
// Example of a "REST" service...
switch ($request->getMethod()) {
case 'GET':
if (!$id = $request->query('id', false))
// We have an ID – fetch it and return the page
case 'POST':
// Create document and return a response
case 'PUT':
if (!$id = $request->query('id', false))
// We have an ID – fetch and update from PUT params, and
// return a response
case 'DELETE':
if (!$id = $request->query('id', false))
// We have an ID – delete, and // return a response
return new ApplicationErrorResponse('Unknown Method');
->attach('foobar', function($request) {
// Curry in controllers to allow them to be lazy-loaded, and to ensure we
// get a response object back (Dispatcher will take care of that).
$controller = new FooBarController();
return $controller->dispatch($request);
$response = $dispatcher->dispatch($request);

The same MVC building blocks are combined in this example to produce something that looks quite different from the ZF1 MVC – yet can pick and choose pieces from the ZF2 MVC and interact with them in a standard way.

Using Traits instead of inheritance

Due to the simple nature of the Dispatchable interface, it lends itself well to PHP 5.next's traits features. As an example, a "REST" trait could be mixed in to a class quite easily to create a REST controller.

<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
trait RestDispatcher
public function dispatch(Request $request, Response $response = null)
if (!$request instanceof HttpRequest)
$resource = $this->getResource();
switch (strtoupper($request->getMethod()))
return $response;
// In a controller file:
namespace Blog\Controller;
class Entry implements Dispatchable
use RestDispatcher;
public function getResource()

While ZF2 will target PHP 5.3, we can also potentially provide ready-made traits for those using PHP 5.next. This will help simplify development for end users.

Dec 22, 2010

Some quick comments on the subject matter that are not explicitly stated but should be:

Configuration and Injection of Resources

I would go with a Service Locator as it would allow the most flexibility in terms of the concrete implementation to fetch what it may or may not need without the need to largely inject what is needed. Since the configuration and injection of these resources should likely be consistent AND expected in terms of development, it would make sense to utilize the Service Locator as it would be a dependency at this point in time thus enforcing it would be available for folks that are adding on in the future with little additional work which would also keep performance slightly faster when looking up several different items.

Request and Response objects must not be completely tied to HTTP requests.

CLI is a perfect example of this where $_SERVER is for HTTP as $_ENV is mainly for CLI

The implementations of Request and Response is largely different depending on the implementation throughout the current ZF 1 and should largely be tied to Request objects that can be of any type that implement that interface.

Some good examples of this are thing such as implementing a Gearman Wrapper - you want to display jobs based off of the CLI and be able to inject them that way. This is also where a Page Controller would help explicitly.

Dec 28, 2010

I'm definitely leaning towards a Service Locator that implements lazy loading. As you note, it would reduce the amount of overhead necessary during application initialization to only what is needed for that particular controller. (Symfony 2 even invokes this same paradigm, passing the service pull the dependencies they need.) locator – which contains the DI container – to controllers so that they may

There is no intention to tie the Request and Response objects to HTTP. If you look at the interfaces, the most basic versions are not HTTP aware, and HTTP awareness is provided by implementing specific interfaces. The idea is that for controllers you wish to re-use in different contexts, you would program towards the most compatible interface.

Thanks for your input!

Dec 22, 2010

I'm not sure if we can discuss all the interfaces without discussing the behavior, having said that...

The basic building blocks of the MVC must include standard Request and Response interfaces.

Is by that meant interfaces that are shared/used across several frameworks (ZF, symfony, etc)?

What do you understand by both Action Controllers and Page Controllers, what purpose do they suite, and how do they differ?

Application-wide (or commonly used) resources must be configurable

Imho, once done initializing (bootstrapping) we shouldn't allow for further configuration.

I skimmed over the page quickly, so I'm sorry if I missed something (will look at it more closely later) <ac:emoticon ac:name="wink" />

Dec 28, 2010

Is by that meant interfaces that are shared/used across several frameworks (ZF, symfony, etc)?

Potentially. Fabien Potencier, lead for the Symfony project, discussed this idea with me at ZendCon, and I began work on defining shared interfaces. However, we have not at this point solidified any plans in this direction.

The point of the wording is that we will explicitly define interfaces for Request and Response objects, and that these will be used across the framework – both in the MVC (where they may be used for both HTTP and CLI requests), as well as in server components (which are a form of MVC, with the presentation format strictly defined) and service clients (HTTP client, REST client, etc.).

"Application-wide (or commonly used) resources must be configurable." Imho, once done initializing (bootstrapping) we shouldn't allow for further configuration.

I wasn't trying to imply differently.

Jan 18, 2011

With time closing in on finalizing the proposal, has any additional effort been given to coming up with cross library interfaces? I think both communities have some outstanding people working with/for them, so any ability to leverage more resources has the potential to benefit all involved.

That said, I completely understand that getting two projects coordinated is an incredibly difficult tasks since both will be on different release schedules and may have licensing/ownership issues, etc.

Dec 22, 2010

On last example I see you are using a request object of Zend\Http component.

1. Will Zend\Http\Request be similar to Zend_Http_Client of zf1 now also used on mvc ?

2. If yes, we'll have to fill the request object with current data (get, post & friend)

or how to create an own request with own data to send an own request to a remote server ?

<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
// dispatch + emit
$request = Zend\Http\Request::createFromSapi();
$response = $dispatcher->dispatch($request);
// send + emit
$request = new Zend\Http\Request();
$response = $request->send();
Dec 28, 2010

Zend\Http\Request would be an HTTP-specific Request implementation – and would be used in both the MVC, as well as Zend\Http\Client.

The request would not have an emit() method – the client would.

Dec 22, 2010

At a glance there seems to be something smelly going on in the last code sample.

There seems to be no relation between the Router and Dispatcher.

I guess the Router is mutating the Request object somehow, and I don't particularly like that idea. As it means the Request has to go via a Router first, or some some magic has to alter the Request first before being dispatched.

Either passing the Router to the dispatcher, or the dispatcher to the router, and making the request immutable would be more preferable maybe (requires more thought)

Dec 23, 2010

As written, we still have to discuss whether the router should manipulate the request object or not. I personally feel better to return the RouteResult object, as I dislike to have the router manipulate the request, but this could be a problem with an event driven dispatcher implementation.

Dec 23, 2010

Another option would be for the router to decorate the original request with say a DispatchableRequest interface.

Dec 24, 2010

Mh, decorating... reminds me of christmas trees <ac:emoticon ac:name="wink" />

Dec 28, 2010

This is the route (pardon the pun!) I'd like to take. The reason being that passing just a request object to a dispatcher simplifies a number of workflows. As an example, I worked on an event-oriented dispatcher at one point, which made it difficult to allow different return values – it was much simpler to simply pass each event the request object.

This would be fairly simple – DispatchableRequest would simply define two methods:

<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
public function setRouteResult(RouteResult $result);
public function getRouteResult();
Jan 10, 2011

After more thought I think the Request object should be immutable.

I cannot see why you would need to access the RouteResult more than once (just to dispatch it).

Having the Request immutable allows you to cache the RouteResult per Request by decorating the Router instead.

Something like this...

<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
class Caching extends Decorator implements \Router
protected $requestActions;
function __construct(\Router $router)Unknown macro: { parent}
function lookupAction(\Request $request)Unknown macro: { if ($this->requestActions->contains($request)) return $this->requestActions[$request]; $action = parent}
Dec 23, 2010

"Hierarchical MVC. HMVC's primary strength is that it allows for creation of complex content by executing many different MVC triads."

This would be just great.

Exactly my problem ATM. <ac:emoticon ac:name="smile" />

Dec 27, 2010

HMVCs seem quite compelling but also demanding.

Quite a good article here I thought:
http://techportal.ibuildings.com/2010/02/22/scaling-web-applications-with-hmvc/

...and a follow up to it optimising with caching and even (to an extent) asynchronous processing:
http://techportal.ibuildings.com/2010/11/16/optimising-hmvc-web-applications-for-performance/

Dec 28, 2010

They can be demanding, but a number of developers have created such implementations in ZF – and wished that the structure of the framework was such that it more easily facilitated such endeavors.

As such, my hope is that the proposed interfaces can accomplish this.

Jan 08, 2011

I noticed that the PECL extension HttpRequestPool (http://www.php.net/manual/en/class.httprequestpool.php) is being used in that second article. Perhaps an implementation of this can be included with the new MVC also?

Dec 23, 2010

Generally speaking the interfaces look quite good. But the HttpResponseHeaders interface is bloated a little bit. For testing the header status wouldn't it be better to do some chaining like:

<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
>isSuccessful(); $httpResponseHeaders>getStatus()->getCode(); // ... and so on

Furthermore there are some inconsistencies like the sent() method. Shouldn't it be named isSent(), wasSent() or something like that?

Dec 28, 2010

These are great suggestions, and I plan to incorporate them. <ac:emoticon ac:name="smile" />

I chose "sent()" for its brevity – but since we don't have a "?" operator for testing booleans in PHP, you're right – "isSent()" makes more sense.

Dec 25, 2010

This is looking good overall. A few notes:

>> Routing could write matched metadata to the Request object metadata.

I would like to see the request object as immutable.

>> Application Configuration should be injected into the child objects.

>> Application-wide (or commonly used) resources must be configurable

It would be helpful if these always needed a key prefix (assuming a similar style to resources.*) so > 1 of each resource could be configured. For instance, it is often necessarily to have two mail objects configured differently. Of course, this can be done today with a bit of massaging; however, a consistent and supported API would be a bit nicer.

>> Design of any shipped MVC implementations must encourage module re-use, and must support modules as basic MVC infrastructure.

Are we talking in terms of Symfony "bundles" and Rails Engines or are we talking about the current nomenclature of a module as a directory of controllers? I'm hoping we are talking about the former as I believe the latter can be more cleanly handled with routing and namespaces.

Dec 28, 2010

I would like to see the request object as immutable.

This is a no-go for me – making it immutable makes testing more difficult (need to use different implementations for testing than you do for the application), and also means it cannot be used easily in other contexts (server classes, where the request would be decorated in order to deserialize the request to PHP data structures).

For instance, it is often necessarily<ac:link><ri:page ri:content-title="sic" /></ac:link> to have two mail objects configured differently.

I'd argue for situations like these, you either create a "manager" object, or we ship one in the framework (much as we've done for cache, log, DB, etc.). That makes the story of having multiple related resources simpler, and more easily configurable.

Are we talking in terms of Symfony "bundles" and Rails Engines or are we talking about the current nomenclature of a module as a directory of controllers?

Definitely the former – the idea is self-contained functionality, which would require controllers, models, views, all resources, etc. to enable that module to work.

(This was the goal of modules in ZF1, and partly realized with Zend_Application, but the idea is to be more explicit with ZF2.)

Dec 29, 2010

making it immutable makes testing more difficult (need to use different implementations for testing than you do for the application)...

I can appreciate this stance; however, I would argue that it would probably be better to test based on the interface which would allow 1..N implementations?

...it cannot be used easily in other contexts (server classes, where the request would be decorated in order to deserialize the request to PHP data structures).

If this truly is the deal breaker, then I would have to agree with your stance.

you either create a "manager" object, or we ship one in the framework

Fair enough <ac:emoticon ac:name="smile" />

Definitely the former - the idea is self-contained functionality, which would require controllers, models, views, all resources, etc. to enable that module to work.

This is good.

Jan 03, 2011

I would like to see the "Message" interface as an implementation of Serializable. Since the message object is at the main tier there is an extreme amount of usage for this object. It would be quite easy to extend this on our own, however, there is quite a bit of usage specifically for it to be an implementation of serializable by default.

For instance:

Flash Messaging

JSON Payloads

Apple APNS Payloads (meta data could contain implementation for the specific keys)

Google C2DM Payloads

Previous request methods

Also with the "Message" interface, I am unsure about the following methods:

public function setContent($content);

public function getContent($content);

Is this meant to be an array going to set for content? Or a method to set just a string of body content? Not sure what get is supposed to do while taking a parameter... maybe a typo?

Jan 03, 2011

re: Message being Serializable – good point, and I think that makes sense.

re: setContent/getContent(). First, I've now updated the proposal to remove the argument to getContent(); it was indeed a typo. As for what $content should be, I specifically didn't typehint it, to allow flexibility in what the argument may be. This will allow passing a string, an array, an object – it would be up to the individual implementations to determine what valid content might be for a message.

Jan 04, 2011

Regarding the

The question is fundamentally this, however: how should controllers, models, and views get their dependencies/resources? Should we expect the front controller/dispatcher to inject them, or to pass a service locator to them so that they may pull them themselves?

I believe that passing the service locator or DI container into controllers, and views would make the code in the controller/view easier to understand since the service needed for the execution would be in the same place they are needed.

Not sure though if this would have an impact on unit testing controllers.

I really love the idea about Hierarchical MVC. And if I understood correctly it would be possible to create an implementation of ESI quite trivial. A had a look at Symfony 2 ESI implementation and this is maybe the most important feature I would like to see done well in ZF2 because fetching parts of the page from memory at the reverse proxy level is order of magnitude faster that hitting the application on every request.

Jan 17, 2011

I'm definitely interested in investigating ESI for ZF2; I can't tell you how many times the "personalization problem" has bit me, and ESI definitely provides a solid solution for it. Right now, however, that investigation is a bit further down the line in the milestone.

Jan 09, 2011

I was wondering if the Response object should also be Dispatchable?

<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[$reponse = new Response();
$response->dispatch( new Request() );]]></ac:plain-text-body></ac:macro>

The Dispatcher::dispatch method could then keep dispatching until either Request::isDispatched() (or similar) is true or the maximum number of dispatches allowed is reached.

The return type of the dispatch method could then be null or another Dispatchable object.

Jan 17, 2011

While I see the elegance of this approach, I also worry that a semi-recursive structure like this would lead to difficulty in debugging and learning the framework. That said, since we can't type-hint on the return value, we could certainly check for a Dispatchable return and execute it.

Jan 11, 2011

The HttpResponse interface is currently sending the headers to the client by usage of Sendheaders and Sendcontent. Wouldn't it be better to change the methods to getHeaders and getContent? Because it not always clear where you want send the headers and content. Maybe you would want to log the headers and content?

Furthermore, the HTTPResponse Interface should also be usable for Zend\Http\Client ( or the ZF2 equivalent )

The same applies to HTTPRequest & HTTPRequestHeader & HTTPResponseHeader

Furthermore the great number of isValid, isEmpty, is* is confusing, and should be reduced to a more normal limit

isOk the isSuccesfull should be enough for most cases

isInformational not many people will ever need this.

isServerError, isInvalid and isClientError should be combined in isError. People are most interested if it was succesfull or not. If people need more information, they can easily get this from getStatus.

Jan 17, 2011

HttpResponse has both get(Headers|Content) methods as well as send(Headers|Content) methods. Sending the response is done with emit() (defined in the base Response interface).

Regarding the various response status testers, another commenter had a good idea: move the status into its own object. This allows us to trim down the HttpResponse interface, while still having a rich interface for testing status.

I agree that we should have an isError() method – but this shouldn't rule out the more specific tests.

Jan 19, 2011

I like the suggestion for trait in dispatch. Good new PHP feature!

I've looked at Kohana and Alloy frameworks in respect of HMVC. I think I get it.

Would like to suggest the view interface provides for a view-html-header object which is accessible to every (cloned) instance of view for each triad. What I mean is you can mess with the current instance of view and you can also call on it to change the unique state the view-header object. I don't think view has been addressed yet fully.

I still don't see the justification for a Zend_Application or a front controller - sorry. Better to create a Zend Core that also provides the signal-slot pattern for all classes extending it and then also provide resource grabbing such that based on the config, somehow you just call a resource as needed from anywhere and you get it

If magic methods are undesirable it's getResource('request'), getResource('log') etc. and all lazy loaded in the core class of course - like a kernel for everything but not a singleton unless it has to be.

In fact if every class extended a core class there would be no need for any singletons at all. Is that good or bad testing-wise? Perhaps convenience methods for the most often called resources?

I'm still not sure how modularity would work for that but, perhaps a search list of resources in place of a namespacing would be okay if constants provided a convention for those common resources we all use? I like the idea of everything being a resource to simply call and not existing until referenced.

Is there any chance of a changing demo showing HMVC capability? Nothing fancy, just flesh on the bones as I seem to be a learn-by-example type and would like to know the ZF2 interpretation re: PAC/HMVC on Wikipedia. Can the view call a new MVC triad for example? I hope so, but not assume the view can access the model.

Finally the caching. Caching specific parts of the output seems ideal to me - as much or little as you want of the output - so it should be a stage before each MVC call I think and using existing HTTP standards as per: http://docs.symfony-reloaded.org/guides/cache/http.html#using-edge-side-includes

Jan 28, 2011

Mark, thank you for the very good article <ac:emoticon ac:name="smile" />

Within this proposal I don't understand the difference of the following methods of HttpResponseHeaders: (setExpires and setMaxAge will set the headers but what does the others ?)

<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
// va.
setExpires($date = null);

Another question is why does the method "HttpResponseHeaders::isNotModified" need a Request object as parameter?

By the way it would be helpful to auto-generate cached responses by storing the sent response locally

cache only on GET/HEAD requests

cache only 200 responses

generate cache id in base of request

(URI + Vary-Headers ...)

generate ETag in base of response (if not present)

generate Last-Modified by mtime of cached item (if not present)

create 304 response if:

response was cached before

ETag of cached response matches requested If-None-Match

Last-Modified of cached response matches requested If-None-Match

create 412 response if:

ETag of cached response doesn't match requested If-Match

Last-Modified of cached response doesn't match requested If-Unmodified-Since

<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[

Now you can also send a cached raw response if the client doesn't cached this resource before.

Please correct me if I'm wrong.

Jan 19, 2011

PS. If you don't want to cache by time-out you cache when it reaches the controller based on DB change and I guess handle that manually.

Feb 05, 2011
<ac:macro ac:name="note"><ac:rich-text-body>
Community Review Team Recommendation

At this stage we accept this proposal, and suggest moving forward to implementing it. The CR-Team recognizes that when problems arise while implementing the interfaces, it may be possible to slightly deviate from this proposal (when discussed with the community).
</ac:rich-text-body></ac:macro>


text:
New Arrivals
mouse over photo to zoom click for larger image
Floral Scarf Print Jersey Knit Dress
Silky, fluid matte jersey in an on-trend scarf print has touches of spring's Very Berry and Begonia. The silhouette couldn't be easier to wear, with an empire waist, 3/4 button-accented sleeves and an A-line skirt. Shell: 95% Polyester, 5% Spandex. Lining: 100% Polyester. Machine wash, cold; tumble dry low. Or dry clean. Imported.
- Pullover style; stretch fit.
- Contast border print defines empire waist. Darted bust. Tabbed 3-button detail and ruching on the sleeve.
- Silky lining through the bodice. Bra strap tabs.
- Length: 36".
We're so sorry: this item sold out sooner than expected. For an equally stylish substitute, please call our Style Experts at 1.877.948.2525. Or click on Live Help below for immediate assistance.

subset: commoncrawl


text:
|Downtown Portland
|Southeast Portland
|North Portland
|Southwest Portland
|Northeast Portland
|Northwest Portland
|Clark County, Wash.
Registration on or use of this site constitutes acceptance of our User Agreement and Privacy Policy
© 2014 Oregon Live LLC. All rights reserved (About Us).
The material on this site may not be reproduced, distributed, transmitted, cached or otherwise used, except with the prior written permission of Oregon Live LLC.
Community Rules apply to all content you upload or otherwise submit to this site. Contact interactivity management.


text:
Gosh, I don't even remember.... the past is really fuzzy cuz Trey dominates my mind. HA!
How about you? I'm curious what's your musical background before Trey came into the picture?
Gosh, I don't even remember.... the past is really fuzzy cuz Trey dominates my mind. HA!
How about you? I'm curious what's your musical background before Trey came into the picture?
Gosh, I don't even remember.... the past is really fuzzy cuz Trey dominates my mind. HA!
How about you? I'm curious what's your musical background before Trey came into the picture?
not was still is MJJ, Stevie Wonder, and Ne-Yo then Trey ...but Justin Timberlake used to b in there and Marques Houston was there during middle school...nice question!
I was pretty much in love with Tyrese. Then changed my mind and went to Jamie Foxx. Every since then it's been all Trey.
I had four favorites = Giuwine, Joe, Babyface & Avant! I still support them & buy their music. It's very few artists that I have all their music, but I have all their stuff. Love them to pieces!
While Trey is my favorite R&B singer at the moment, still my all-time favorite (unreplaceable...expands across all music genres) is Michael Jackson. His music is timeless & even if he will never have another album (unless he pulls a Tupac), what he has on the shelf now will outlive anything FOR ME that has already been done or will ever be done in my lifetime. When I say I love Michael Jackson's music - trust and believe that I do. No one touches him in my eyes!
i was in LOVE with nelly in middle school i mean if u knew me then u knew he was the 1, it was crazy and i had a lil somthing for que from day 26 but nothing like trey
Asgree w/ ROS! I had just gone to a GL concert, along w/ JE, Avant (wuz majorly in luv w/ him), Brian McKnight, J.O.E. (sexy bald-headed ass, umppp), Genuwine (only his music) & Jodeci.
Big fans of them all! I wuz also into Usher (confessins wuzs the CD!!!), Tyrese, Maxwell, Jaheim, Mario, Robin Thicke, Pleasure P/Pretty Ricky, Omarion/B2K(he wuz cute & sexy as heck), Marques Houston (naked had me), wuz still listening to R. Kelly, Ne-yo, TANK (still luv him) & Bobby Valentino! Mr. Ray J had also stepped on the scene & I wuz liking his One Wish & Wait a Minute. Hes sexy too, hehe! I like all their music, but none of them, I mean none, well maybe TANK, can compare to the sexiness & talent of Mr. TreySongz! When he stepped onto the scene, I forgot about all them, lmao!
I liked CB too, but he came out w/ Run It during the fall of 2005, when Trigga came out in the early summer of 2005, so I wuz jammin Trigga FIRST! I like CBs music bc I can dance to most of his music.
I use to love me some Ginuwine! (Still do, just not as much as I love me some Trey) Other artist that I liked before Trey are B2K, Imajin, the young Bow Wow (always disliked grown up Bow Wow), IMx, Mario, Neyo, Dru Hill, Playa, Chris Brown, B5, Jodeci, Silk, Robin Thicke, Usher, and Tevin Campbell of course!
My favorite was Ginuwine before Trey and I went just as hard for him as I do for Trey now. People say I just threw G away when I ran across Trey. Damn Trey just be dominating peoples ears and heart!
Omarion and he still is, Ray J, B2K (Just for Omarion though), Chris Brown, Diddy!! To much to name Omg B5 lol
I use to be in love with Ginuwine whwen he first came on the scene. But other than that there was no one and I was surprised at how I fell so hard for Tremaine.
Befor i heard Trey i was a really big fan of usher and T.I !
I still am a huge fan of usher but Tremainz my favourite !
hmmm idek i was never really into an artist this much. i love music, so, i enjoy many different songs, of different genre and artists, but really too sign up on a site n b checking it daily n make overseas calls on my phone just to hear his voice n stuff. nawh
I enjoyed a lot of male artists and groups before Trey came out. As a matter of fact, I liked everybody that @Rolanda named, and Usher, Dru Hill and Boyz II Men, Tevin Campbell, Gerald Levert, Tupac and Biggie.
Of course, I would have had to have been born in this century, if I couldn't say that I also LOVED New Edition, Prince, and Michael. Dag, I was listening to them before Trey was even born...Wow I'm old. LOL.
But the way I loved Ray J was similar to how I feel about Trey now, and when I liked B2K, I was really into guys who dance. Stomp The Yard is my all time favorite movie about guys who dance. I'm watching that right now, as a matter of fact. There's just something about fine ass black men that can dance. Then again, there's something really sexy about the ones who can sing...
Well as far a male artists goes I will always and forever support Usher.. And I've continuously supported Trey every since he's been on the scene.. Outside of them the other artists in my ipod are Tyrese, Maxwell, Jaheim, Mario, Justin Timberlake/Insinc, Silk, Jodeci, Robin Thicke, Pleasure P/Pretty Ricky, Omarion/B2K, Bow Wow, Marques Houston, R Kelly, Lloyd, Chris Brown and basically any artist with great music just because I love music in general. But as far as spending loot to meet and greet.. Trey and Usher are the only two artists that has ever gotten that type of love from me.. Now the ultimate artist Prince can still get my money when he goes on tour.. "no doubt about that".
@cuttgurl609: I stopped watching videos for a long time too. I guess as you get older they aren't as interesting. But I do like watching Trey's videos.
Oh yea I almost forgot but before Sisqo it was that boy group Imajin. I don't know if ya'll are familiar with them but they had a short career but I do think if it was longer I would have supported them heavy I had posters in my room and I listened to their ONE cd everyday after school lol
I didn't really have a fav male artist before Trey. I'm a singer and I love music but I actually stopped listening to the radio and stopped watching videos on my own until Trey really hit me. I didn't like wut music had become.
I did listen to certain artist like, I've bought Usher, Chris Brown, B2k, Pretty Ricky cd's but thats about it. Michael was always my all time fav but he wasn't really puttin too much out. Kelly Rowland still is my fav female artist. I am Beyonce lol at least thats wut i think when i'm dancin or singin along with her music.
Oh yea but back in the day when i was like 14 I was in love wit some........ SISQO "Yeeeeaaaaaa Yeaaheeeaaaa Yeeeeeaaa!!!!" lol He used to sing his butt off but he became a Diva and uggghhhh i can't stand a Diva especially a male Diva


text:
|Get Crafty
Event Type: Adult Programs
Age Group(s): Adult, Seniors, Teens
Date: 8/24/2013
Start Time: 10:00 AM
End Time: 12:00 PM
Get together with fellow crafters on the 4th Saturday of every month for a creativity blast! Bring your own projects and work on knitting, crocheting, embroidery, scrapbooking, writing, or whatever you enjoy crafting. Show off your finished projects and check out what other people are doing. Join us in a social atmosphere to craft, chat, and get inspired.Library: Millard Branch (402.444.4848)
Location: East Meeting Room
Contact: Melanie F. Schultz
Contact Number: 402.444.4848
Status: Closed


text:
Includes 2 Containers, 2 Hangers, 2 Baskets and Changing Mat
Order in the next 19 hours 17 minutes and select next working day for delivery to mainland UK on Tuesday
Why buy me?
The Stokke Care is the changing unit that evolves with your baby. It provides an adjustable ergonomic changing environment to give you and your baby a unique safe space to interact and bond. Goes on to convert into a small desk ideal for the homework days.
About me
Want to learn more?
The innovative people at Stokke have turned the traditional changing table on its head. Ergonomically designed so that you face your baby at changing time and providing space for you to literally get your feet under the table so you can get closer to your little one, facilitates eye contact, physical interaction and emotional bonding. The changing table also has two different height options so you can choose which one is most comfortable for you.
Two large storage baskets are supplied to sit on the shelves and are ideal for nappies, towels, cloths and wipes. The two smaller plastic containers fasten onto each side of the changing unit to keep smaller items like nappy cream and cotton wool organised and within easy reach. A metal rail on each side provides extra room to hang clothes or a bath towel. All the storage has been tailor made so that everything you need is reachable without having to change focus from your little one. The water-resistant mattress is non-slip, easy cleaning and hygienic - and, quite naturally, comfortable!
Suitable for nappy duty until your baby is 12 months old, or 11kg, the changer can go on to be used as a bookshelf, TV station or transformed into a small desk ideal for two children to sit and play games or draw at. There is also the option of further conversion into a larger desk with the extended table-top kit (sold separately).
Extra details
I come with
There are no reviews for this product.
Click for audio and text help.
Click for audio and text help.
Click for audio and text help.
Click for audio and text help.
This product is available as a pre-order. This means that we do not currently have the item in stock but we are expecting it shortly. You can place an order for this product now your expected shipping date will be 17-04-2012
A place where people come together to discuss our products and services, ask questions and seek advice.
to be a part of it.


text:
Findwell, a real estate brokerage, relies on technology to keep agents available to clients. Without a dedicated IT administrator, keeping lines of communication open was not always easy. The company now uses Microsoft Office 365 for cloud-based email and document sharing, making it easy for agents to maintain access to information and be more responsive to their clients from anywhere without the need to support an IT infrastructure.
Business Needs
Findwell aims to be more than your average real estate agency. Founded in 2008, the company delivers real estate brokerage services to home buyers and sellers, offering them dramatically lower fees through the use of technology and an innovative business model, while still providing exceptional service. Findwell is trying to grow in a difficult real estate market—and succeeding.
One of the company's primary objectives is to make its real estate agents accessible at all times. "If clients see a home and want to put in an offer, they want to be able to reach their agent immediately so that they don't miss the opportunity," says Kevin Lisota, Chief Executive Officer of findwell. "As agents, we are most often in the field, not the office, but we need constant access to information for our clients. We also need to quickly respond to email from prospective clients because, if we don't, they could go elsewhere and the missed opportunity would cost us thousands."
Keeping lines of communication open requires attention from an IT perspective, but findwell does not have a dedicated IT administrator. "We are a small business, so I take care of IT provisioning, training, management, and maintenance," says Lisota. "I am fairly technical, so I don't mind the work, but the time that I spend managing our IT infrastructure to keep everyone connected with their clients and each other is time that I am not spending on building our business."
The transition to Office 365 went so smoothly that findwell employees had no idea when it happened. "We use Microsoft Exchange Online and Microsoft SharePoint Online just as we used to use the on-premises Exchange Server and SharePoint Server," says Lisota.
The company makes comprehensive use of Exchange Online, including its shared calendars, support for multiple email boxes, and mobile messaging. "Our agents need to be able to send and receive email on all sorts of devices from anywhere they happen to be," says Lisota. "The sync capabilities of Exchange Online mean that I can easily enable my employees to get email on all of their phones and computers from any web browser."
Findwell uses SharePoint Online to manage documents such as home-listing checklists, flyer templates, and its employee manual. Employees also submit their expense reports through SharePoint Online and use the service's dashboard functionality to monitor the company's sales progress.
The company has started using Microsoft Lync Online for web conferencing, which is a new capability for agents. "We currently handle business in person, through email, or over the phone," says Lisota. "By using Lync Online, we have a more time-effective way to share complex information such as contracts, market valuations, and home details with our clients. Now we can replace a lengthy email exchange or a long drive with a quick online meeting."
The company expects the following benefits from using Office 365:
Improved responsiveness to clients. Using Office 365 fosters the company's goal of constant availability to clients. "Clients expect us to be reachable and have the answers that they need at all times. Office 365 supports that effort, whether our agents are in the office, at a home, or in a coffee shop," says Lisota. "Thanks to Office 365, our agents can access the information that they need with the tools that they are already familiar with. That is a great advantage."
Greater business agility. The company can scale its technology to fully support business growth without adding IT headaches or infrastructure hardware. "As I add more real estate agents, I don't have to figure out if our server can handle the growth or worry about hardware upgrade cycles. Office 365 can easily grow along with us."
For more information about other Microsoft customer successes, please visit:
Seattle, Washington–based findwell is a real estate startup that combines technology and a progressive approach to deliver full-service real estate brokerage services at lower prices than traditional real estate agencies.


text:
* Dry and chapped skin
* As a shaving lotion
* Diabetes skin care
* Hand and Foot Syndrome- a side effect of chemotherapy drugs
* Chamois cream for bicyclists
* Needlework and quilting
Some people may be put off by the fact that this line of products was originally made to be used on cows in dry, harsh conditions. There's no need to let that deter you. I received an assortment of products from Udderly Smooth to try and it's done well with moisturizing my skin and keeping it from being dry. You can also be assured that the company does not engage in animal testing.
Udderly Smooth Foot Cream was the winner of Woman's Day Magazine's Best in Beauty for 2005. I've been using it regularly on my feet to keep them smooth.
I got a kick out of the directions for use on the Udderly Smooth Udder Cream, which include washing the teat parts and udder thoroughly. Regardless, it can be used on your skin as well for dry, chapped areas. It feels almost like silk when applied. There is no greasiness or a feeling of heaviness.
I read on the site that Udderly Smooth can also be used on the face as a general moisturizer, foundation primer, or makeup remover. I've used it on my face a few times to moisturize it and have noticed my skin looks more refreshed. The Udder Cream does not seem to have any particular smell or fragrance to it.
The Hand & Body Lotion comes in a large bottle and will last for quite some time. Only a small amount is needed to get your hands and body feeling rejuvenated. Just as the Udder Cream does not feel gunky or heavy on the skin, the Hand & Body Lotion doesn't either. Aloe Vera Gel and Vitamin E are some of the helpful ingredients included in this lotion.
Win It!One person will win an assortment of Udderly Smooth products similiar to what I received (Udderly Smooth Udder Cream, Foot Cream, and Hand & Body Lotion).
Leave a comment with something you learned about the Udderly Smooth company OR one of the products you'd most like to try.
Follow me on Twitter, partymix25.
Tweet about this giveaway, leave a link to the tweet (can be done once daily).
Follow my blog.
Subscribe to my blog by email.
Add my button to your blog.
Blog about this giveaway, leave a link to the post (+3 entries).
Leave a separate comment for each entry and include your email address in the comments. Giveaway is open to residents of the USA. Giveaway ends 3/31/10 at 8 pm CST. Winner will be randomly drawn and will have 48 hrs. to respond to email notification or a new winner will be drawn.


text:
Compare Products: Check up to four products with to see a side-by-side comparison
Your search did not find any results. Try entering a different search term, removing some search filters or click here to view this page with no search filters.
WEBstaurantStore.com provides you with clear pebbled plastic tumblers in a wide variety of sizes so that you're sure to find just what you need for your pizzeria, diner, sandwich shop and more!
Other Standard Plastic Tumblers


text:
Get job alerts for: CSR jobs in Indonesia
You can cancel email alerts at any time.
Sending you activation email...
Get notified when there are new jobs for this search.
You can cancel alerts at any time.
Please check your email
Click the verification link in the email to start receiving your job alerts.
Your job alert is active


text:
This was one of those rare and lovely weekends when we didn't have a national holiday, a birthday, sporting events, sinus surgery, extended family event, house guests, yard work, or any other major commitment. Can I tell you how much I enjoyed it? I should have been cleaning out and organizing my basement, but the fabric scraps that exploded all over my sewing table kept calling my name. (To my credit I did spend 45 minutes dismantling and unclogging the large blockage in my vacuum cleaner, so I should get points for that at least. I'll spare you the pictures of that 'creative' endeavor.)
I was having a hard time deciding what colors and fabrics to use for this quilt. I swore up and down, no new fabric - it ALL had to come from the stash. Then I went to JoAnn to buy a new rotary cutter during a 50% off sale and happened to walk past the Denyse Schmidt fabric (which also happened to be on sale). I didn't realize she had a new collection, Daisy Mae. Some really COOL prints and colors - that's where the greens and the red at the top came from. Seeing those colors totally inspired me for this quilt. The rest are from the stash. Sadly, (or maybe fortunately for me), the fabric quality is not nearly as good on this collection (and yet the price is the same). As a result, I did not buy very much. Unfortunate, since there are some really cool prints.
So anyway, thank you 'boring' Saturday afternoon for your generous donation of productive time. I hope you had some weekend time to sew, or play 'orphans', or clean out your vacuum cleaner too. This is when I like January.


text:
Now showing items 11-14 of 14
|settlement informality, change, land, informal economy. [1]
|Slum upgradinf, slum eradication, South Africa Housing, MDG targets. [1]
|Tenure in slums; enumeration; grassroots tool; Kisumu [1]
|Urban freedoms, right to the city, equal right to the city, equal society, ongoing transformation [1]
Now showing items 11-14 of 14


text:
New Arrivals
mouse over photo to zoom click for larger image
Embraceable Short Sleeve Sleepshirt Ruby
Online Only! Also available in XXL!
Sleep softly in the unrestrictive comfort of a sleepshirt and Cool Nights knit. Satiny piping and a pocket sweeten this V-neck ruby sleepshirt.
- Reinforced neck seam.
- Short sleeves.
- Non-cling knit retains shape and silky drape, even after countless washings.
- Approximately 37.5" from shoulder.
- 93% Rayon, 7% Spandex. Machine wash. Imported.
- Embraceable pajamas are the softest, most luxurious in the world.
- Our exclusive Cool Nights knit stays cool and dry.
We're so sorry: this item sold out sooner than expected. For an equally comfortable substitute, please call our Solution Experts at 1.866.768.7662. Or click on Soma Chat below for immediate assistance.


text:
Gene hackman
Photo Gallery
Gene hackman
Gene Hackman portrays a small-town basketball coach in this inspiring film from 1986. HOOSIERS received two Oscar nominations at the 59th Academy Awards including Best Original Score.
Use a Facebook account to add a comment, subject to Facebook's Terms of Service and Privacy Policy. Your Facebook name, photo & other personal information you make public on Facebook will appear with your comment, and may be used on Oscar's media platforms. Learn more.


text:
Dust-Free Erasers from Faber-Castell are ideal for making corrections to graphite drawings, delivering clean erasure without smudging. These erasers are latex-free.
Ask a question about Dust-Free Erasers Ask a question about this product
Be the first to write a review on this product!
Please wait...
You May Also Like...
How to get VIP Club Prices
Anyone can be a VIP Member with:
Only $25/year
Ask a Question About Dust-Free Erasers
Your email will not be shared. We will only use your email address to respond to your question. When asking your question, please be as descriptive as possible, it will allow us to give you the most accurate answer possible.
Please wait...
Please wait...


text:
Women's Fitness Collection
We're obsessed with autumn's alluring hues. Think deep jewel tones, vivid prints and curve-hugging silhouettes. These bottoms go where you do—from a morning run to Bikram and beyond.
Find the perfect pair of black pants to fit and flatter. Ready for whatever the day brings your way.
Clothing should go where your busy life leads you. These versatile pieces transition from your workout to the rest of your day—no wardrobe change needed.
Find the look that fits you.These outfits are perfect for your workout or a lunch date with the girls.
This season is all about lightweight layers, soft fabrics and all-day comfort. Pair unexpected hues and textures for a look that's totally you.


text:
Oven Seared Amish Raised Chicken 'Chop' with Morel Sauce
|Executive Chef Nick Seccia, The Herny Ford
|URL - Link:
Chef Nick Seccia, executive chef for The Henry Ford in Dearborn, shares one of his signature creations: A flavor-infused chicken breast modeled after a pork chop!
|Number of Servings:
|Chicken Chop
6 airline-cut Amish raised chicken breast (6-8 oz. each)
6 slices thick cut hickory smoked bacon
1/4 Cup pure olive oil
2 Cloves garlic peeled
2 Tbsp. fresh parsley
2 Tbsp. fresh thyme
2 Tbsp. fresh basil leaves
2 Tbsp. Dijon mustard
1 Tbsp. organic apple cider vinegar
1/2 Tbsp. Kosher salt
1/2 Tbsp. ground black pepper
Morel Sauce
1 cup fresh Morel mushrooms sliced in half lengthwise and cleaned
1 large shallot minced
1 Tbsp. unsalted butter
2 Tbsp. brandy
1 cup roasted veal stock reduced from 2 cups
1/4 cup heavy cream
Kosher salt and ground black pepper as needed
|Chicken Chop
1. Combine all ingredients except chicken and bacon, puree in a blender.
2. Remove the meat and skin from around the bone on the chicken.
3. Pour marinade over the chicken and marinate overnight.
4. Place chicken skin side down flat with the bone pointing away from you then roll the thin edge towards the chicken until rolled into a chop shape.
5. Stand chicken up so the bone is straight up then wrap the bacon around the bottom.
6. Roast at 350 degrees F for about 35 to 40 minutes or until the chicken is cooked through. 7. Serve with morel sauce.
Morel Sauce
1. Saute the mushrooms and shallots in butter until the shallots are clear and the mushrooms are tender.
2. Add the brandy and reduce until almost dry.
3. Add the stock and heavy cream reduce until thickened.
4. Season with salt and pepper.


text:
Follow us:
Click below to filter your search results
Number 533
(Reaffirmed 2014)
ABSTRACT: Prenatal lead exposure has known adverse effects on maternal health and infant outcomes across a wide range of maternal blood lead levels. Adverse effects of lead exposure are being identified at lower levels of exposure than previously recognized in both children and adults. In 2010, th...
August 2012
Number 511
(Reaffirmed 2013)
ABSTRACT: Clinicians who provide care for incarcerated women should be aware of the special health care needs of pregnant incarcerated women and the specific issues related to the use of restraints during pregnancy and the postpartum period. The use of restraints on pregnant incarcerated women and...
November 2011
Number 449
(Replaces No. 230, January 2000)
ABSTRACT: Phenylketonuria (PKU) is an autosomal recessive disorder of phenylalanine (Phe) metabolism characterized by a deficiency of the hepatic enzyme, phenylalanine hydroxylase, an enzyme responsible for the conversion of phenylalanine to tyrosine, and elevated levels of Phe and Phe metabolite....
December 2009
American Congress of Obstetricians and Gynecologists
409 12th Street SW, Washington, DC 20024-2188 | Mailing Address: PO Box 70620, Washington, DC 20024-9998
Copyright Terms of Use


text:
Every March, our acclaimed Film Program draws thousands of fans, filmmakers, press and industry leaders to Austin, TX to immerse in some of the most innovative, smart and entertaining new films around.
Browse through the categories below; click on a category heading to see examples of each category from our 2014 program.
- Submit Your Film
- SXSW® Film Festival FAQ
- Browse 2014 Film Lineup
- Flip through the 2014 Film Program Guide
- Read the Film Schedule Grid Online
- Watch Video Content
- SXSW Film Award Categories
Narrative Feature Competition
Eight world premieres, eight unique ways to celebrate the art of storytelling. Selected from 1,324 films submitted to SXSW Film 2014.
Documentary Feature Competition
Selected from over 892 submissions, the eight world premieres in the 2014 Documentary Feature category brought real-world stories to life, demonstrating innovation, energy and bold voices.
Big names, big talent: Headliners bring star power to SXSW, featuring red carpet premieres & gala film events with major & rising names in cinema.
Narrative Spotlight
High profile narrative features receiving their World, North American or U.S. Premieres at SXSW.
Documentary Spotlight
Shining a light on new documentary features receiving their World, North American or U.S. Premieres at SXSW.
Visions (formerly "Emerging Visions") filmmakers are audacious, risk-taking artists in the new cinema landscape who demonstrate raw innovation and creativity in documentary and narrative filmmaking.
Scary, funny, sexy, controversial – provocative after-dark features for night-owls and the terminally curious.
Featuring innovative new work aimed squarely at the small screen, Episodic tunes in to the explosion of exciting material on non-theatrical platforms, including serialized TV, webisodes and beyond.
24 Beats Per Second
Showcasing the sounds, culture & influence of music & musicians, with an emphasis on the documentary.
A diverse selection of International filmmaking talent, featuring innovative narratives, artful documentaries, premieres, festival favorites and more.
Festival Favorites
Acclaimed standouts & selected previous premieres from festivals around the world.
Special Events
Live Soundtracks, cult re-issues & much more. Our Special Events section offers unusual, unexpected & unique one-off film events.
Narrative Shorts
A selection of original, well-crafted films that take advantage of the short form and exemplify distinctive and genuine storytelling.
Documentary Shorts
Slices of life from across the documentary spectrum.
Animated Shorts
An assortment of stories told using traditional animation, computer-generated effects, stop-motion, and everything in-between.
Midnight Shorts
Bite-sized bits for all of your sex, gore, and hilarity cravings.
Music Videos
A range of classic, innovative, and stylish work showcasing the scope of music video culture.
Texas Shorts
An offshoot of our regular narrative shorts program, composed of work shot in, about, or somehow relating to the Lone Star state.
Texas High School Shorts
A preview of the next filmmaking generation, as Texas High Schoolers present shorts of 5 minutes or less.
Photo by John Shapley/Getty Images


text:
Tuesday, May 18, 2010
Question: Internet Discussion vs. Actual Play
8 comments:
- Rob Conley said...
I think some RPGS have more interesting premises than other. Ones that lead to extensive discussions. This does not correlate to playability or how often a RPG is played although if the RPG has a good rule system it can help.
For me Traveller is one RPG that I talk about more than playing. The Third Imperium setting is endlessly fascinating from my POV and I can talk about it all day.
- May 18, 2010 at 8:22 AM
- Jeff Rients said...
I think there's a huge net skew towards the latest games. Over the 19 years I've been involved in the local scene I look at actual campaigns run and see a much more even mix of stuff that's hot on the net and stuff nobody talks about much. There's a popular d20 Modern game right now. Before that it was Mekton Zeta.
- May 18, 2010 at 8:31 AM
- Rognar said...
I get the sense that D&D 3.5/Pathfinder is underrepresented in terms of online discussion. Beyond Paizo's own site and a little corner of ENWorld, there seems to be few sites dedicated to these games. Contrast that with the tsunami of "old-school" D&D blogs. To a casual observer, you would assume many more people play Labyrinth Lord than Pathfinder.
- May 18, 2010 at 10:59 AM
+1 Rognar
I agree that 3x/PFRPG seems to be underrepresented in internet discussion. But this may be simply b/c the Paizo forums are so lively or it could be a matter of game complexity...I dont know but I would LOVE to see some PATHFINDER blogs but they seem to be about as rare as 2e retro clones lol. -Azhriaz
- May 18, 2010 at 11:40 AM
- James V said...
I agree that 3x/PFRPG seems to be underrepresented in internet discussion. But this may be simply b/c the Paizo forums are so lively
I think you got it in one. Pathfinder seem underrepresented because there's one clear place online where their community can get together. A well supported and lively house forum should make personal blogs unnecessary. At least I could see a publisher taking that POV.
- May 18, 2010 at 11:56 AM
- Rognar said...
The problem with Paizo's site is that it's too lively. If you post a new thread, you better hope it attracts some interest in the first hour or it will be buried.
- May 18, 2010 at 12:30 PM
- Gleichman said...
I always see a huge diconnect because I've never played the 'in' game since the late 70s. So from my PoV the Internet is always off base.
This is true even when I went to sites dedicated to HERO System which has been a consistent choice for me. They may be talking about about the same books, but the usage was so different that they may as well have been a D&D site.
The people who go online and actually post are a narrow selection, and frankly I doubt they are in position to comment upon the hobby's larger trends outside their own groups.
- May 18, 2010 at 1:23 PM
- 1d30 said...
There's a place for blogs even if there are excellent fora.
An internet forum is a place where the person who screams the loudest without getting banned gets to shape the discussion. People come, don't read the conversation, and put their own views at the (current) end. A solid majority of posters don't return to the thread, or only read a couple posts after theirs, and so they don't learn anything. Nobody's opinion changes.
A blog is one person telling it how they see it. If you don't like it, you probably won't continue reading the blog. So the blog tends to attract likeminded people, who want to come and learn what the blogger offers. They take what they want and leave the rest. Sometimes readers' comments refine or inspire the blogger or other readers.
Ideally, the forum creates an environment where ideas are tumbled around until a few good arguments arise, which people can look at to form their opinions and spur them on to further investigation. In reality they often become cesspits spawning viral garbage.
Ideall, the blog is like a personal publication, somewhere between a diary, local newspaper, or professional journal. In reality they're often insular and are alternately slow to adapt and yet mated to the whims of the author.
But regardless, they each do something different. Just because there's an enormous forum doesn't mean there's no reason to have blogs (or vice versa).
- May 18, 2010 at 1:38 PM


text:
Monday, December 22, 2014
Follow us:
Western NY
Time Warner Cable video customers:Sign in with your TWC ID to access our video clips.
Sign in
To view our videos, you need to
install Adobe Flash 9 or above. Install now.
Then come back here and refresh the page.
Thousands from across the country are gathering at Webster Schroeder High School to say goodbye and pay their respects to Chiapperini, a lieutenant with and public information officer for the Webster police department. Hundreds of firefighters attending the funeral are being bused from Webster Thomas High School to Webster Schroeder High School, where the service will take place.
After the funeral, a smaller procession will proceed from Schroeder High school to West Webster Cemetery. That will include the procession driving past the intersection shown, and then past the West Webster Fire Station on Gravel Road, before ending at West Webster Cemetery at the intersection of Maple and Ridge roads.
YNN will have continuing coverage of the funeral for Webster Firefighter and past chief Mike Chiapperini.
Those services will be live at Noon.
Reproduction in whole or in part without permission is prohibited.
© 1999-2014 Time Warner Cable Enterprises LLC. All Rights Reserved.
Web design and web development by Tipit.


text:
13 Ways To Smell Amazing All The Time!
One whiff of you and your crush will be dying to get a little closer. Just follow these simple tips.
By Cosmopolitan
Don't Rub Your Fragrances Once You've Sprayed It On
"Spray it on your wrists the back of your neck, or mist it into the air and walk through it," says Mark Knitowski, vice president of product innovation and fragrance for Victoria's Secret. "But whatever you do, don't rub it in because this will make the top note disappear quickly, leaving you with only the middle and base notes, rather than the full fragrance."