14:50 And we're done. I'm up now, so can't continue blogging :) Leave a comment if you want to see more like this.
14:50 Susan Ottwell highlighting how awesome Revolution is because it lets you override basically anything, without meddling what's already there.
14:48 Breaking: Bert doesn't like MIGXdb.
14:48 Google is useful.
14:47 Most of the examples can be found in the Extending modUser document in the RTFM.
14:46 Why choose MODX? Interesting question at a MODXpo... ;)
14:46 Changing the table later is possible with modManager using addField/alterField methods. You don't lose data when the model changes but you do need to update the table.
14:44 Great question from Susan; why not extend modUserProfile? Could do that, but in this case just extending modUser seems to be fine.
14:43 Using the User extended fields doesn't work when you need to search through the data, as it's stored as JSON.
14:41 Bert claims he can't access the ExtJS files from here, but I think he just doesn't want to show it :P
14:40 To add the tabs to the user edit screen, a plugin is used that triggers on the OnUserFormPrerender event. It also triggers on the OnUserFormSave event which seems to do stuff for licenses. People want to see all code now!
14:39 Several people are mocking the usage of ExtJS. Can't blame 'm. :D
14:38 There's also another component that lists all the users and their licenses.
14:37 Now we're seeing the manager page for the extended modUser that Bert uses for SimpleCart. It has a new tab that Bert added using ExtJS, which shows the API Keys (licenses) for users.
14:35 With extending modUser we're not calling
$modx->addPackage; instead we are only adding the extension package (using
$modx->addExtensionPackage()) as that will make sure the package is loaded on every request.
14:34 Someone in the crowd recommends checking out MIGXdb to easily build from the schema.
14:33 The build script is run once to generate the models from the schema. The same as regular component development. The build script can be found in the RTFM. See here.
14:32 And that's a wrap! Time for questions.
14:32 We're indeed seeing that the fullname method works. We can still use the xPDO getOne method to get related objects, in this case the dateProfile object is huge!
14:31 Login not working! Okay, it did work the second time :)
14:30 Some clarification based on a question, the first and lastname are stored in the dateProfile object related to the dateUser. So this is stored separately (in the dateProfile table) from the core modUser (modx_users) table.
14:29 Unsurprisingly, the getFullname method gets the dateProfile object, and adds the first and last name together.
14:28 Back to the model to show the getFullname method. Bug spotted! The getFullname method uses the core xPDO methods such as xPDOObject->getOne to load related models.
14:27 We're now looking at an example snippet that checks if the user is logged in (using the hasSessionContext setting) and if so, it returns the fullname from the getFullname method, that was added to the custom user model.
14:26 Question from the audience, is it possible to set a default class key? Answer: not in the manager, but in the frontend using the Register snippet you can set a property to make sure new users are created with that class.
14:25 Of course all normal functionality and methods are available too.
14:24 MODX loaded. We're now seeing the class key is different, but everything else is the same as regular users. Awesome! When the user logs in it will use the custom model (dateUser), so you can access everything as normal (core) user methods.
14:24 Using the normal Login snippet you can login in the frontend of the site with an extended user. We're now waiting for MODX to load...
14:23 Bert explained how using custom methods on the extended modUser object can help keep things organised.
14:22 It's important to add the extended user as an Extension Package using the addExtensionPackage method on the modX object. This is also discussed in the Extending modUser documentation.
14:20 As with normal component development, you'll need to build the model out of the schema. A script for that is available from the RTFM, this one to be exact.
14:19 The manager pages for editing users does not change by using a custom modUser object. You can of course add custom manager pages for editing that.
14:19 Because the relation is composite, there is no need to manually remove the dateProfile objects after removing the dateUser. Aint xPDO awesome? :D
14:18 We're now looking at the schema file which shows a relation between the dateUser (an extended modUser) and a dateProfile which contains the extra data.
14:16 For component developers, the model and schema files are exactly the same as what they're used to.
14:14 Bert is talking about a dating site he built that had specific requirements to the user, such as encryption.
14:12 Bert is explaining the general modUser setup as it is in the core. This contains the modUserProfile (name, address etc), modUserGroup (permissions) and a number of useful methods such as isMember, hasSessionContext and isAUthenticated, generatePassword, sendEmail. Other useful data includes user settings, messages and profile data.
14:11 Bert Oost will be talking about extending modUser today.