| Age | Commit message (Collapse) | Author |
|---|
|
Kohana makes this type of transition fairly straightforward in that
all controllers/helpers/etc are still located in the cascading
filesystem without any extra effort, except that I've temporarily
added a hack to force modules/gallery into the module path.
Rename what's left of "core" to be "application" so that it conforms
more closely to the Kohana standard (basically, just
application/config/config.php which is the minimal thing that you need
in the application directory)
There's still considerable work left to be done here.
|
|
|
|
|
|
|
|
writable.
|
|
bomb.
|
|
|
|
|
|
|
|
There's no UI to select the locale yet.
|
|
headers to be specified as a parameter. The documents say that it
should be "\r\n". Some sendmail programs seem to violate the
specification and get confused. In these cases the header separator
is just "\n".
This change allows the header separator to be set by the a
configuration parameter.
|
|
|
|
|
|
facility. Something quirky is happening in the first test, see comment
in code, but I couldn't figure it out. Left a @todo for now.
|
|
|
|
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.
|
