Admin Handler redux

[Matt Read]

With the release of 0.6, I'd like to propose a complete overhaul of the
adminhandler, and the entire admin area, code. Right now the entire
thing is a mess of hundrends of methods scattered throughout the
adminhandler class, which each handle different things for different
admin pages. And each page handles things differently form others. I'd
like to standardize the entire thing to provide a common logic for all
the admin pages, and ajaxy stuff, to do things.

A while back I started the "adminhandler branch" which became impossible
to keep in sync with trunk due to the number of changes made. I'd like
to propose something similar to what I started there.

Each page of the admin (eg, dashboard, posts, post, comments, etc.) will
be handled by it's own "AdminPage" class, a child of the parent
AdminPage. When an admin page is requested, the associated AdminPage
class is instantiated, and the appropriate method, based on the "action"
and "request_method" is called. eg. When dashboard is requested using
the GET method, AdminPageDashboard is instantiated and the act_get()
method is called. When the addModule ajax action is called via POST, the
act_ajax_addModule_post() method is called.

I'd like to further extend this to a more REST/CRUD type system. So make
a POST or PUT request to /post would CREATE a new post. PUT request
to /post/$id would UPDATE given post, DELETE would delete. Basically,
allowing us to tie the admin system closer to the ACL CRUD system. (I
believe browsers will allow us to submit forms with action="DELETE|
PUT".)

A small table of HTTP -> CRUD:

HTTP | CRUD
-------+---------
POST | Create
GET | Read
PUT | Update, Create
DELETE | Delete

Originally what I did was to default to act_request_$method() instead of
just act_$method(), which was confusing. Also I put all the adminpage
classes in system/admin/classes which is confusing since the admin
folder is the "View" folder. I would also rename class as
"AdminPage{$page}" instead of "{$page}AdminPage".

For the basics of what I started, please see the following:

Parent AdminPage:
https://trac.habariproject.org/habari/browser/branches/adminhandler/htdocs/system/admin/classes/adminpage.php

AdminHandler:
https://trac.habariproject.org/habari/browser/branches/adminhandler/htdocs/system/classes/adminhandler.php

and an example AdminPageDashboard:
https://trac.habariproject.org/habari/browser/branches/adminhandler/htdocs/system/admin/classes/dashboardadminpage.php

I would also like to see a standardized way for ajax methods to return
information. See bug #898.

Also a common API to the "itemManage" JS library, which most pages could
use (posts, comments, logs, plugins, themes). Providing a "grid like"
approach to populating the lists. Allowing for adding/removing rows,
headings, columns, etc., and changing the "view style"/template used for
displaying each object. Also allowing for easier integration with ACL
and adding/removing actions in the "dropbutton" thing.

I'd like to hear some other ideas anyone has, and try to make a written
standard of our admin system, before we start cannibalizing things. I've
kinda started a _very_, _very_ rough "sketch of ideas" (haven't had much
time recently to improve it) on my wiki page. Please feel free to add
anything.

http://wiki.habariproject.org/en/User:MattRead/adminhandler
http://wiki.habariproject.org/en/User:MattRead/adminhandler#Item_Manage

I would also like to note, that in order to implement such massive
changes it would require a "freeze" on adminhandler changes, until we
can get everything moved over to the new system (whatever it is we come
up with). (unless SVN is truly magical, and can merge something like
that).

[Caius Durling]

On 6 Apr 2009, at 21:36, Matt Read wrote:

(I
believe browsers will allow us to submit forms with action="DELETE|
PUT".)

If they don't you could hack around it by setting a hidden form field _method to either "delete" or "put". This is how rails handles browsers not sending delete/put correctly.

C

---

Caius Durling

ca...@caius.name

+44 (0) 7960 268 100

http://caius.name/

[Chris Meller]

I haven't looked at your branch in depth, but I still love the idea of splitting out each page into its own class.

I'm somewhat less attached to the HTTP -> CRUD idea. It would definitely depend upon how the implementation panned out in regards to browser support.

So when can you have it done? :)

[Caius Durling]

On 6 Apr 2009, at 21:43, Chris Meller wrote:

I'm somewhat less attached to the HTTP -> CRUD idea. It would definitely depend upon how the implementation panned out in regards to browser support.

I'm fully in favour of this, but I build any app I touch using this mindset so I'm quite biased to that way of thinking.

<keyword-junkie>RESTful CRUD FTMFW</keyword-junkie>

[Geoffrey Sneddon]

On 6 Apr 2009, at 21:36, Matt Read wrote:

> I'd like to further extend this to a more REST/CRUD type system. So
> make
> a POST or PUT request to /post would CREATE a new post. PUT request
> to /post/$id would UPDATE given post, DELETE would delete. Basically,
> allowing us to tie the admin system closer to the ACL CRUD system. (I
> believe browsers will allow us to submit forms with action="DELETE|
> PUT".)

I'd follow APP's (Atom Publishing Protocol) example for consistency's
sake. (Quite what APP does I don't know.) I also presume you mean
@method and not @action. My understanding is that browsers allow GET,
POST, PUT, and DELETE (these are matched case-insensitively, but
should probably be given in uppercase for consistency with HTTP
itself) and map anything else to GET.

--
Geoffrey Sneddon
<http://gsnedders.com/>

[Owen Winkler]

On Mon, Apr 6, 2009 at 4:54 PM, Geoffrey Sneddon
<fooli...@googlemail.com> wrote:
>
> I'd follow APP's (Atom Publishing Protocol) example for consistency's
> sake. (Quite what APP does I don't know.) I also presume you mean
> @method and not @action. My understanding is that browsers allow GET,
> POST, PUT, and DELETE (these are matched case-insensitively, but
> should probably be given in uppercase for consistency with HTTP
> itself) and map anything else to GET.

Is there a reference that confirms that all of these verbs work in all
browsers we intend to support in our admin?

Owen

[Arthus Erea]

I strongly support these changes.

Adminhandler.php, as it stands, is an unholy beast which we must slay.

I would recommend that we create some sort of standardized "AJAX"
class in both PHP *and* JS. The PHP AJAX class would be called by
AdminPages (and possible ItemManage). The JS class would handle
interpreting errors, executing data, etc.

I would caution that we shouldn't limit the AJAX class to *only* HTML.
You should also be able to map a "success" function which would
receive data (not necessarily html) and process it. Ex.

{
notice: ['Notice number one','Notice nubmer two'],
error: ['Error number one', 'Error number two'],
data: {
name: "james"
}
}

$.habariAjax(habari.url.ajaxWhatever, values, success: function(data)
{ alert(data.name); } );

In regards to the CRUD aspect, I'm not an expert. However, it does
seem a little complicated and constraining to me. I'd have to see an
actual implementation before I'm convinced. Maybe we'd be better off
starting by transferring everything into classes, then pursuing such
alternate plans. Consider me skeptical but open to persuasion.

I'm still a little fuzzy about the ItemManage class, but it does seem
like a good idea. We were trying to do something like this with the
JS, but standardization (of html) would definitely help. However, I
don't think we need to *require* that every itemset has all the html
sections. Not all sections make sense for all of them.

Instead, there should be a customizable addition list. We'd
*standardize* the types (just like FormUI), but not require that every
itemset has all of them. In fact, there might also be some ability to
define where the values *come from* (it'll be different for different
objects). Ex.

$items->add_sections(array(
'title' => 'title',
'description' => 'content'
));

In that case, it'd only display the "title" and "description" fields.
These would be populated according to the passed source. Ex. $object-
>{$source}. We'd also include some defaults, so you could do
something like this:

$items->add_sections(array('title', 'description'));

Ideally, all of this would also be extendable by plugins, in a similar
way to FormUI. The $items class would simply be passed to an action
before given to the theme.

Here's some hooks I'd like to include:

$items->remove_sections();
$items->add_sections(array($name => $source)); // Allow sections to be
remapped in this way as well, as above
$items->move_section_after($name, $preceding);
$items->move_section_before($name, $proceeding);

I'd be willing to help out in whatever capacity I can (especially the
JS), but I've been less involved of late. I'm also not sure certain
people want my code touching any of this.

~Arthus

[Blake Johnson]

On Apr 6, 4:43 pm, Chris Meller <ch...@doesnthaveone.com> wrote:
> I haven't looked at your branch in depth, but I still love the idea of
> splitting out each page into its own class.
>
> I'm somewhat less attached to the HTTP -> CRUD idea. It would definitely
> depend upon how the implementation panned out in regards to browser support.
>

Like Chris, I am very much in favor of splitting the adminhandler
class into subsections.

I am a little more confused about your HTTP->CRUD proposal. What
exactly does your HTTP to CRUD mapping buy us?

The admin JS is also a bit of a mess. I understand the desire for an
itemManage API, but even before that I'd like to see a little general
clean-up. For instance, we should be using descriptive CSS class-hooks
to generate behavior rather than lists of CSS IDs (eg. add a
"draggable" class to relevant HTML entities rather than list the IDs
of every entity we want to be draggable). Also, we use the jQuery
library, but otherwise we use a very non-jQuery-like JS style. I don't
have a concrete suggestion yet for how to fix this, but I just picked
up John Resig's "Pro Javascript Techniques" a couple weeks ago, so you
will probably be hearing more from me on this topic as I make my way
through the book.

--Blake

[Michael Harris]

2009/4/7 Matt Read <matt....@gmail.com>:

>
> With the release of 0.6, I'd like to propose a complete overhaul of the
> adminhandler, and the entire admin area, code. Right now the entire
> thing is a mess of hundrends of methods scattered throughout the
> adminhandler class, which each handle different things for different
> admin pages. And each page handles things differently form others. I'd
> like to standardize the entire thing to provide a common logic for all
> the admin pages, and ajaxy stuff, to do things.

I'm definitely in favour of cleaning up the admin handler.

[snip]

> Parent AdminPage:
> https://trac.habariproject.org/habari/browser/branches/adminhandler/htdocs/system/admin/classes/adminpage.php
>
> AdminHandler:
> https://trac.habariproject.org/habari/browser/branches/adminhandler/htdocs/system/classes/adminhandler.php
>
> and an example AdminPageDashboard:
> https://trac.habariproject.org/habari/browser/branches/adminhandler/htdocs/system/admin/classes/dashboardadminpage.php

It may be that other handlers become similarly monolithic in the
future. I think putting things in /admin may lose us flexibility and
cause problems in the future. What about moving the handlers to
/system/handlers/{admin,user,atom,etc}.php, and have handler-specific
things in a subdirectory, /system/handlers/admin/dashboard.php, for
example ?

--
Michael C. Harris, School of CS&IT, RMIT University
http://twofishcreative.com/michael/blog
IRC: michaeltwofish #habari

[Chris Meller]

On Tue, Apr 7, 2009 at 4:28 AM, Michael Harris <michael...@gmail.com> wrote:

<snip>

> Parent AdminPage:
> https://trac.habariproject.org/habari/browser/branches/adminhandler/htdocs/system/admin/classes/adminpage.php
>
> AdminHandler:
> https://trac.habariproject.org/habari/browser/branches/adminhandler/htdocs/system/classes/adminhandler.php
>
> and an example AdminPageDashboard:
> https://trac.habariproject.org/habari/browser/branches/adminhandler/htdocs/system/admin/classes/dashboardadminpage.php

It may be that other handlers become similarly monolithic in the
future. I think putting things in /admin may lose us flexibility and
cause problems in the future. What about moving the handlers to
/system/handlers/{admin,user,atom,etc}.php, and have handler-specific
things in a subdirectory, /system/handlers/admin/dashboard.php, for
example ?

I also like the idea of moving handlers and their sub-items out of the generic classes directory, regardless of what the eventual structure is. They're more like controllers than libraries, so it's never made much sense to have them lumped all together, it was just easy.

[Chris Meller]

On Mon, Apr 6, 2009 at 7:01 PM, Blake Johnson <blakejo...@gmail.com> wrote:

On Apr 6, 4:43 pm, Chris Meller <ch...@doesnthaveone.com> wrote:
> I haven't looked at your branch in depth, but I still love the idea of
> splitting out each page into its own class.
>
> I'm somewhat less attached to the HTTP -> CRUD idea. It would definitely
> depend upon how the implementation panned out in regards to browser support.
>

Like Chris, I am very much in favor of splitting the adminhandler
class into subsections.

I am a little more confused about your HTTP->CRUD proposal. What
exactly does your HTTP to CRUD mapping buy us?

The admin JS is also a bit of a mess. I understand the desire for an
itemManage API, but even before that I'd like to see a little general
clean-up. For instance, we should be using descriptive CSS class-hooks
to generate behavior rather than lists of CSS IDs (eg. add a
"draggable" class to relevant HTML entities rather than list the IDs
of every entity we want to be draggable).

Agreed.
 

Also, we use the jQuery
library, but otherwise we use a very non-jQuery-like JS style.

Some of the things we do could probably be wrapped up into jQuery plugins (so they extend $()) and can just be dropped on pages to do what they're supposed to do (by parsing out anything with a certain CSS class, for example), but a lot of it probably shouldn't. There's some good OOP JavaScript in there, it just needs to be modularized a lot like adminhandler...

[Owen Winkler]

Chris Meller wrote:
>
> I also like the idea of moving handlers and their sub-items out of the
> generic classes directory, regardless of what the eventual structure is.
> They're more like controllers than libraries, so it's never made much
> sense to have them lumped all together, it was just easy.

This change seems to mesh well with implementing SPL autoload and the
bootstrap stuff we were talking about on IRC.

For those not present, we were discussing how it would be nice if you
could include the Habari system without it actually processing the output.

A potential solution is to create a system/bootstrap directory in which
a series of purpose-related modules could include their components.
Example components include running the installer, initializing the
database, and loading plugins.

The index.php file would be reduced to a series of includes that pull
from that bootstrap directory. Other applications could create their
own index.php-like files that include only the desired components of
Habari by including just those bootstrap files. This would make it
easier to, for example, embed Habari functionality within some other
page or application.

SPL autoload would simply use the SPL autoload features directly insteda
of implying them like we do now. It would also need to be augmented to
support loading handlers from a different place than class libraries.

Owen

[Chris J. Davis]

I really like this current line of thinking.

And hopefully my job situation will be much more time friendly
starting in May so I can actually help out with some of this. WooHoo!
to no more 7 days a week/21 hours a day work schedules!

Chris

[Geoffrey Sneddon]

I couldn't find a reference, and I was going to check myself that they
do. However, Anne van Kesteren said they did, so hopefully he's right.

[Caius Durling]

I was under the impression that it wasn't supported in all the major browsers, hence rails using a hidden field called _method to make it work across browsers that don't support the actual verbs.