| Age | Commit message (Collapse) | Author |
|---|
|
|
|
routing and know whether we're going to an /admin page or a regular
one.
|
|
1) They must all start with "admin_". This pattern is not directly
routable.
2) Their urls must be /admin/xxx.
3) The Admin_Controller will take the xxx and look for Admin_Xxx_Controller
and will delegate to that admin controller, after doing security checks.
Moved the users and dashboard views into individual modules for now.
|
|
|
|
sessions; it encodes all the value into the cookie which means
little/no security, transfer costs, and storage limits.
|
|
to know that we're in test mode.
|
|
|
|
|
|
administation component to the scaffolding Actions tab. The importing functionality will follow shortly.
2) Defines a routining pattern for module administration controllers. URI's of the form admin/module/method/parameters gets remapped into module_admin/method/parameters. This will result in the lookup of the the controller Module_Admin_Controller
|
|
|
|
|
|
directory and make it writable by the server. The location of the temporary upload directory is specified in config/upload.php
|
|
to be added without having to update the config.php file
|
|
to make it work on Windows as well.
|
|
- Port of Ruby's I18n gem (http://rails-i18n.org/)
- Added proper plural handling on top of that.
- Using CLDR 1.6's plural form data
- See I18n_Test for example usage.
- Not integrated into G3 templates yet. Probably adding __() as alias for I18n::instance->translate().
- No specific plan yet where localization files should live.
|
|
|
|
core_block:head method to insert the title into the head section. If the config value is false, the default Browse Photos::$item->title is used. A string value with a trailing '-' will append the config value to $item-title. Otherwise, the page title is set with the supplied value.
|
|
the header_bottom() insertion point.
|
|
supporting Atom as the default input and output format of RESTful controllers. Only the constructs necessary for representing comment feeds and entries have been implemented. Its output are valid Atom 1.0 documents. The test contains examples of how to make feeds and entries.
|
|
* HTTP header setting in comment module now going through REST helper API.
* Fixed items controller test.
* Fixed user installer test.
* Fixed _create() handling in the REST controller.
* Fixed routing for edit and add forms.
* Added some tests for the REST controller.
* Set svn:eol-style to LF on a bunch of files.
* Added preamble to MY_Forge.php.
|
|
(it would fail, but this way they get a 404 instead of another error).
|
|
1) We now use __call() in REST_Controller to handle any requests to a controller
that were not already handled. In the case of RESTful controllers, this should
be the only entry point (although they're free to break the model and add other
ones.. nothing stops them).
This means that we can remove all the catch-all routes in
routes.php which greatly simplifies it.
2) Move request_method() and output_format() out of REST_Controller and into the REST
helper in core/helpers/rest.php
3) Experiment with letting the various subclasses check the output_format and deal with
it themselves. This simplifies the API, but it might be a bad idea in that it might
push too much work to the individual controllers. It's a balancing act, time will tell,
I'm willing to change it back later.
|
|
doesn't refer to a fixed resource or collection of resources.
Fix some minor bugs in the code so that we can actually generate a
feed. It looks pretty cool! Improved pagination links, but didn't actually test them.
|
|
|
|
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
|
|
GET /form/edit/{controller}/{resource_id} -> controller::_form_edit($resource)
GET /form/add/{controller}/{parameters} -> controller::_form_add($parameters)
* Updated comment, user and core modules to reflect the API changes
* Cleaned up routing and handling of requests to /{controller}
|
|
implementation yet
|
|
- Return proper Content-Type header for GET /comments requests
- Got rid of the query processing for index() in REST_Controller()
- Small misc fixes
|
|
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()
|
|
|
|
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
|
|
|
|
_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.
|
|
|
|
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.
|
|
basic install test. There is no interface at the moment to do authentication. It is dependent on the install of the user module.
|
|
|
|
navigation.
|
|
|
|
|
|
screen and you can install and uninstall it. Which creates the tables, defines 2 groups (adminstrator, registered) and one user (admin).
|
|
|
|
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!
|
|
Replace theme HTML with *almost* the latest stuff from the
mockups. (it doesn't include r18467 yet).
Our theme format is now modelled after WordPress / Habari's style
where you have one entry point per type (eg: album.php) which can
load up whatever parts it needs (eg: $theme->display("header"))
Created album and photo helpers which have create() functions
that form the base of our new API, along with tests for them.
Created our own version of the ORM_MPTT since the existing
versions were too buggy and unsupported to depend upon. Only has
a minimal implementation so far, and the tests are not yet
committed.
Added path(), thumbnail_path() and resize_path() to Item_Model
Extended the scaffolding to allow you to add lots of
photos/albums into your hierarchy.
Deleted modules/mptt -- we're not going to use this anymore.
|
|
route
and add a link to it from the welcome page.
|
|
|
|
disable logging if the log dir is not writable.
|
|
|
|
command line mode, and expects to put data into test/var. Create a module
to wrap it that generates a nice text-only view of the output.
|
