text:
<ac:macro ac:name="note"><ac:parameter ac:name="title">Superceded</ac:parameter><ac:rich-text-body>

This page has been superceded by <ac:link><ri:page ri:content-title="Zend Framework 2.0 Requirements" /></ac:link>; please direct further discussion to that page.
</ac:rich-text-body></ac:macro>
<ac:macro ac:name="note"><ac:parameter ac:name="title">Participate in the Discussion</ac:parameter><ac:rich-text-body>

Please participate in the discussion! You can either do so in comments to these pages, or by subscribing to the firstname.lastname@example.com – simply send an email to email@example.com!
</ac:rich-text-body></ac:macro>

Zend Framework 2.0 will be the first major version following the 1.x series, and as such is the first time BC breaks will be allowed. Our goal is to make breaks only where they make sense: there will be no renaming of components just for naming consistency, but we will improve the code base to make it more maintainable, easier to extend, or make use of new language features that better accomodate the design,

At this time, we aim to have ZF 2.0 have a minimum requirement of PHP 5.3 (which version of 5.3 is still to be determined). This allows us to make use of a number of new language features that better suit framework development, such as namespaces, __invoke(), closures, goto, Late Static Binding (LSB), etc.

This page serves to summarize various changes we will be making for 2.0, both as new features as well as improvements. Additionally, it links to several pages covering specific components.

Architectural/Design Changes

Our goal with ZF 2.0 is to improve the overall consistency of the project. With consistent APIs relating to constructors, options, and exceptions, developers can more readily grasp the basics of each component and move on to specifics of usage.

Unified constructor. All constructors will (optionally) accept an array of options or Zend_Config object as the first argument. This allows for more flexibility to add new arguments to the constructor, have variable numbers of arguments, and allow "named" arguments. Additionally, it's a good technique for allowing Dependency Injection.

As part of this initiative, most components will also have a "setOptions()" method to which the options array will be passed (and which may be used later to reset object state). Typically, this will proxy to other setters.

Many components in ZF 1.X already do this: Zend_Application, Zend_Form, Zend_Validate, Zend_Layout, etc. We are simply extending this paradigm to cover all components.

In order to reduce code duplication, we will likely introduce a zend\Options class, which will work roughly as follows:
<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
namespace zend;
class Options
public static function setOptions($object, array $options)
if (!is_object($object))
foreach ($options as $key => $value) {
$method = 'set' . self::_normalizeKey($key);
if (method_exists($object, $method))
public static function setConstructorOptions($object, $options)
if ($options instanceof Zend_Config)
if (is_array($options))
protected static function _normalizeKey($key)
use zend\Options as Options;
class Foo
public $bar = '';
public $baz = '';
public function __construct($options = null)
public function setOptions(array $options)
public function setBar($value)
public function setBaz($value)
$foo = new Foo(array('bar' => 'baz'));
echo $foo->bar; // "baz"
$foo->setOptions(array('bar' => 'boo', 'baz' => 'bat'));
echo $foo->bar . $foo->baz; // "boobat"

Options. In ZF 1.X, the various components which accept options accept a variety of formats: some expect underscore_separated keys, others expect camelCasedKeys, others expect UPPERCASEDKEYS, and some expect lowercasedkeys. This leads to confusion for many, and also leads to difficulties debugging. Our goal in ZF 2.0 is to standardize option keys to correct this situation.

Currently, we are leaning towards all_lowercase_underscore_keys. These are human-readable, contain only valid PHP variable characters, and make for a simplified option parsing implementation. Additionally, it is trivial to translate such keys to camelCase ("str_replace(' ', '', ucwords(str_replace('_', ' ', $value)))") for purposes of overloading – and this makes it easy to document option key => class property affiliations.

Exceptions. Each component will have an Exception marker interface, with exceptions defined for discrete exception types thrown by the component. The concrete exceptions will either extend the global Exception class or an SPL Exception, and also implement the component Exception interface. This allows us to throw appropriate SPL exceptions while retaining a common Exception type (via the marker interfaces). As an example:
<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
namespace \Foo\Bar;
interface Exception
class InvalidArgumentException
extends \InvalidArgumentException
implements Exception
try {
throw new InvalidArgumentException();
} catch (\Foo\Bar\Exception $e) {

Design By Contract. We will be altering portions of the framework to follow the concept of design by contract, and new development will follow this paradigm. At first, this will take the form of refactoring to add interfaces/refactoring interfaces to reflect actual usage.

Interfaces make creating alternate implementations of standard classes easier, while assuring that these implementations will continue to work with the classes that consume them. In many cases currently, we offer only abstract classes, and no equivalent interfaces; in other cases, the consuming classes use methods that are not part of the interface.

In addition to this initiative, we will be eliminating some functionality intended to add flexibility to some of the standard classes. We have found that oftentimes this functionality leads to performance overhead as well as consumes maintenance time that could be used better elsewhere in the framework. As an example, the Dispatcher has a number of methods for adding custom class -> file mappings that are largely unused and which use an unnecessary number of CPU cycles; refactoring this to follow only the standard use cases would ease maintenance, while having a good, simple interface would make creating alternate implementations for custom use cases easier.

Elimination of most singletons. ZF has often been accused of "singletonitis." While we're not sure if we completely agree, we will note that in most cases, the singletons we have presented a number of problems and led to difficult test cases. Additionally, in most cases, the singleton is unwarranted. We will be refactoring to eliminate these, including in Zend_Controller_Front. In exceptional cases, we will keep them; these include global operations such as autoloading and database connections.

Creation of components for general-purpose, cross-functional actions. A number of components duplicate code, and we want to push the duplication areas into discrete components that the original components may then consume. Some of these include:

Plugins/Helpers/Strategies (seen currently in Zend_Controller_Front, Zend_Controller_Action_Helper, Zend_View (helpers and filters), Zend_Form (validators, filters, and decorators), etc.). Plugin discovery and loading could benefit from a common API.

Decorators (seen currently in Zend_Form; other areas could benefit from the pattern)

Factories (seen currently in Zend_Db, Zend_Navigation_Page, Zend_Auth, Zend_Translate, Zend_Cache, etc.)

Caching (seen currently in Zend_Translate, Zend_Locale, Zend_Queue, Zend_Paginator, Zend_Feed_Reader, Zend_Db_Table, etc.)

Usage of new language features within plugin architectures. Currently, most plugins rely on the strategy pattern, but the mechanism differs between plugins. PHP 5.3 offers some compelling alternatives that we want to explore: __invoke() and closures. Closures are less compelling as we cannot do simple type-hinting on them. __invoke() offers perhaps the simplest solution, and could become a standard API for plugins.

Autoload-only. We will move to using autoloading throughout the framework. This solves a number of performance issues, as well as simplifies coding dependencies (particularly exceptions).

Namespaces. PHP namespaces benefit frameworks and libraries more than any other code bases, and ZF can benefit from it greatly, particularly with components such as Zend_Search_Lucene and Zend_Controller. However, adopting namespaces does not come without a cost: all code will need to be rewritten to define and use namespaces. This will be the single biggest BC break we introduce.

We also plan to introduce a separate namespace for unit testing, and are currently looking at either \test\zend, \zend\test, or \zendtest. This, along with per-component namespaces, will help prevent naming collisions within the test suite.

goto. Goto is often considered "evil," but is invaluable when creating Finite State Machines (FSM) and parsers; usage of goto will be evaluated on a case-by-case basis. Some examples of components that could potentially benefit from such an implementation include Zend_Search_Lucene (which already implements a FSM), the MVC (more below), Zend_Ical, and Zend_Markup (though not all of these may make use of it).

<ac:link><ri:page ri:content-title="Plugin Architectures" /><ac:link-body>Specifics on Plugin architecture changes</ac:link-body></ac:link>

MVC Implementation

Our current MVC implementation is increasingly adding overhead to the dispatch cycle, slowing down the request cycle. While you can squeeze additional performance out of it via stripping require_once calls and using autoloading, the fastest requests are still far short of other, slimmer frameworks (CodeIgniter and the various new microframeworks come to mind here).

We are considering several potential approaches to rectify this situation. As mentioned in the previous section, we will be refactoring a number of components to provide strict interfaces. This, along with good documentation of these interfaces, will allow for easier extension and customization of ZF components. This frees us to provide a more conventions-based approach with ZF's MVC layer. The benefit to this is that it makes it possible to streamline the MVC code to just what's necessary for the 80/20 case it was designed for – while still providing flex points (via the interfaces) for customization.

Second, one approach other frameworks (both PHP and otherwise) are using is to provide explicit mapping of URL routes to controllers (a prime example is Horde_Routes, which is in turn based on the Python Routes project, which was in turn inspired by Ruby on Rails). This approach is potentially slightly less RAD friendly (after developing your controllers, you then need to add them to the map), but has the benefit of simplifying the dispatcher (the controller and action are known and do not need to be discovered) while still offering lazy loading. We will be looking into this to either offer as an alternate implementation or as part of the core offering.

Finally, one possibility offered by PHP 5.3 is the idea of having the front controller be a state machine, due to the addition of goto to the language. This would make it possible to define specific application states and easily jump to them, solving several issues that currently occur due to operating within a loop. It's also a common paradigm particularly with event-driven architectures, and should be somewhat familiar to JS and/or GTK developers.

For more information on proposed MVC refactoring, please visit the following pages:

Zend_Controller 2.0

Zend_Controller_Router 2.0

Zend_View 2.0

Zend_Session 2.0

<ac:link><ri:page ri:content-title="Zend_Form 2.0" /></ac:link>

Other components

Zend_Soap 2.0

Zend_Mail 2.0

Nov 11, 2009

there will be no renaming of components just for naming consistency

Why not? All code (both within ZF as well as apps depending on it) will have to be reviewed anyhow since class names will be changed to allow for namespaces.

Nov 11, 2009

Renaming the components will make migrations harder for developers. If most migration can be done simply by substituting '_' with '\', it's a much easier story.

Nov 11, 2009

Ok, but why not get rid of any naming inconsistency now with 2.0. It is not such a big deal to do the renaming from Zend_Foo_Bar_Whatever to Zend\Bar\Foo\Whatever. Every IDE nowadays can do this without much effort. These changes only need to be documented in a migration guide.

update: added an "in" before consistency

Nov 12, 2009

+1 for fixing all naming issues now. Also:

Our goal with ZF 2.0 is to improve the overall consistency of the project. With consistent APIs relating to constructors, options, and exceptions, developers can more readily grasp the basics of each component and move on to specifics of usage.

If you accept that naming is a critical part of the design of the code, then it would seem to be in our best interest to seize this opportunity to fix as much as possible in pursuit of this goal. The longer bad names stay around, the higher their cost to fix will become. IIRC, I believe that Kent Beck said in the Refactoring book that you should make a point to fix bad names before other issues. Good names may be the single biggest factor affecting the understandability of the code.

Nov 11, 2009

+1 for removing any naming inconsistency. I do not think the migration path will be much harder, and the added consistency would be worth it in the long run.

( Ralf I assume you wanted an "in" before that "consistency" in the previous comment. funny... )

Nov 11, 2009

Yes Jacob you are right. It must have been too late last night after a hard days work. Sorry for the confusion.

Nov 12, 2009
<ac:macro ac:name="note"><ac:parameter ac:name="title">Allowing Class/Component renaming</ac:parameter><ac:rich-text-body>

Based on the comments and other discussions, I've stricken the sentence indicating we will not rename components for naming consistency. This can be addressed with migration scripts, and we will make this an additional task for the 2.0 roadmap.
</ac:rich-text-body></ac:macro>
Nov 12, 2009

The meaning is... change to names allowed? Two migrations of class names are too much imho, and addressing consistency now is a better choice than having to deal with it later.

Why underscore_lowercase_keys? Is it not simpler to use camelCaseKeys since the translation to setters involve only a ucfirst()/lcfirst()?

Nov 12, 2009

We'll review changes on a case-by-case basis (instead of having a blanket ban).

As for underscore_lowercase_keys, the issues are thus:

Case sensitivity issues with options are very hard to track down

Case sensitivity issues have led to a variety of maintenance problems in existing components, including issues determining how to resolve plugin names to class names (FrontController vs. Frontcontroller, etc.)

It's relatively simple to transform underscore_lowercase_keys to underscoreLowercaseKeys using PHP's string functions, which in turn makes it:

undetrivial to cache object method names and do case sensitive comparisons later

They're more readable in configuration files

Overall, the use cases become simpler and easier to support in a uniform manner. If applied throughout the framework, this becomes a simple rule for developers to learn.

Nov 13, 2009

Imho case sensitivity it's the way computer works. but it is a personal opinion. What am I worried about is the consistency of the keys with camelCase method and class names (someone confused about when he has to use lowercase_underscore and camelCase).

Nov 13, 2009

It'd be really, really simple: option keys and configuration keys are always underscore_separated. Properties and methods are always camelCased. 1:1 matching between them.

Case sensitivity may be how a computer works, but it's a bitch to debug; I can't tell you how many times I've seen posts on the mailing lists or issue tracker where the problem ended up being option case – nor how many back and forth messages/comments it takes to determine this. It's relatively easy to determine when the key in question refers to a class name, but other options are less obvious.

Nov 11, 2009

How about focusing on the extendability of classes? I can't tell you how many times I've run into a situation where I need to modify the behavior of a method, and I've run into either private variables (without getters/setters) or final classes in the ZF. There are definitely cases for their use, but I feel that there are a lot of private variables that could be protected. Also some classes are declared final, but shouldn't be. I can't remember any specific examples off hand, but I think the REST server/client has a couple.

Nov 12, 2009

Simply making classes non-final or turning private to protected does not make something extensible. Without any further thought this makes them only "hackable". There is a very good rule of thumb for inheritance: Design and document for inheritance or else prohibit it. Designing a class for inheritance means that the extension points are well-defined, the consequences of extending a class are documented, etc. That makes the class "robust".

By just making classes non-final and members protected instead of private you indirectly increased your maintenance burden and the chance for breaking backwards compatibility. Every single protected member might now be used by some application that relies on it, even renaming breaks BC. Every single protected method might now be overriden or used in a subclass, causing strange side-effects that were never anticipated.

The worst example I read somewhere, I think it was on a cakephp wiki page, is that "all members should be protected, this is a framework and thus should be extensible". This is just not extensibility or at least a very unstable and unreliable extensibility.

Maybe you're frustrated because you were run into such situations where you needed to modify the behavior of a class in a way that was not intended. Probably you would've been happier at that point when it would've been possible to just extend that class or override that particular method. But you would be frustrated later when your code broke all of a sudden because the code you relied upon was refactored. If you demand everything to be protected/non-final you put a huge burden on the framework developers to maintain backwards compatibility.

Its no secret that inheritance breaks encapsulation to a certain degree anyway.

Nov 12, 2009

You make some excellent points Roman, I agree that in general one should use stricter OO concepts (final and private) to enforce particular use cases in ones own code. But that is a tougher dance to dance when you are a general purpose framework.

Generally, framework component developers cannot identify all use cases when authoring a new component. Like all great technologies, the really interesting use cases don't really become apparent until after people have had a chance to play with the code. That said, when we decide to restrict usage of final and private, and static state for that matter, it's because we feel there is both a public API as well as an extension point API that should be available to consumers. This allows us to not lock in (via BC) to a particularly inflexible and restrictive API, and also allows consumers to extend in ways that otherwise would have presented pain points. This also allows us to grow the original use case, and further unit test them as new use cases and possible extensions become available.

Most major changes that go into ZF components get reviewed for both of these potential BC breaks: on the public known API as well as the protected extension API. And we do our best to ensure as much BC as possible on the extension API.

Then there are also some advantages when unit testing, but that's a whole other topic <ac:emoticon ac:name="wink" />

Nov 12, 2009

I'm not sure where you're looking, but there are exactly four classes marked final withing ZF – 2 in the InfoCard component, one in AMF, and Zend_Version. I hardly think this will be an issue – but we will review those cases. (In your specific example of the REST server, it will be going away in 2.0, and we recommend using the new Zend_Rest_Route to build your RESTful applications via the MVC.)

Regarding private variable usage, we actually recommend protected visibility except in those cases where overriding could cause the implementation to break. There may be a few places we need to review the visibility, but I do not expect too many changes in this regard. As Roman notes, visibility is not the key to extensibility; class and component design is. The flex points should be well-defined and documented.

Nov 12, 2009

I was wrong earlier about making classes final, I forgot my use case... It was actually making methods final.

So here is a situation I ran in to... There is a REST API I wanted to consume, I knew the results of the REST calls I was making wouldn't change very often (maybe once a day), so I naturally wanted to cache the results. The static method getHttpClient in Zend_Service_Abstract is final, there is no way to use a custom HttpClient... Also, the HttpClient as it exists right now, doesn't support caching (and for good reason, this use case is very obscure). However, I couldn't find a good solution to implementing caching in my scenario, without wrapping the entire process in a caching statement... (I'd rather cache the calls, not the final Zend_Rest response).

I am by no means arguing for globally removing private or final without consideration... just to review the places it has been used in the past and consider whether or not it is necessary.

Maybe (possibly silly again), but having a place where all major Zend components where caching makes sense... Again this is just one tiny problem, but a great chance to review old code.

Nov 13, 2009

I'm still looking over the Controller 2.0 and Controller_Router 2.0 docs, but I didn't see any mention of Zend_Rest_Route in the classes section of the Router 2.0 wiki page? It will need to be updated along with the other routes, right?

Nov 18, 2009

That's correct. The Zend\Rest\Route will have to be updated according to the new interface.

Nov 12, 2009

This all looks great, I like the idea of design by contract, lack of clear api's in some of the classes have been frustrating at times.

Your FSM MVC example is also very interesting I look forward to watching this grow <ac:emoticon ac:name="smile" />

Nov 12, 2009

I've read through all the docs on the wiki, and followed the discussion in the mailing list. First of all, let me say that this looks really good. I like the direction ZF is headed, and it certainly seems that we have enough enthusiastic contributors behind the wheel to make the framework go in a direction we're all happy with in the end. This needed to be said, because my notes below might come across as more harsh than they actually are.

Unified constructors. This is simply a bad idea. be assumed that all classes are "configurable" objects (I mean who are we, jQuery?). Granted, some of the classes in the framework (I've even written such a component myself :S) benefit from taking $options as a single constructor param, but most don't. Sure, an array is an efficient data structure in PHP, but we lose all the good stuff, namely a self-documenting syntax which is easy to learn, because it is typed and can be automatically parsed by IDEs. Not only IDEs, actually. My favorite way of learning a class is by looking at the constructor, either by opening the file directly, or looking at auto-completion suggestions in the IDE. I expect to find a clear overview of the required params for constructing the class in a valid state. This won't be the case with an $options array, which has to be manually written in a docblock. Sure, IDEs could parse this information, but we all know that won't be a viable feature for several years, and only in a few selected IDEs (probably as an extended "ZF" feature for Zend Studio which won't be contributed back to the original PDT project, and then we have it going with slow bureaucracy at least until PHP 6.0 is released and the whole PDT project will have to be rewritten once again).

But it goes beyond syntax and "pedagogical" reasons. I'd take it as far as to say that if this is a feature we need because constructor params change too frequently, something is completely funked further down the line. A constructor shouldn't need to take a whole load of params to construct the object in a valid state, it should be simple. Perhaps the class has too much responsibility, and should be refactored separate its behaviour into more logical groupings. Of course this can't always be done, but I'd still argue that in most cases a constructor shouldn't take more than 3 params. This may sound blatantly provocative, so take it with a pinch of salt, but think about it; wouldn't it be nice? Supear-easy to get an overview and learn the API.

For classes that absolutely have to take a single $options param, there is still a way to do it which is more easily parsed by both humans and IDEs. Make an FooOptions class which is consumed by the Foo constructor. This is something that is done in several other languages, and from my experience it works well when the constructor needs a bunch of options. Example, let's say we have an an Application class that takes 10 param. Instead of putting those params in a naive array, make an ApplicationOptions class with 10 properties (and/or getters/setters), which allows us to do public function _construct(ApplicationOptions $options). This allows for auto-completion in IDEs, it's easy to understand, OOP-wise it's easy to extend, and way easier to maintain in the long run than an array. And of course, all such classes (and indeed all constructors) should follow the principle of _convention over configuration, i.e., the user should have to specify as few options as necessary. A nice side effect for this pattern is that those options class may contain extra logic if that's something you need.

I don't buy the argument that this makes (type 3) dependency injection a breeze. Surely, implementation-wise it's a breeze, because you can stuff whatever you like in an array and hope for the best, but dependency injection shouldn't trade off readable code, and you shouldn't have to depend on dependency injection to be able to create a class.

So yeah, I'm somewhat against unified constructors. Moving on...

Exceptions. What's the deal with those marker interfaces and having to wrap stuff to use it? From what I can tell, the argument narrows down to this: it allows us to catch "zend" exceptions, or "zend\somecomponent" exceptions. Let's say I'm writing some code in the zend\navigation namespace, and want to throw an InvalidArgumentExcception. Do I have to a) make an empty Exception marker interface in the namespace, then b) make an InvalidArgumentException that extends SPL's InvalidArgumentException and implements the marker interface? I'm asking not because I'm trying to bash the sketched solution, but because I find it unclear. It seems extremely cluttered, I have to admit, and there is no apparent use-case where you'd benefit from catching exceptions based on component. Furthermore, an InvalidArgumentException is an InvalidArgumentException – its logical meaning doesn't change whether it's used in the zend\navigation namespace or the zend\view namespace. I've never understood why ZF does things so differently with exceptions than other languages/frameworks I know. Nowadays we're just throwing the general "component exception" no matter what, we don't have exception classes that carry any meaning by themselves. This is a shame, because it really is much easier to work with exception classes you immediately understand what means. And to cap it all off, this would mean you wouldn't have to catch "general" exceptions where it doesn't make sense.

Let's use SPL exceptions directly, that's what they're there for. No need to wrap any exception class or make marker interfaces, because it doesn't really solve anything. I know there has been talk about making "translatable" exceptions and whatnot, but it doens't look like this is happening any time soon, and in case it does, it could be implemented by retrofitting a TranslatableException interface or by introspecting general exception classes (which would make it work outside the ZF world as well).

Now for the finale, our favorite topic of discussion: class/interface naming. I wrote a comment about this in the Controller 2.0 page yesterday, but it seems it got clogged in the tubes or something. I know this has been discussed before, but I'm curious to see the reasoning behind the current Interface suffix scheme, because as I recall it, this has never been anyone's favorite. First off, Interface is a long word, and takes up quite a bit of horizontal space. I'm not trying to be a 80-characers-per-line nazi here, but I generally am in favor of shorter, more descriptive names. Secondly, the Interface prefix looks weird in variable declarations and params, because we're passing discrete implementations, not interface. We all know this, of couse, but I can't help but to find it irrational/illogical. "I'm passing this event interface to the _invoke() method". We don't say that, we say "I'm passing this _event to the __invoke()" method. I guess what it comes down it is that the Interface prefix simply doesn't read well.

Regarding abstract classes, what's the currently preferred scheme? Is an Abstract prefix/suffix considered good practice? I'm actually okay with an Abstract prefix where it's absolutely necessary, but generally it's always possible to give it a more descriptive name. Base may also be considered as a prefix/suffix, because this reads well and actually indicates what the class is – a base for other classes to extend. Another option, which I feel haven't been given enough consideration, is to use a Default prefix. This is particularly handy in situations where you have an interface and a default implmentation of the interface, like with the currently suggested Controller 2.0 implementation. Also, I've seen this used in several other languages (and yes, that is an argument, because we all feel comfortable with what we already know).

Instead of ...

<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
class ActionController implements ActionControllerInterface
public function __invoke(EventInteface $event) { }

... let's use:

<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
class DefaultActionController implements ActionController
public function __invoke(Event $event) {}

There, fixed it. A lot easier to read, and frankly it just looks way cooler. On a semi-uninteresting sidenote; shouldn't the controller take a more specific Event type, such as MvcEvent, ControllerEvent, or DispatchEvent? Let's not forget the mantra "descriptive names". I doubt it's the intention that a controller should be able to dispatch any event. Also, with descriptive names (as opposed to several components having just Event classes like with Exception), we wouldn't have to alias imports if we were to use events from several namespaces in the same class.

Urr, I think that's it for now. It's a bit tl;dr, but I hope I could get some points/opinions through.

And again, this is not bashing out on the framework just for the hell of it, because I really do like the direction of the framework, and I'm not trying to rain on anyone's parade.

I think the essense of what I'm saying is that code should be self-documenting and easy to read, easy to learn.

Nov 13, 2009

Interface naming:

I'm not a fan of long names but I think it is important to see if it is an interface and abstract class or a normal class. This makes is more easy to debug and understand the code.

In my opinion a good naming would be to add the prefix "I" to interfaces and the prefix "A" to abstract classes.

EventInteface -> IEvent

EventAbstract -> AEvent

Exception interface:

The use of this marker interface is very flexible and don't make it more complicated. Now you can determine if you would like to catch an exception by SPL name or to catch exceptions from a specific component (or from all zf components)

My only objection is the naming of the interface \Zend\FooBar\Exception. It isn't based on interface naming standard and block the name for a simple component exception that extends directly the exception class.

Please rename the exception interface to \Zend\FooBar\IException or \Zend\FooBar\ExceptionInterface

<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
interface \Zend\IException
interface \Zend\FooBar\IException extends \Zend\IException
class \Zend\FooBar\Exception extends \Exception implements \Zend\FooBar\IException
Nov 13, 2009

We have already defined how interface and abstract naming will work in the coding standards, and this will not change in 2.0 (the definitions were actually intended for 2.0, to be honest). They are:

Interfaces are suffixed with "Interface": ActionControllerInterface

Abstract classes are suffixed with "Abstract": ActionControllerAbstract

This policy keeps them grouped together and with their default implementations. Additionally, it's an easy rule to remember and implement for non-native English speakers.

As for Exceptions not following this rule, that is because there may be components where there is no Exception marker interface, and others where there is; it's more consistent to use the same name regardless of implementation.

Nov 13, 2009

Your comment wasn't posted when I posted my comment below, so I didn't see it.

So this is nailed in stone now? I guess it's okay to be consistent with such a naming scheme, even though I want to pull out my hair every time i suffix something with Interface <ac:emoticon ac:name="wink" />

Nov 13, 2009

Interfaces are suffixed with "Interface": ActionControllerInterface

Sounds ok for my. Essentially it is viewable by name. <ac:emoticon ac:name="smile" />

Exception interface:

> As for Exceptions not following this rule, that is because there may be components where there is no Exception marker interface, and others where there is; it's more consistent to use the same name regardless of implementation.

I don't understand this. The definition is (on top):

"Exceptions. Each component will have an Exception marker interface, with exceptions defined for discrete exception types thrown by the component."

-> This means for me in ZF2.0 ALL components have to implement this marker interface.

And the next sentence:

"The concrete exceptions will either extend the global Exception class or an SPL Exception, and also implement the component Exception interface."

-> How can the component implement an Exception which extends the global Exception class if the name of the marker interface is \Zend\FooBar\Exception ?

Generally why we say Allowing Class/Component renaming for naming consistency but add a new inconsistence ?

Nov 13, 2009

What's the benefit of catching exceptions per component? Initially it sounds like a useful feature, but I've never had the need to do so.

Regarding interface naming, I also like the simple "I" prefix – ISomething – but we shouldn't need to specify in the interface name that it is an interface. It's derived from the context where it's used.

I don't care for the "A" prefix for abstract classes. It looks weird, and I don't see why ZF should define its own naming scheme when we've had others for years in other languages and libs.

Nov 13, 2009

The benefit comes when you want to differentiate your own exceptions from those of the framework or those from other 3rd party libraries. Just because you're not doing it doesn't mean others are not.

As for the I/A stuff, see my other reply to you.

Nov 13, 2009

Robin, thank you for your detailed and well-considered comments.

unified constructor

The original thought behind the unified constructor is that, because this has become a common pattern throughout the framework, we should make it explicit. That said, you, Stefan Priebsh, and others are providing some excellent arguments against the concept – and I particularly appreciate that you are providing some alternatives to the practice.

The areas where the pattern has become useful can be lumped into two primary categories:

Plugin/adapter classes

Service classes

The first case encompasses components such as Zend_Form (particularly elements, validators, filters, and decorators) and Zend_Application (particularly resources); the second refers to the various Zend_Service consumables, a number of which have, due to changes in the remote APIs, needed to change constructor signatures. In the case of plugin/adapter classes, typically the objects are being created via a factory, and methods are not being called until after instantiation. In the case of service classes, often the values passed to the constructor are necessary in order to connect to a given web API – but will not be used until a call to the API is made.

In both cases, the information is typically not required by the constructor. As such, having a "Configurable" interface that defines setOptions($options) would likely suffice. This interface should be fairly uniform, particularly in implementation, to ensure that developers can use it easily.

I also like your idea of using configuration "containers" to pass to either the constructor or setOptions(). This has benefits particularly for those using IDEs, and provides an OOP paradigm; that said, I think allowing an array and/or Zend_Config object also should be allowed. I'd like to examine this idea more.

For now, let's operate under the assumption that the "unified constructor" is not set in stone, and may be replaced with one or more other recommendations that will serve to solve some of the same issues regarding APIs.

First off: this use case actually did not originate with myself or the Zend team, but was one brought up and agreed upon during the original PHP project interoperability group meeting at php|tek in 2009. If we don't do this, we'll be operating differently than other frameworks – which makes that particular point of yours moot.

The rationale is clearly described in the narrative, but I'll bring up the salient points:

It allows catching the exception as an SPL/native Exception

It allows catching the exception as a specific vendor/component/subcomponent exception

It encourages creation of well-defined and descriptively named exceptions

interface/abstract naming

I thoroughly agree with your points on naming. There, it's said.

However, there are other points of view to consider. Yes, you have a good grasp of the English language – but not all non-native speakers do. Coming up with a good name for an interface or abstract class can be difficult, particularly in a language as nuanced as English (e.g.: what do you call a Person interface? Personable? not quite the connotation desired...). Additionally, if you have both an interface and an abstract implementation sitting beside a concrete implementation, naming becomes even more difficult. Consider the case of routing: a good name for an interface might be "Router", but what do you call the concrete implementation? or an abstract implementation?

Finally, while API docs and IDEs may make finding the interfaces and abstract classes easy, what if you don't have the API docs in front of you, or don't use an IDE? How do you distinguish, by glancing through the filesystem, which class is an interface, which an abstract, etc?

Having simple, clear naming rules alleviates these issues:

Abstract classes end in the word "Abstract": PersonAbstract

Interfaces end in the word "Interface": PersonInterface

Sure, these may be somewhat ugly, but having easy to follow rules solves all of the above issues. It also fits your criteria of the code being self documenting, not only in how these elements are defined, but in how they are named.

Nov 13, 2009

Thanks for taking the time to reply and explain some of the thoughts behind the decision. It's cool to see that something as nerdy as "unified constructors" can upset and engage so many people <ac:emoticon ac:name="smile" /> People really care about the framework, which is a good thing.

Also, thanks for summarizing the PHP Interop Group thingy. I was given a link on the mailing list, but couldn't really find anything on the topic at the URL. To be honest, I still don't get it, but that's fine. As long as I get to throw SPL exceptions, I'm happy.

I won't continue to nag about exceptions and class naming, because let's face it: it doesn't really matter that much. It's not the end of the world whether we go for one naming scheme or the other, the functionality remains the same.

I'd still like to answer some of the (rhetorical) questions you raised, though. (This time just for the hell of it. It's Friday night and I need a break from glaring at AS3 code. FML)

Q: What do you call a Person interface?

A: Person.

Q: Consider the case of routing: a good name for an interface might be "Router", but what do you call the concrete implementation? or an abstract implementation?

A: interface Router, class DefaultRouter, abstract class AbstractRouter (or abstract class RouterBase)

Q: ... what if you don't have the API docs in front of you, or don't use an IDE?

A: I wouldn't expect anyone to learn the ins and out of the framework architecture without ever using some sort of documentation. I'm thinking that if you're really looking for abstract classes or interfaces in a specific namespace, you probably already know what you're looking for (to some extent).

Q: How do you distinguish, by glancing through the filesystem, which class is an interface, which an abstract, etc?

A1: Again, you probably have an idea what you're looking for.

A2: There aren't that many interfaces or abstract classes in any given namespace. Actually, in most cases (yup, I skimmed through the working dir with find and grep) there's just one interface and one abstract class. Determining which is which just by looking at filenames is not at all an impossible task, even if you suck at English.

A3: This argument falls through when introducing Phar packaging.

It also fits your criteria of the code being self documenting, not only in how these elements are defined, but in how they are named.

Quoted for truth.

Nov 13, 2009

Thanks for the response, Robin. Had me laughing for the first time today!

I just want to point out one thing with the naming questions: you came up with some right off the bat, but even in those, there's a ton of variability – does the indicator of abstract (regardless of what it is) come before or after the class/component name? Does "default" or "base" indicate abstractness? etc. The goal of the naming conventions is to take some of the variability out and make it consistent, particularly between different developers.

As you say: in the end, it doesn't really matter that much – so long as we're all following the same rules.

(I'll dig up the link to the Interop group statement on exceptions soon and post it.)

Nov 13, 2009

Just to clarify.

1. Yes, "Abstract" would always be a prefix, so it reads as "an abstract DoesSomethingClass".

2. "Default" indicates a concrete implementation – "the default DoesSomethingClass".

3. Not too fond of "base", really. Let's forget I even said that.

Mar 10, 2010

I don't know how late-to-the-game I am with my reply, but I felt compelled to point something out to Robin, and other anti-unified constructionists out there: You can still "document" the constructor even with just an array as a parameter. Take the following code snippet as an example:

<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
class Foo {
public function __construct($options = array('foo' => '', 'bar' => '', 'baz' => ''))Unknown macro: { var_dump($options); }
$foo = new Foo;

If a unified constructor were to define the "default" options that it accepts in the constructor, then in my opinion, we could have the best of both worlds.

PS. I have not yet finished reading all of the comments, so if this has already been said, then please accept my apologies. I just wanted to get this out there before I forgot what I wanted to say. <ac:emoticon ac:name="smile" />

Nov 13, 2009

I strongly suggest not to introduce the unified constructors.

The main reason is that you give away the two main advantages of dependency injection through the constructor, explicitness and the ability to use type hints. You'd force developers to look at the source code to find out about required or optional dependencies (I'm just focussing on the dependency injection aspect of the parameter arrays here). Type hinting is possible in the individual setter methods, but not in the general setOptions() method. This will lead to problems, or require people to explicitly code type checks.

Another reason, albeit less important, is that you make it a lot harder to figure out which constructor arguments are optional. Constructor arguments with default values make that very easy.

The Foo implementation shown above has a hard-coded, implicit dependency on Option, which is really, really bad. Number one, you have to look at the Foo source code to learn about the dependency, as Option does not show up in the Foo API. Number two, you cannot easily swap out Option for anything else. Late static binding can obviously help, but if somebody wants to extend Option, they will still have an unnecessary hard job.

In the above example, Option is basically a registry through the backdoor. Pass $options with "everything" to the Foo constructor, let Option pick the values that Foo need by checking for which setters there are. I see a high potential for abuse.

In addition, Option makes some assumptions, for example the presence of a public setter method named setSomething(). Underscore-separated names are converted, which implies that you run into all the troubles of named parameters when renaming a setter method: the IDE is not going to help people, they have to figure out that they must fix their named parameters throughout the code. If you choose that route, you have to throw an exception in Option when a setter does not exist - otherwise people have to debug their code just to find out that due to a typo, one option value has not been set.

Last but not least, the above example requires a public setter for everything that I may want to pass in as a constructor argument. Especially when it comes to injecting dependencies, this is in most cases not what I want: I want to force users of my class to pass a dependency as a constructor argument, but I want to prevent them from being able to change that dependency later. By requiring a public setter for everything, you introdoce a lot of potential for people to screw up.

To sum it up, in my opinion the disadvantages of unified constructors by far outweigh the advantages they offer.

Nov 13, 2009

I would also prefer to reduce the dependencies instead of having all these objects passed in the constructor, but it is not simple. I guess the Option class is only a tentative to avoid repetitive code, and it cannot be injected, because it is used to inject.

For the setters problem, it would also be good to prevent further changes to the class, but this can be achieved via setters that accept a value only if it is not already defined.

Since there is a lot of dependencies in Zend Framework classes, why not get rid of the Option class and using setter injection instead? Since the actual construction would be performed automatically by a injector/provider/container there is really no difference. We can even adopt a new standard and name the setters injectCollaborator(), injectOtherCollaborator() and so on.

Nov 13, 2009

I agree to some degree. If Option is indeed used for this, it should follow design by contract, and therefore the parameter should imho do the configuring, not a some hard-coded class. That would get rid of your dependency injection troubles.

<ac:macro ac:name="noformat"><ac:plain-text-body><![CDATA[
class Foo {
function __construct($options = null) {
if($options instanceof ConfigureInterface)Unknown macro: { $options->configure($this); }
elseUnknown macro: { // maybe try something else, or throw an exception, whatever. }

Zend_Config for example could implement configureinterface and configure the Foo class in the "standardized" PHP way, but you could replace it easily with your own implementation of the ConfigureInterface.

Finally array options, they could (and imho should) be disregarded, and simply be wrapped in a "ConfigureInterface" that handles arrays, for example Zend_Config itself, or maybe the "unified" constructor could handle this for you, which would be a "service" to the user, more than a recommended usage:

<ac:macro ac:name="noformat"><ac:plain-text-body><![CDATA[
class Bar {
function __construct($options = null) {
if(is_array($options))Unknown macro: { // default to standard Zend_Config implementation}
elseif($options instanceof ConfigureInterface)

As for required dependencies, they (imho) shouldn't be in the options altogether. They should be simply part of your constructor definition:

<ac:macro ac:name="noformat"><ac:plain-text-body><![CDATA[
class Baz extends Foo {
function __construct(SomeDependencyInterface $dependency, $options = null)Unknown macro: { parent}
Nov 13, 2009

Stefan – thanks for your comment!

Based on your arguments and those others have made, I'm definitely inclining to revisit this decision, and you can see more of my thoughts on this in a reply to Robin Skoglund further up the thread. As I note there, the pattern really makes most sense for those classes being used as plugins/adapters, or for classes where we know that constructor arguments may vary over time (concrete service consumable classes – the Zend_Service tree, basically). Even so, there may be other approaches we can consider – and I'm willing to do so as long as we can approach all such cases in a uniform way. One issue ZF is often take to task for is the inconsistency of API, and that's one thing I want to address with 2.0.

Nov 15, 2009

Since the dispatching process and the "plugin" systems are going to change, I was wondering if it wouldn't make sense to make their design suitable for C implemented extension. Those two "components" really need to be as fast as possible and I assume that a "simple" PHP extension, which implements support for them, would really help to obtain some very good speed gains.

Those features are common enough in modern web development that an extension like that could also be useful for other frameworks.

Nov 15, 2009

This actually sounds like a crazy cool idea. +1 from me

Nov 15, 2009

Offering both would be best in my opinion. Not everybody will be allowed to run custom PHP extensions on his platform. There could be some interfaces implemented in C by the extension and in PHP.

Nov 15, 2009

Some people apparently have thought about doing this already pre-1.0, and more recently we also gave that a shot ('round the release of 1.7). However, because we didn't have time, nor enough C programmers we froze the project for a while/indefinitely (we'll see which of the two).

Having said that, I do think porting stuff to C++ is a good idea. However, since ZF is a PHP framework, design decisions should be made with (primarily) having PHP in mind, not an other language. Basically anything done in PHP can be ported to C+, and considering that I think we should first have something stable and working in PHP, before people start porting it to C. Also, due to the time it takes to port PHP to C+ (trust me, it does..) such a PHP module would always be 'behind' with the ZF releases.

One advantage; you can just run the unittests to see if all functionality was ported correctly (another pro for unittests <ac:emoticon ac:name="laugh" />)

Nov 19, 2009

Even though I believe that all those improvements discussed here are really good, I think - as of today - ZF is mostly lacking of good support on the Model and does have great room for improvement there, I think. I feel that part as being under-represented in the discussions so far.

I would love to see the Service Layer being more exposed and more "default" so that developers stop putting business logic in their controllers and - even better - also stop putting it into the business objects. Business logic perfectly fits into the service layer and ZF could support that by making a service layer "something really normal that is there by default". ORM is another topic that - I beliebe - is already covered by ideas of integrating Doctring (2) or at least making usage of Doctrine, Propel etc. easier in ZF. Zend_Db is pretty fine, but Doctrine & Co. really provides persistence in another dimension.

One thing missing also is solid support for transactions. Having something like JTA would really push ZF / PHP heavily towards "enterprise readiness". Also applications are going to be more and more distributed and therefore transaction management is getting even more important. Without solid transaction management, mission critical enterprise applications are hardly imaginable, to be honest.

Thanks for taking time reading through my thoughts. Really appreciate!

Nov 22, 2009

How about implementing request parameter mapping to action method parameters out of the box? I've seen many implementations of it, but having the option to utilize it out of the box would be nice..

http://devzone.zend.com/article/10861-Request-parameter-mapping-to-action-method-parameters
http://fbdevzone.com/2009/10/request-parameter-mapping/

Nov 23, 2009

Personally, I'm not terribly interested in this. The request object is mutable, and by implementing request parameter => action method parameter mapping, you actually limit the functionality quite a bit, as well as put more of an onus on the end-user developer to define the required parameters. As an example, if, in the future, they require more parameters, they will have to change the method signature.

That said, with the proposed implementation, you could quite easily do this within the __invoke() method, and we could have a variant action controller type that allows it. I just do not feel it should be the default use case.

Dec 08, 2009

From my perspective improving performance of the MVC layer seems like the most important task. The current implementation has its "slowness" distributed over many components thereby making it very hard improve the situation.

I therefore welcome a rewrite of the MVC layer very much. I would argue for making the most common use case faster even at the cost of more complexity in other use cases.

Also it could be considered adding a section to the performance section of the Reference Guide that shows an example of how to make some requests go around the front controller but still use ZF components. E.g. a php file in the public directory that includes the bootstrap but does not start the MVC layer.

Dec 12, 2009

I have two major issues with the above proposed implementation of zend\Options. Actually three. The third being that IMO you should get rid of the classes in nodes, ALL of them. Options should have it's own package, options. So, zend\options\Options. Pretty pretty please.

The first problem I have with the actual code is that passing of arrays instead of objects: it leaves no room for extension. Poor design choice.

The second problem is directly related: use of a static interface. Do you really want to introduce even more static interfaces in ZF? Please no!

Dec 13, 2009

Please see the above discussion; we've already decided not to implement the Options class/package.

Dec 16, 2009

I think ZF 2.0 with a minimum requirement of PHP 5.3 is a very large mistake. Take a look at all the web hosts around. Many of the web hosts (especially shared hosts) do not yet offer 5.3. DreamHost for example says they can not move up to it until all the 3rd party PHP modules they use are supported under 5.3, they have tested it and then had a server upgrade.

I can not name a single shared web host that supports PHP 5.3.

Do you expect ZF 2.0 to be used by anyone on shared web hosts?

Dec 16, 2009

I don't think 5.3 will be a major issue. The next version of Symphony and Doctrine will be 5.3 only, and they're both due out (probably) sometime late next year. Besides, the web-hosts will be slow to upgrade if there's no demand for it.

Dec 17, 2009

ZF 2.0 is not going to happen overnight; we're anticipating being ready for release no earlier than late 2010. By that point, I have no doubts that 5.3.2 will already be released, if not even 5.3.3 – in other words, it will be a fairly mature product.

Currently, most Linux distributions are already offering 5.3 as the standard current version, as is Mac OSX. Since the distributions are already backing it, the hosting providers will not be long to follow – and many have already indicated that they are preparing for it.

One way to get hosting providers to upgrade their offerings is through user pressure. Since ZF, Symfony, Doctrine, Agavi, and other projects are planning 5.3-specific offerings, there is already tremendous pressure from their respective communities directed at hosting providers – and this will have an effect.

Finally, we plan to support the last minor release of the 1.X branch for a while following the 2.0 release, as we know that upgrading will not be something everyone can jump on board immediately – in part due to hosting providers. You do not have to adopt immediately.

Dec 18, 2009

Really, why so late? The whole host support question is completely unnecessary, exactly for the reason above: branching. If you are going to branch anyway, why not get 2.0 out there ASAP? People (like myself) are impatient for a namespaced ZF. Doctrine is releasing a first beta of their 2.0 in early January. Yes, Symfony is mentioning late 2010, but personally I do not care much about Symfony. But perhaps exactly because Symfony is being so slow about it, ZF has an opportunity to jump in that gap.

Overall I simply don't see why it has to take a whole year. Adapting the current codebase to use namespaces really shouldn't take a year. That's just ridiculous. As soon as you establish the guidelines any twat can do it. I realise there are (some) other changes you would like to be included in the 2.0 release, but really, those can be in 2.1 as well, who cares, it is just a number. We have been waiting in anticipation for namespaces for a very long time, and now that they're finally here, and our IDEs finally support it, you're telling me I have to wait another whole year before I will be able to use a namespaced ZF. I beg of you to reconsider. Pretty pretty (pretty) please.

Dec 18, 2009

It's more than just namespacing that we're doing. We're re-architecting a number of components in order to make them (a) easier to maintain, and (b) more performant. That work will not happen overnight. At the same time, there are a ton of issues in the tracker that need to be addressed or at least considered (to ensure we don't propagate them to the new release, or to ensure requested features make it to the new release). Additionally, since major releases are the only times we can break backwards compatibility, we want to try and address as many such breaks as possible now so that we won't feel hampered 6-12 months down the road and have to wait another 2 years to change things. Finally, who do you think is going to do the work, exactly? Yes, we have 3 folks at Zend, myself and two others – but we have to work not only on this, but also maintaining the current branch, reviewing new code contributions, documentation, maintaining the site, and more. The community? Mostly volunteers, who have limited time individually to contribute. As an aggregate, yes, we can make progress – but it will take time.

Doctrine started work on 2.0 close to a year ago – they are proof that a change like this won't happen overnight.

Dec 18, 2009

Well, Doctrine 2.0 does have a lot of changes other than namespacing as well.

I'm am not saying that wont be a lot of work nor claiming you have massive human resources, I just said that looking at just namespaces, it should be possible to get that released early next year. I'll admit though, I hadn't thought of BC and the policy to only break it on major releases. And I wont deny some parts of ZF could use some BC breaking refactoring. I guess it would have been a good idea to start a little earlier, especially considering how long 5.3 has been in development, but there's nothing to be done about that now. It's indescribably disappointing though.

Dec 18, 2009

The 5.3 API did not stabilize until 2-3 months before the stable release. Since we were planning on taking advantage of a number of new language constructs, we needed to wait until they were stable to even begin planning (namespaces, for instance, underwent a number of iterations; additionally, some features like traits looked like they might make it into 5.3, but were dropped relatively late in the 5.3 cycle).

Could we have started planning earlier? Potentially. But with initiatives like Zend_Tool, Zend_Application, and more, we were already overwhelmed with responsibilities.

Frankly, I think it's probably just as well we wait. It's always good to wait until at least the .1 version of any release series to ensure the biggest bugs are worked out, and to get a chance to see how usage patterns pan out. We're much better prepared at this point to adopt 5.3 features than we would have been had we started planning earlier.

Dec 18, 2009

I was not going to make a big deal out of this, but since you shared your view on it, I'll do the same.

It does not matter if the API was stable. It was in development, so it's not surprising that things changed along the way (although admittedly the last minute change did have larger implications than you would normally expect so late in development).

What's more important is that you could have started with the BC breaking refactorings, in general, sooner. You know, those things that you are saying prevent you from putting a namespaced release out there early next year. Not because you've known how namespaces were going to work for a long time, because you didn't, but because you knew there was going to be a PHP release with namespaces. It doesn't require a lot of imagination to have the foresight to see that a lot of your userbase can not wait to use this feature.

Are you telling me there was some conscious choice that favoured development of Zend_Tool and Zend_Application over preparing for 2.0? Because then you guys made a major error in judgement. Because in my humble opinion those additions really don't add any "much needed" functionality, but more importantly, addition of those do not break BC, thus could have been added after 2.0.

Dec 18, 2009

Can we quit crying over spilled milk?

Dec 18, 2009

We can. I wasn't planing on furthering the discussion in this direction, that was just my response to Matthew's defense of the current time frame. I realize and mentioned there is nothing to be done about it now (aside from breaking with the BC policy perhaps), but I disagree that this was unavoidable as one would think by taking that reply word for word.

Perhaps a more interesting discussion would be what can be done to get to 2.0 as soon as possible, as in sooner than the currently projected release date of late 2010.

Dec 18, 2009

I am also really waiting for ZF 2.0 to come and I would love to get it as soon as possible. But what I don't want is when the requirement "to get it released asap" is getting more weight than all other requirements mentioned in the discussion and on this page. I rather wait another 12 months and get a production ready ZF 2.0 than have to wait maybe even a longer time to get ZF 2.1 or even 2.2 which fix all the problems that have been left in ZF 2.0 to release it asap.

12 months isn't really a long time nowadays.

Dec 19, 2009

I would agree, except for the 12 months is not a long time part. 12 months is an agonizing long time when you are waiting, and I already went through it waiting for PHP 5.3 to get to stable (on a side note I fail to see how 12 months has gotten any shorter).

That said, I think the main focus for 2.0 should be refactoring for flexibility, which allows you to tack on new behaviour to your hearts delight without breaking BC until 3.0.

Dec 18, 2009

I agree with Matthew on this. Everyone will have to wait for the established projects to implement their upgrade strategy.

If you simply can't wait, consider new projects that are built from scratch on 5.3. I'm aware of one such framework project: Lithium

And Matthew touched on a point about resource constraints. There always one good way a developer can help him with that problem. <ac:emoticon ac:name="wink" />

Dec 19, 2009

> "I agree with Matthew on this. Everyone will have to wait for the established projects to implement their upgrade strategy."

The need for refactoring, the BC policy and namespaces did not drop out of the sky though. Anyway, lets drop this. Nothing to be done about it.

Lithium is, if memory serves, a CakePHP fork. Just not for me. Also, I have my own resource constraints. Though maybe this is the ideal time for me to try and get some time available.

Dec 19, 2009

Honestly, I think the timing is spot on. All this talk of planning and implementing new features and refactoring for ZF 2.0 far earlier is sort of silly. PHP 5.3 is so new, and we have so many components, that until very recently there would have been a major shortage of developers with 5.3 experience. It's also completely moot - ZF 1.9.x and 1.10 work perfectly well under PHP 5.3 - nobody absolutely must have ZF 2.0 right now.

>The need for refactoring, the BC policy and namespaces did not drop out of the sky though. Anyway, lets drop this. Nothing to be done about it.

Your point? You expected us to cease all development for PHP 5.2, a version which will be supported for years to come and is everywhere, simply because PHP 5.3 might get widely adopted a year or two from now? We've known all this for a long long time - but I'd say most of us are still using PHP 5.2 in production. The will to improve ZF 1.x for our current production needs is still relevant. I won't be using 5.3 in production for a long time yet simply to let a few mini releases roll out with any loose issues resolved.

Dec 19, 2009

> "PHP 5.3 is so new, and we have so many components, that until very recently there would have been a major shortage of developers with 5.3 experience."

Really, as I've mentioned before, nobody would have needed any 5.3 experience to implement the refactorings that are needed. The two (support for 5.3, namespaces in particular, and BC breaking refactoring) are completely separate, except in that implementing namespaces in itself is a BC breaking refactoring. I'll reiterate that I doubt I am the only one waiting for the opportunity to use the 5.3 features in production environments. If refactorings were further progressed, this would have been a reality many months earlier.

> "You expected us to cease all development for PHP 5.2, a version which will be supported for years to come and is everywhere, simply because PHP 5.3 might get widely adopted a year or two from now?"

No, of course not, that is ridiculous. I would have expected to start the BC breaking refactoring for 2.0 sooner. In a separate branch.

However, I would like to add that I am not looking for scapegoating or anything like that. It is the way it is, and as much as you all can deny error on anyones part or acknowledge it, it does not effectively change anything right now. The continued defense of the current state of things is more a battle of egos than anything else IMO.

> "It's also completely moot - ZF 1.9.x and 1.10 work perfectly well under PHP 5.3 - nobody absolutely must have ZF 2.0 right now."

Maybe you can explain to me how not being an absolute requirement makes it moot? I can think of an endless list of things that I do not absolutely require, but make a major positive impact on development nonetheless.

Dec 19, 2009

>Really, as I've mentioned before, nobody would have needed any 5.3 experience to implement the refactorings that are needed.

It's really hard to see how one could take advantage of PHP 5.3 without the necessary experience. Sure, you could hit the low hanging fruit but that is mere cosmetics and doesn't bring about significant advantages or improvements to the framework as a whole as the Roadmap is currently hinting at. Switching syntax a new major version does not make. The relevant refactorings depend on your view - there are dozens of components that could use improvement outside the MVC core. Without more resources, hitting all of them is very difficult.

>No, of course not, that is ridiculous. I would have expected to start the BC breaking refactoring for 2.0 sooner. In a separate branch.

I was hinting at the resource issue. Take myself - I could have a) worked on ZF 2.0 during 2009 or b) written Zend_Feed_Reader, Zend_Feed_Writer and Zend_Feed_Pubsubhubbub which I really wanted yesterday on my production platform which will run PHP 5.2 for at least another six months. I could not do both. The needs of the now will always be more pressing. We're only now hitting the point where those needs are starting to coincide with PHP 5.3.

It is something of an ego battle <ac:emoticon ac:name="wink" />. People have worked their asses off for every single ZF minor version this year with some really amazing results applicable right now to improving their applications. Questioning why nobody was worked on ZF 2.0 misses a huge point - everything we've done IS an improvement for ZF 2.0. You've missed the indirect benefits of that. Zend_Application? Zend_Tool? Zend_Feed_XXX? Tons more. Throw in Matthew's MVC improvements (which he even has some code for) and you have a card of features that could already justify a ZF 2.0 release even without the PHP 5.3 improvements. Frankly I'm amazed at some of the stuff we've crammed into mere minor releases <ac:emoticon ac:name="wink" />. You should looks at how lines of code has increased month on month since the 1.0 release. That ZF 2.0 is an opportunity to allow PHP 5.3 as a dependency and break compatibility where needed shouldn't de-emphasis the fantastic work of the past year in making the framework better than ever with new features. I've always thought we passed the watermark for a notional ZF 2.0 months ago and we're really working towards ZF 3.0 <ac:emoticon ac:name="wink" />.

> Maybe you can explain to me how not being an absolute requirement makes it moot?

You could run ZF 1.10 on PHP 5.3 in production today. PHP 5.3 isn't the reason for ZF 2.0, it's merely another dependency we can leverage off. People overestimate the importance of PHP 5.3 to improving anything. If you have good code now, you'll still have good code on PHP 5.3. The reverse also holds true. An awful lot of improvements that can be made have nothing to do with the PHP version. This is the unfortunate consequence of having ZF 2.0 and PHP 5.3 so closely linked.

Dec 19, 2009

You hit the nail on the head. The key to this discussion is exactly as you just put it:

"People overestimate the importance of PHP 5.3 to improving anything."

I guess now that PHP 5.3 exists at all anything written against PHP 5.2 is just an abomination right. Really, I mean, those who have reviewed the code behind 1.9+ (I do this for any code I'm going to use on large projects), don't you think it's pretty good even without 5.3?

Sure, I want 5.3 and I want everything I use to support it, BUT ==>> http://framework.zend.com/issues/secure/IssueNavigator.jspa?status=Open

The time invested in discussing this moot issue could have been used to resolve a couple bug-hunt days issues. Every issue resolved now is going to make 2.0 that much better.

 Padraic, thanks for working on the very components that I use to get stuff done instead of jumping to 2.0 just because you thought it would be cool.

Dec 19, 2009

We'll agree to disagree. I don't use Zend_Feed nor Zend_Tool and didn't really need Zend_Application. In contrast, I am, and I am guessing a lot of users if not most, very eager to start using namespaces in ZF projects. From this perspective your priorities seem off. May be you're right though, and your userbase is more appreciative of before mentioned components than it would have been of a quick namespaced release. In which case I stand alone and acknowledge that this discussion is moot. But I seriously doubt it.

Dec 19, 2009

A quick namespaced release would never be ZF 2.0 since it's mere cosmetics if nothing deeper - if folk want namespaces that bad there's nothing stopping them from contributing a namespaced 1.10 release. I'm sure all of us would appreciate the help. I'll agree to disagree though <ac:emoticon ac:name="wink" />. I don't view namespaces as sufficient justification alone for a major release.

Jan 04, 2010

All the talk on the features and specs for ZF 2.0 are great but one thing I think was kind of forgotten about on the 1.0 release was the documentation. Now don't get me wrong I think we have great component documentation but one thing I think we could use more of is actual use case tutorials. Say someone wants to get Auth/Acl/Navigation setup on their website; why should we rely on them searching through a whole lot of blogs (outdated) which are possibly using bad practices? I think before we even start to approach the release date of ZF 2.0 we need to have more Getting Started and use case documentation written; and actually it's something I would like to help out with too.

Jan 05, 2010

This is already in the works. Please have a look at a test version of the 1.10 manual
http://www.mikaelkael.fr/doczf/1.10/en/

Jan 05, 2010

Thanks Ralf for the link.

It would be nice if there would be possibility to add comments to the pages. It`s a great addition to manual. Take a look at php.net/manual where comments are sometimes even more valuable than the content of the manual page.

Is there any chance to add this kind of feature or is it too late?

BR,

Jan 05, 2010

This is in the works, and will hopefully be in place for the 1.10 release.

Jan 30, 2010

Just an idea for further refactoring of Exceptions.

In Doctrine 2 we move all the exception messages to the exception class itself which makes "the real code" much more tidy, like:

<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
throw FormException::duplicateElementName($elementName);
class FormException extends \Exception
static public function duplicateElementName($elementName)Unknown macro: { return new self("The element $elementName you specified is already registered!"); }

This way you can re-use exception messages more easily and get all the messages out of the code. Additionally its much easier to globally change exception message behaviour (in regards to error-codes for example).

Apr 23, 2010

Isn't this bringing some more complex development and creating usage errors?

If these methods aren't well-documented, users may throw the wrong exceptions in the wrong place : there are a lot of peolple who are already confused with differences between exception classes RuntimeException and LogicException.

Feb 20, 2010

I would like a freely configurable user authentication module, which can be configured via an ini file. Optimally, this module should have the following features:

Freely selectable database (at least in MySQL)

Completed set of table definitions

Possibility to deposit its own table definition as a set

After creating a new user data to the user via e-mail will be sent

After the confirmation of the new user's account will be unlocked

The reason for my desire is that you need for almost any project, such a module. And it would just be cool if there would be this one (almost) ready-made solution that has to be just configured.

Greetings,

trady

Feb 28, 2010

There are some classes names like "Zend_Config_Writer_Array" which can't simply renamed to "zend\config\writer\Array" because "Array" is a reserved word.

The complete list:

<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
find -name And.php -or -name Array.php -or -name Break.php \
-or -name Case.php -or -name Catch.php -or -name Class.php \
-or -name Clone.php -or -name Const.php -or -name Continue.php \
-or -name Declare.php -or -name Default.php -or -name Do.php \
-or -name Else.php -or -name Elseif.php -or -name Enddeclare.php \
-or -name Endfor.php -or -name Endforeach.php -or -name Endif.php \
-or -name Endswitch.php -or -name Endwhile.php -or -name Extends.php \
-or -name Final.php -or -name For.php -or -name Foreach.php \
-or -name Function.php -or -name Global.php -or -name Goto.php \
-or -name Ff.php -or -name Implements.php -or -name Instanceof.php \
-or -name Namespace.php -or -name New.php -or -name Or.php \
-or -name Private.php -or -name Protected.php -or -name Public.php \
-or -name Static.php -or -name Switch.php -or -name Throw.php \
-or -name Try.php -or -name Use.php -or -name Var.php -or -name While.php \
-or -name Xor

How should these classes renamed ?

(For abstract classes & interfaces the new name is already defined)

EDIT: formated find

Mar 28, 2010

I second (or fifth) the use of Doctrine with the release of Zend Framework 2. Like many others I have already integrated the latest stable release of Doctrine with ZF 1.7 - ZF 1.10. I can not recommend this move enough.

Apr 15, 2010

>I second (or fifth) the use of Doctrine with the release of Zend Framework 2.

+1 One up!

Ship with a mature ORM that comes with a huge community already and provide a best practice example on how to use it within the new Zend MVC.

" Blog it! Post it! Comment it! We need to get Doctrine http://bit.ly/1FH5A9 with the release of Zend Framework 2. http://bit.ly/29LHxZ " http://twitter.com/framework_zend/status/12256250204

Dec 10, 2010

I would like to see Doctrine-like functionality within Zend Framework 2.0, and possibly a Doctrine adapter. I'm not sure if the others are suggesting the inclusion of the actual Doctrine library within ZF2, but I would think that would be off-limits - just as we do not expect to see MySQL or memcached bundled in.

Dec 19, 2010

Please discuss here, this page is "old"

ZF 2.0 requirements


text:
The Round Rock City Council on Thursday, Oct. 10, enacted Stage I restrictions (PDF) that allow only twice-a-week watering for its customers. The restrictions go into effect Monday, Oct. 14.Councilmembers cited the ongoing drought as well as a recent Brazos River Authority (BRA) recommendation for increased water conservation measures for its customers that take water from Lake Georgetown.The BRA issued a Stage 2 Drought Warning (PDF) declaration for Lake Georgetown on Oct. 4, requesting a 10-percent reduction in water use from the reservoir. City Utilities Director Michael Thane said Round Rock customers had already been using less water this year compared to last year, but the potential impact of the ongoing drought necessitate taking additional conservation measures. "This makes sense because if we don't get a significant amount of rain over the next nine months, Lake Georgetown will be at dangerously low levels as we head into next summer," Thane said.So far this year, compared to this time in 2012, Round Rock customers have used approximately six percent less water. Thane credits an aggressive water conservation education program and the City's tiered rates in summer months for the decreased usage. The City of Round Rock's Drought Contingency Plan (DCP) consists of 3 stages. The City is enacting Stage 1 of the DCP and the restrictions for this Stage are based on the following schedule:
Watering is allowed between midnight to 10 a.m. or 7 p.m. to midnight only.
The following activities are allowed in compliance with the watering schedule above:
Not allowed:

subset: commoncrawl


text:
Thursday, April 07 2011, 01:35 PM
A king
bow down and kiss my ring
Then open your mouth and sing
praises again and again
Friday, March 25 2011, 02:13 PM
one and all.
Thursday, March 24 2011, 03:41 PM
This life is uphill
one trouble brings another
With no sister and no brother
No help in this, no frills
And time it slowly kills
Till one and all we feel
That death itself is real
Thursday, March 10 2011, 12:17 PM
well well. What have we here
Are these the dregs of society?
Have I found my brothers and sisters?
I sift through the piles discarded trash
like an old man wielding a metal detector on the beach
or more accurately a vagrant rummaging through the garbage.
I wade through human refuse daily
shunned and rejected they repulse
but me they attract
a shot of adrenaline to an otherwise motionless body.
Thursday, October 28 2010, 01:47 PM
Do you sell plastic dolls?
Thursday, September 02 2010, 01:34 PM
boss lady
Thursday, August 26 2010, 02:11 PM
when you gonna carry scrapah bikes?
Sunday, June 27 2010, 10:59 PM
Thursday, April 22 2010, 01:30 PM
Almost 3 million.
Thursday, April 15 2010, 11:48 AM
I see your clever disguised taunt
And I know what you want
A room for your couch
Or a socket for your plug
But you're homeless and broke
With no time for a joke
Be careful you'll choke
Because the king has spoke
Thursday, April 15 2010, 10:28 AM
The king
Thursday, April 08 2010, 12:52 PM
Whoever said I knew what I was saying?
This mind is not prone to staying
Insanity escapes the slaying
While sanity continues decaying
Thoughts digress, progress regress
This open wound I redress
Slow veins, discolored stains
It reminds me of the time I stopped breathing
Hands still, heart slow beating
Eventual meeting
Black wall creeping
Soul gone sleeping
Thursday, January 28 2010, 12:04 PM
Then it doesn't suit me
And if it doesn't suit me
why buy the suit?
The whole point would be moot
I think it's time I scoot
Thursday, January 21 2010, 11:26 AM
That was the sickest watch you've ever seen?
because despite all the information I could glean
I couldn't find out if it would make women scream
But then I woke up and realized it was all a dream
Thursday, August 13 2009, 12:00 PM
My item took a bonus and now it's on vacation.
This is the story of the man/woman/child/animal/tree who discovered a reason to reason.
Thursday, July 30 2009, 12:41 PM
To rise up against the ever present lack of marginalized root beer stands. We must be united in our quest for ground breaking steam producing plants. To do otherwise would be a grave injustice on the flowering intellect of the unadorned man robot.
I will stand by idly no longer as the very foundation upon which my far reaching grasp has sparked an angle of perpetual vision induced tunnel scope modeled alpha food deterrent of the highest level.
Thursday, April 16 2009, 03:28 PM
That's how you spell potatoe right?


text:
Available Projects
The handle emitted a louder sound when flushed this morning. It wasn't really a breaking sound, but more like something coming loose, or perhaps popping off, perhaps a vacuum release sound.
Checking the tank, I found that the fill tube had become become disconnected from the overflow tube.
Searched online but couldn't find an exact configuration that matched mine to reference here for display purposes.
At the end of the fill tube is a plastic device that looks like an inverted straw hat. The fill tube extends through this and apparently connects or mates to a smaller tube within and extending upward from the the overflow tube.
I can reattach the two parts easily by hand and hold them, but they won't stay together. I didn't see anything in the tank that might have broken off, and I don't know what originally held them together.
What's the EASIEST fix for this? The shutoff valve is stuck so I'd have to work that loose first if I had to change anything.
I'm wondering if I can't just tape the two parts together? (My easy way of fixing things!)
Thanks for any help.This message has been edited. Last edited by: GardenSprite,
sprite, why not replace the whole assembly with a "flushmaster " kit It'll only take about 45 minutes, and be better than what you have now. Only costs about 5 bucks
That was my thought too.
General Disclaimer
Any advice given here is general in nature and is not necessarily valid for your given area. If in doubt check with your local codes enforcement department for what is required when doing electrical, plumbing or structural work on your house. Permits may or may not be required in your area and home owners may not be able to DIY some tasks. I have no way of knowing if you have the skills needed to complete the tasks you are asking about, when in doubt seek professional assistance.
My advice may be worth exactly what you pay me for it. :-) For the record I did not stay in a Holiday Inn Express last night.
The only 'simple' fix is if you are talking about the 1/4" diameter tube that goes from the fill valve assembly to the overflow tube in the middle of the tank.
1. If this tube had come loose from the overflow tube, then all you need to do is somehow attach it so that the end of the 1/4" tube pours into the opening of the overflow tube. If the stock clip that holds it in place is broken, a rubber band twisted around each tube can hold it in place.
2. If it's broken at the fill valve end, then the easiest solution is to get a new valve assembly as everyone else has recommended.
Nona and Sparky, I took a quick look at the flushmaster assembly; not sure what the improvement over my configuration would be but I'm most certainly not knowledgeable about this at all so I'll study it some more.
Nona, it might take you 45 minutes to make the change but it would me hours!!!
Jaybee, I haven't yet mastered a rubber band technique; can't manage to get it around the 2 tubes but am still working on it. And it is as you described in your opening comment.
I'll try again today.
I had some electrical tape holding the two tubes together temporarily but flushing creates pressure which forces them apart so that isn't going to work.
I think there must be a small spring that allows for the fill tube to open and close into the overflow tube, but I didn't see anything like that in the tank. Thought maybe it blew off and was resting on the bottom of the tank.
Thanks for the suggestions; I'm afraid I'm going to have to replace the whole assembly (for me it's a major operation!))but I'll try a few other rube goldberg methods before that -
And, BTW, any suggestions for loosening the shutoff valve? I can't enough leverage just by trying to "rock" it and loosen it.
Thanks again for taking the time to help.This message has been edited. Last edited by: GardenSprite,
You could also just shut the main water supply to the house off, while you work on the toilet.
This is what I used to do, before we had shut offs on all the toilets.
believe me sprite. It's only going to take you 45 minutes. The hardest and slowest part of the job is getting all the water out of the tank.
Once that is done, you disconnect the fill tube from the tank, remove the retaining nut, unpack the flushmaster, stick it into the tank and follow the instructions even a caveman can do it
And, yes, if the shut off valve is too stuck, just shut off the water at the whole house shut off or at the meterThis message has been edited. Last edited by: nona,
I totally agree that it is just not that difficult, nor time consuming. The directions with the Flush Fixer are very clear and step by step. You will feel AMAZED at your ability to fix your toilet! LOL
If you are still worried, often a more handy friend/neighbor can come and keep you company while the two of you complete this repair. Then celebrate together with a successful FLUSH!
As a long time DIY person, I normally will start any plumbing repair like this early on a weekday morning, so if by chance something went wrong (it never did), I could always get a pro out to help.
Quickest way to get your tank drained so you can remove the fill assembly without dumping water all over your floor: Turn off the water, flush the toilet, holding the flapper open to get rid of as much water as possible, take your wet/dry vac and suck out the rest of the water. Easy, peasy, no fuss no muss, no mess. If you need to pull the toilet bowl for some reason, the wet/dry vac does a really quick job of getting the remaining water out of the toilet trap. I'd start by quickly pouring a bucket of water in the bowl, which should empty most of the water out, and then use the wet/dry vac to get the rest. No splashed water on the floor as you move the toilet out of the room.
General Disclaimer
Any advice given here is general in nature and is not necessarily valid for your given area. If in doubt check with your local codes enforcement department for what is required when doing electrical, plumbing or structural work on your house. Permits may or may not be required in your area and home owners may not be able to DIY some tasks. I have no way of knowing if you have the skills needed to complete the tasks you are asking about, when in doubt seek professional assistance.
My advice may be worth exactly what you pay me for it. :-) For the record I did not stay in a Holiday Inn Express last night.
Thanks for all the suggestions and encouragement.
Shutting off the water at the main is certainly an option; I just never thought about it (duh!).
I used to have a neighbor who would quickly volunteer to help if not do the work himself but his wife divorced him and he is rarely around any more.
My father normally would want to help if not do the work himself, but as I think some of you know he's not able to do much of that kind of work any more.
Right now I've found a simple workable solution, but I suspect Murphy's Law will become operative and sooner or later there will be more problems, so I'll plan on visiting the plumbing section of Lowe's when it's a bit warmer. I'm saving all of your responses for that time.
I also will do it at the beginning of the week so I can get help if necessary. I've learned over the years never to clean drains on the weekend for that reason.
It's interesting that that option was never a concern before this winter, when there's now so much snow on the edges of the narrow driveway that nothing but my small car can get through. Any plumber's truck would definitely get stuck in the piles of snow and ice.
Thanks again for taking the time to help me. I'll report back when I get the system changed out, but assuming I do it without help, be prepared for some crowing and bragging about my newfound plumbing capability! This message has been edited. Last edited by: GardenSprite,
We are all pullin for you!
20 years or so ago I took several classes home repair at our local community college. One on plumbing, another on basic home repairs. The home repair class was the best. We did work at the local children's zoo (Building interior walls, insulation, drywall, simple pre-wiring) and for a couple of weeks we divided into groups and went to each others homes to tackle small but needed projects. An instructor came or met with each group. Toilets were included. That class paid for itself many times over!
Figuring out that one can read/follow simple directions and have the confidence to attempt the project is often more than half the battle. We are sure you will do what is needed!
I should probably take some classes too; I think our Lowes or HD had them, perhaps still does. I'm not sure if our community colleges have them but I'll check it out. That's a good idea.
There are 3 campuses of one community college locally, each with a different focus (medical, scientific and sort of a mixed bag of courses).
Thanks for the words of encouragement; I really appreciate it. Right now I'm trying to encourage myself to go and tackle the piles of snow keeping the driveway too narrow for anything but my car just in case I have to call for help. But with the support that's here I don't think I will.
Thanks again to everyone!
when I was a teen, we got the whole series of Time-Life homeowners books. really learned working hospital maintenance. so I have a general idea what is DIYable legally and what I have to make a call for.
if you have to replace the flush assembly, and there is no shutoff, install one. quarter-turn if you can, they are better made and don't gunk up over time. over bare copper, check to see if a Shark Bite type unit is allowed in your jurisdiction for bare copper pipe, beats soldering next to a wall.
the old-time brass sillcokc assembly is long-gone now, which is a boon for DIYers. much easier to just put in the Fluidmaster, whose little hose to the elevated vent pipe inside the tank usually slips into a ring on most toilets. an Ideal hose clamp and a tie-wrap could be fiddled into place if you don't have that ring to hold the hose.
that likely would become, I suppose, a "maintenace item..."This message has been edited. Last edited by: swschrad,
sig: if this is a new economy, how come they still want my old-fashioned money?
well sprite, to rejuvenate an old post, how did you make out with the toilet valve problem ? Did you replace it yourself ?
Nona, I decided not to do anything until there was enough room in the driveway for my plumber's truck to get in if I needed help. It's only been in the last few weeks that the snow finally melted and there's more than just a cow path to get in and out of the driveway.
But then the kitchen sink became a bigger problem, then and now it's more medical issues, so the toilet valve issue remains unfixed, but it's not that much of an issue as I just hold the fill valve after flushing to keep it from spraying the bathroom walls.
Thanks for asking.
|Powered by Social Strata
For general message board help, click the tab labeled "Tools," and choose "Help" from the dropdown menu.


text:
Intervention: (S03.Ep.13) Caylee DVD
Sale Price: $19.99
To Order by Phone Call 1-800-933-6249
- Additional Details
- Format: Closed-captioned, Color, DVD-Video, NTSC
- Rating: Not Rated
- Number of Discs: 1
- Run Time: 50 Minutes
- Region: Region 1
- Aspect Ratio: 1.33:1
- Language: English
- Studio: A&E Home Video
- DVD Release Date: August 17, 2007
Family environment can make some people more susceptible to addiction. Clearly, this was the case for Caylee, a speed-balling heroin-addict that was taught to count calories by a bulimic mother who was never satisfied. This intervention is for mother and daughter to recognize their problems and find solutions.
- At 23, Caylee is a bulimic college drop-out with a heroin addiction.
- Her mother Christy is also bulimic, but does not believe she has a problem.
- Can an intervention help both parties?
23-year old Caylee had an upbringing that made her especially susceptible to addiction. Her mother, Christy was never satisfied with her accomplishments. Teaching Caylee to count calories at an early age was clearly not advisable. Today, Caylee is a college drop-out, hooked on heroin, bulimic, and incredibly manipulative to those around her. An intervention may be her only hope.
This intervention is not for Caylee alone. Christy is a bulimic. Sexually-abused as a child, she is under the misconception that she has managed her life well. While the intervention is mainly for Caylee, Chrsity's problems cannot be ignored. Can mother and daughter both find help? INTERVENTION guides a family through the process that may bring both mother and daughter some peace.


text:
WC Wellness
Wellness has become an essential aspect to improve the quality of life in our society. College serves as an important lifetime foundation and experience for individuals.
Wellness services and programs offered during the college experience can help create healthy lifelong behaviors including eating well, regular exercise, and emotional and spiritual growth.
Wilmington College believes that every person is first and foremost a spiritual being, that the active pursuit of truth is a life-long vocation, and that the development of a strong, personal moral code is equally as important as the development of intellectual skills and knowledge. Spirit, mind and body make up the three components of a person's essential unity. Each of these is a necessary and eternal part of man. Students are encouraged and expected to develop a high degree of self-discipline and personal restraint and an active moral compass for their lives.
Wilmington College envisions and supports a community of students, faculty and staff engaged in regular and ongoing activities and educational programs promoting health, fitness and wellness for the mind, body and Spirit.
Wilmington College Wellness Program seeks to provide the College community of students, faculty and staff wellness programs and associated activities to educate, promote, develop and enhance healthy life choices, behaviors and activities.
Wellness and Health Promotions Committee (WHPC)
It is the mission of the WHPC to provide the College Community of students, faculty, and staff wellness programs and associated activities to educate, promote, develop, and enhance healthy life choices, behaviors and activities. WHPC recognizes that individual wellness consists of the essential unity of Mind, Body and Spirit.
Pyle Fitness Center
The Wilmington College Fitness Center is located in Pyle downstairs in The Underground.
The Fitness Center is open from 7 a.m.-Midnight Monday-Sunday. (Summer and Break hours may vary)
We ask you to please sign-in upon arrival at the counter. The Fitness Center also has weekly activities scheduled featuring:
Yoga - Monday-Friday at 6:00 PM
All pool and ping pong equipment are located in the Fitness Center. We ask you to please return any equipment used after you are finished.
For photos of the fitness center please check out our gallery on the side bar to the left.
The Wilmington College Wellness Program covers all aspects of Total Wellness, mentally, physically, spiritually, etc. Below various links and resources related to Total Wellness.
Student Health 101: http://readsh101.com/wilmington.html
Heart Awareness- http://www.americanheart.org/presenter.jhtml?identifier=1200000
Diabetes Awareness-www.diabetes.org/
Wilmington College's H1N1 virus information- wchome.wilmington.edu/cgi-bin/WCreader.cgi
Cancer Awareness- www.cancer.gov/cancertopics/types/breast
Smokers Anonymous - http://www.recovery.org/topics/about-the-smokers-anonymous-12-step-recovery-program/
Wilmington College Guest Speaker Dawn Weatherwax's nutrition page- www.sn2g.com/index.php
The 2013-2014 WHPC consists of:
Student Director of WHPC--- Lauren Strickland
Event/Program Coordinator--- Kirstin Woodruff
Late Night at the YMCA and Fitness Center Student Manager--- Spencer Robles
Faculty/Staff Wellness Representative
Intramural director
Director of Greek Life and Wellness Programs
Bud Lewis, ext. 341
Wilmington College Wellness Disclaimer