As I see it, there have historically been several barriers to entry for using the Zoop Framework:

• Zoop has poor documentation
• First time setup is hard (dependencies, etc)
• Zoop has an overly complex skeleton app

So how can we fix this?

Documentation

We've come a long way. Most new code has adequate inline documentation. Unfortunately the Users Manual and From A to Zoop haven't kept up. We could definitely step up the pace here.

Complicated setup, initial launch

I've removed any unnecessary core dependencies from the Lunar branch. XML-RPC is now only required if it's actually used. This means there are currently no core PEAR library dependencies in Lunar. This is awesome.

Components used to declare dependencies if there was a remote possibility that they would use another component. I've reordered configuration load in Lunar, so component and app configuration is available in the component constructor. This allows components like Formz or Auth to conditionally require components depending on the current configuration. This also helps to reduce core dependencies: A skeleton app currently requires: core, spyc, app, session, validate, gui, convert, and zone.

This can be optimized further. Components can now be added at any point in the runtime, allowing lazier loading and catering to more specific needs. For example, the Validate component might be required only when a GuiControl is created, or the Convert component might only be added when using a controller output format other than HTML.

Lunar has also learned some new tricks. It has a 'check environment' phase in which components ensure that files, classes and folders exist, and are writable as required. Components can add tests and display simple errors to the user, allowing them to quickly identify and fix environment problems. This is a vast improvement over the backtraces and confusing notices generated by trying to write to a folder that doesn't exist.

Environment checking results are cached once they return success, so, for example, the Gui component doesn't have to try to create compile and cache directories on every page load. While a small improvement, this is performance improvement nonetheless.

Overly complex skeleton app

I propose branching the skeleton into two apps. First, a skeleton, which is exactly that: a barebones skeleton. To fill the need for sample code and something fun to play with, we should add a 'noob' app. I see this app including a zone or page for each cool Zoop feature, with some easily accessible examples and clearly documented code. This is for the first time user, and should work without much configuration.

The Lunar branch of the skeleton app has been pared down to the essentials. It now consists only of a default zone, a zone template file, three basic templates (header, footer, welcome), and required theme resources.

The app directory structure has been simplified in Lunar as well. Zones are now located in a zones directory, and can be organized hierarchically rather than by throwing the entire url into the filename. So instead of:

app/zone_default.php
app/zone_admin.php
app/zone_admin_users.php
app/zone_admin_groups.php

we have:

app/zones/default.php
app/zones/admin.php
app/zones/admin/users.php
app/zones/admin/groups.php

The zones directory in the app corresponds to the controllers, and directories have been added for model and view as well. GuiControls and templates hang out in subfolders of view, for example. The directory structure is more hierarchical, rather than flat as it was in the past. This makes it easier to grok at a glance.

Thoughts?