- add_user_to_group and remove_user_from_group should take Group_Definition instances
to be consistent
- add_user_to_group and remove_user_from_group in drivers/IdentityProvider.php should
not be static
Bagging the User_Definition and Group_Definition abstract classes and replacing them with interfaces with the same names.
Make sure all the unit tests work.
Create an Identity library that defines the interface the Gallery3 expects
Move the user and group helpers into the gallery module to provide the familiar
interface into the Identity library.
Create a Gallery Identity back-end that is supplied by the user module.
The vision here is that all user and group code that is gallery or ui specific
is contained within the core product. Anything that relates to manipulating a
user or group is contained in the back end code that can be replaced.
related events from within the model handling code. The only
exception to this currently is item_created which is challenging
because we have to save the item using ORM_MPTT::add_to_parent()
before the object itself is fully set up. When we get that down to
one call to save() we can publish that event from within the model
also.
File_Structure_Test to make sure we don't regress.
According to the PHP docs, the "public" keyword is implied on static
functions, so remove it. Also, require private static functions to
start with an _.
http://php.net/manual/en/language.oop5.visibility.php
OLD:
$form->submit("Foo") --> <input type="submit" value="Foo">
New:
$form->submit("foo_button")->("Foo") --> <input type="submit" name="foo_button" value="Foo">
Mostly we don't care what the button is so we leave the name blank.
- And refactor printf to our string interpolation / pluralization syntax
- Also, a slight change to the translations_incomings table, using binary(16) instead of char(32) as message key.
communicate. Almost all controllers now use JSON to speak to the
theme when we're dealing with form processing. This means tht we only
send the form back and forth, but we use a JSON protocol to tell the
browser success/error status as well as the location of any newly
created resources, or where the browser should redirect the user.
Lots of small changes:
1) Admin -> Edit Profile is gone. Instead I fixed the "Modify Profile" link
in the top right corner to be a modal dialog
2) We use json_encode everywhere. No more Atom/XML for now. We can bring those
back later, though. For now there's a lot of code duplication but that'll be
easy to clean up.
3) REST_Controller is no longer abstract. All methods its subclasses should create
throw exceptions, which means that subclasses don't have to implement stubs for
those methods.
4) New pattern: helper method get_add_form calls take an Item_Model,
not an id since we have to load the Item_Model in the controller
anyway to check permissions.
5) User/Groups REST resources are separate from User/Group in the site
admin. They do different things, we should avoid confusing overlap.
