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? :) On Mon, Apr 6, 2009 at 4:36 PM, Matt Read <[email protected]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
