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).
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at http://groups.google.com/group/habari-dev
-~----------~----~----~----~------~----~------~--~---
