batch::start() before starting a series of events, and batch::stop()
when you're done.
In batch mode, the notification module will store up pending
notifications. When the batch job is complete, it'll send a single
digested email to each user for all of her notifications.
Updated the scaffold and local_import to use this. Haven't modified
SimpleUploader yet.
Starting a batch call batch::operation(name, item). In the case of
adding photos name = add and item is the parent of the new items.
When the operation is finished the batch::end_operation(name) is
called.
operation and end_operation events are called. Handlers
(i.e. item_created) can call batch::in_progress(name) to determine if
a batch is being processed.
start_batch and end_batch add and remove the batch id from the
session. Modules wishing to do batch processing, just need to fire
the start_batch and end_batch events. Other modules that need to be
aware of batches (i.e. notifications) just check the session for "batch_id".
events: start_add_batch and end_add_batch. The parameter is a batch
id which is generated on the first add request. The protocol is call
the add_photo as many times as required and then call finish when
done.
Also renamed the add method in local_import to add_photo so it is
consistent with simple_uploader
idea. Instead convert movies to jpeg before doing any
transformations, which keeps the graphics functions clean and abstract
and dealing solely with image types. Lighter/simpler solution.
2) Protect the fullsize image with a permission check
3) Added a content:encoded element to each item which allows the image to show up in the body of the feed.
* Added new field in items table (path) which is sanitized version of
name.
* Added __set method on Items_module to set the path field whenever
the name field is changed.
* Made some changes to the scaffolding so missing the path column
would not kill the scaffolding.
* Changed MY_url::site so not having a 3rd parameter won't throw an error.
