| Age | Commit message (Collapse) | Author |
|---|
|
in order to follow the convention that controllers that refer to a collection of resources have plural names.
* Added a bug workaround to routes.php
|
|
refer to collections should now have plural names and there should be only one controller per resource. Updated existing classes that implement REST_Controller. The routing now works like this:
GET /controller -> controller::_index()
POST /controller -> controller::_create()
GET /controller/id -> controller::_show()
PUT /controller/id -> controller::_update()
DELETE /controller/id -> controller::_delete()
GET /form/edit/controller/resource_id -> controller::_form()
GET /form/add/controller/data -> controller::_form()
|
|
XML to the comment controllers as a proof of concept. It's not fully
baked; we should examine ways to create helpers to make this process
easier.
|
|
print it out.
|
|
1) Changed the way that we get forms. Now, if you want to get a form
for a REST resource you prefix /form to the resource id. So:
/form/photo/1 : returns a form for editing photo id 1
/form/comments/1 : returns a form for adding a comment to photo id 1
/form/comment/1 : returns a form for editing comment id 1
2) Changed the comment module to have two controllers:
comment: deals with a single comment resource
comments: deal with collections of comments attached to an item
Related stuff:
- Moved the comments js into the theme
- Reworked Comment_Helper for clarity
- Moved form generation code down into Comment_Helper
- Cleaned up routes (eliminating new comment ones added in recent rev)
- Added form() function to all REST controllers
- Changed comment module to use a block instead of an arbitrary helper call from the theme
- Comment controller only returns HTML currently, but returns a 201 Created status
code when a new comment is added, which the Ajax code can catch and act upon.
- Got rid of a lot of extra views in comment module
|
|
variable; change the header so it links to the user controllers; and add the user controllers which don't do anything.
|
|
_put(), _delete().
This should make it more obvious that these are not your typical
routes, simplifies overall routing by removing a rule and removes the
possibility of accidentally leaking information if we route to one of
them by accident.
|
|
controllers. Any controller that wants to act RESTful can extend this
class and implement get/post/put/delete.
Tweak default routes to disallow direct access to the REST controller
and direct access to any REST methods.
|
|
|
|
do anything else. Just got tire of my changes being clobbered :-)
|
|
Create Item_Controller as a common superclass for Album_Controller and
Photo_Controller. Change routes to route requests to Item_Controller
for dispatching, which in turn will generate get/post/put/delete
requests to the controlller so that each controller has a RESTful
surface.
Change in_place editing to take advantage of this.
|
|
|
|
?> to your theme file and you get a well formed pager. Themes can
customize this any way they want. A version that matches the mockup
is provided in the default theme.
|
|
|
|
Implement a real breadcrumb.
|
|
sidebar.html.php file loops over $theme->blocks() which in turn calls
carousel::block() which uses the Block object to create a standard
block UI. Hooray!
|
|
|
|
the controller initiates a request to a top level page (eg:
album.html.php) which is then free to include whatever other page
chunks it wants with calls like <?= $theme->display('header.html') ?>
Variables like $item and $children are in the global space for all
views.
theme.php helper is now Theme.php library which lets us store the name
of the theme inside the variable itself. This means that the theme
does not have to know its own name because you can use $theme->url()
for all urls to stuff inside the theme itself, which makes it possible
to cline a theme without changing a single line.
Still using the mock album UI.
|
|
route
and add a link to it from the welcome page.
|
