My latest crazy idea - the admin
Owen Winkler
of the Habari admin, but it's looking pretty snazzy - not much
changing graphically, but a bit more organized. I assume that the
organization is due in part to Blueprint CSS
(http://code.google.com/p/blueprintcss/) although Chris didn't make
any specific mention of it.
This got me thinking... Imagine this...
Say we create a single admin template page. In that page, we output
just the basic header/menu and footer, and in between we call
something like Layout::out('admin').
The Layout class could be something like the Stack class (or maybe we
just augment the Stack class). What you'd do is something like this:
...
$drafts= Posts::get('status'=>'draft'); // Put array of drafts into $draft
Layout::add(
'admin', // The layout to add a new component to
'drafts', // The name of this component
'drafts_component.php', // The component PHP file
array($drafts), // The data to pass to this component
14 // column span
);
$this->display('index.php); // Display the admin template
...
// In the admin template between the header and the footer:
Layout::out('admin');
...
Mind you, I haven't thought out this syntax completely yet. But the
idea is that we'd create all of the data that the template would
display (just like we do for the templated public blog pages), and
then add a component (read: "specialized admin template") to the
Layout/Stack that would output that data. (Another thought is that we
have a lot of places that display data in the same way. If we create
generic components to do that, we could reuse that component template
for both "drafts" and "recent posts", for example, saving coding
time.)
A combination of parameters supplied to the Layout::add() method and
the component itself would determine how the layout actually appears
on the page, using Blueprint-like containers, columns, and spans.
The idea is that every discrete component of the page becomes
modifiable by plugins. You can change which component is used to
display data (allowing you to customize data output), whether a
component is used at all (easily removing features that users without
permissions shouldn't see), and add new components that display your
own data. It would also allow you to change the layout of any admin
page by rearranging the components/containers in the Layout class.
This plugin syntax could possibly work like:
...
function action_display_component( $component )
{
if($component->layout == 'admin' && $component->name == 'drafts') {
if(!User::identify()->can('view_drafts')) {
$component->template = 'my_drafts_template.php';
}
}
}
function action_display_layout( $layout )
{
if($layout->name == 'admin') {
$layout->add(...); // add some custom components to the admin.
}
}
...
This should work for every page in the admin, for all content that the
admin displays.
A similar feature would be useful for general public template display,
assuming you wanted to build a theme that way. I think such an option
might be appealing. A theme could come with a number of components
and a basic frame in which they can all be rendered. Choose the
pieces you want to output exactly what you need. Eventually, an
interface could be built to allow you to reorganize the components on
the page without altering code. That would be something to see!
The immediate benefits of working out something like this are that we
would move the data access and operation back into the handler, rather
than having everything in the admin templates themselves. Also, being
componentized, these things should reasonably allow for style/skin
changes in the admin. Plus, the plugin benefits that I described
above would be very beneficial, and would allow more extensive
customization than simply sprinkling plugin hooks throughout a series
of templates.
We could also create a user-space override for components, so that you
could drop in your own components (just like for classes) to override
existing core components. This would make it very easy to build an
entirely new admin look/layout without having to touch core code.
Even if we don't implement all of the above, this alone would be
beneficial.
All of this is probably not a small task, but one having some concrete
benefits. I think it's possible to move in this direction without
having to convert the entire admin at once, so it could be something
we migrate slowly.
Anyone think this is a worthwhile project to pursue?
Owen
Andrew da Silva
Where are the admin snapshots from Chris, I must have missed that e-mail...
Chris J. Davis
Andrew da Silva
Chris J. Davis
Root
Can anyone please point them out for us? TY.
Chris J. Davis
the dashboard. I just wanted to make sure that no one got their
hopes up :)
http://www.chrisjdavis.org/user/images/new-dash.png