1) Move the display context code into the controller themselves so that it's
more logically a continuation callback from the original controller
rendering code.
2) Simplify the display context set/get code and put it in the item helper,
it's just a couple of lines of code now.
3) Add more descriptive breadcrumb strings
Create the concept of a Photo_Display_Context. If the user is browsing a dynamic album (i.e. tags) and chooses to
look at an image in that album. The display of the image happens correctly, but the 'next' and 'previous' buttons
are no longer consistent. When one of these is clicked, Gallery will open the adjacent image in the actuall album,
not the dynamic album.
- Breadcrumb::build_from_item becomes Breadcrumb::array_from_item_parents
- Eliminate Breadcrumb::$id -- it's no longer necessary
- Fold Breadcrumb::generate_show_query_strings into Breadcrumb::array_from_item_parents
- Create Breadcrumb::set_first() and Breadcrumb::set_last()
- Breadcrumb::build_from_list goes away, we just use arrays for this
- Change Search_Controller and Tag_Controller to just create an array
of Breadcrumb instances with the first/last marked appropriately
- Breadcrumb_Test loses a bunch of complexity.
Create a Breadcrumb library which has two static methods for_item (which takes a an item and builds the entire
breadcrumb for the item) or build (which takes a variable number of Breadcrumb elements and creates a breadcrumb
based on the specified elements).
Used tag->url() to build the tag album url. Escaped the query string for the search. Tightened up the breadcrumb code
in page.html.php.
When adding the show query parameter, we can't blindly concatenate using the ? separator. We have to check that we
use a & if a query parameter already exists.
by the following rules:
1) An initial dialog or panel load can take either HTML or JSON, but
the mime type must accurately reflect its payload.
2) dialog form submits can handle a pure HTML response, but the mime
type must also be correct. This properly resolves the problem
where the reauth code gets a JSON response first from the reauth
code, and then an HTML response when you reauth and continue on to
a given form -- try it out with Admin > Settings > Advanced.
3) All JSON replies must set the mime type correctly. The json::reply
convenience function does this for us.
4) By default, any HTML content sent back in the JSON response should be
in the "html" field, no longer the "form" field.
The combination of these allows us to stop doing boilerplate code like
this in our controllers:
// Print our view, JSON encoded
json::reply(array("form" => (string) $view));
instead, controllers can just return HTML, eg:
// Print our view
print $view;
That's much more intuitive for developers.
to a logon page to allow the user to login. Pass the target url as a session
variable to allow the user to be redirected where they want to go if the login
was successful. Fixes ticket #1009.
Item_Model::save(). This makes creating albums similar to editing
them and makes it difficult to create an album poorly. I expect to be
able to remove a lot of code from the photo and movie helper because
it's duplicated here.
In order to do this, I refactored ORM_MPTT::add_to_parent() into
ORM_MPTT::save() so we now add it to the parent when we do save. This
allows us to call save() only once which saves a database call per
add.
The Albums_Controller logic is roughly the same as before.
Haven't updated the tests yet, they're going to fail miserably since
many of them depend on album::create() which is now gone.
now only Albums_Controller::update() supports the pattern. All
form and controller based validation happening when editing an
album has been moved over.
Model based validation means that our REST controllers share the
same validation as web controllers. We'll have consistency
enforced at the model level, which is a Good Thing.
The basic pattern is now:
1) Rules are in the model
2) ORM::validate() (which is called by ORM::save() but you can
call it directly, too) checks the model for all the rules and
throws an ORM_Validation_Exception if there are failures
3) Actions are no longer taken when you call Item_Model::__set().
Instead, they're all queued up and executed when you call
Item_Model::save().
Notes:
- item::validate_xxx() functions are now in Item_Model::
- We still call $form->validate() because the form can have
rules (and forms triggered by events will likely continue to
have rules.
guess how to send the user back. Instead, proxy the originating item
id through the edit forms so that we can tell exactly what page we
were on when we began editing. If we were viewing the item, then
redirect to its new url (in case it changed) to fix ticket #745. But
if we were viewing some other item, then just stay on the current page
to fix#940.
The page_type approach didn't work because you'd have the same
"collection" page_type when doing a context menu edit for an album.
1) Controller::$input is gone -- use Input::instance() now
2) Handle new 'database.<default>.connection.params' parameter
3) Handle new 'cache.<default>.prefix' parameter
1) The new default route is "albums", and Albums_Controller::index() does the right thing
2) Items_Controller redirects to the appropriate specific controller
3) All item controllers now have show() instead of _show(), so that
the routing code in url::parse_url() can get to it. But that code is protected against
receiving bogus requests.
types, and a subtype for specifics. Currently the top level bucket
collection, item, other
Here are the core subtypes so far:
collection: album, search, tag
item: movie, photo
other: login, reset, comment-fragment, comment
It's legal to create new page_subtypes whenever you want. Use the
appropriate page_type to get the coarse grain behavior that you want.
both albums and movies. Kohana's paginator is not quite sufficient
for this, so create our own pagination logic in Theme_View with only
the stuff we need.
Clearly document the variables available in pager.html so that themers
know how to use it.
Fixes ticket #626.
