random::hash()
random::string()
random::percent()
random::int()
So that we don't have lots of different ways to get random values all
over the code. Follow-on to #1527.
see if we're deleting the album we're inside in quick::delete. If we
delete the album we're currently viewing, redirect to the parent.
This fixes ticket #1185.
the end which triggers .gallery_show_loading(). Not a complete fix
for #817 but it's a start and it takes care of one place where we have
a long running process.
item::move(source, target) helper when the parent member has changed.
Using the move method insures that names and slugs that could conflict
in the target album are resolved properly. Changed the item::move
method so it returns a message to be displayed if the caller chooses.
And changed the move controller to display the message returned by the
move if the item name was renamed as part of the move."
Rolling this back for a couple of reasons:
1) Bug in move.php ("message.info" is not a function name)
2) Having the message come back from the API call as a side-effect is
sloppy. We should find a cleaner way to do this checking.
3) having item::move() call save() on any changed values in the ORM
is counter-intuitive. Move should move, save should save.
I think the right approach here is to roll the move() code properly into
save().
This reverts commit 2492280cc0.
method, which encapsulates saving an item and handling name and slug
conflicts. Call this instead of doing a save directly."
Rolled this back because it fails KISS. We already have an API for
saving models with Item_Model::save() that's consistent with all of
our other model code. Adding a new way to save items is confusing and
inconsistent.
This reverts commit 9504f71efc.
1) Don't call ORM_MPTT::move_to() directly. Use the new
model-based-validation approach of changing the parent_id and saving.
2) Item_Model::parent() can return null; check for it.
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.
choosing a random image is essentially a function on an item collection.
Also implemented a bunch of other query filters for item collections.
Created item::random_query() as a way of generating a reasonable
starting point for random queries.
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.
we're not relying on overriding url::site() to do tricks around item
urls. This means that you won't get item urls by doing
url::site("albums/37"), for example, but it also means that we won't
get pretty urls where we don't expect them (like in the action of a
<form> element).
Incidentally, this will help us move over to using the slug format
because if you've got a bad character in a url, the edit forms will
now work on it since they'll be id based.
