JApplication::loadSession resets JUser object

[qson]

Hello folks,

I am trying to build a web app using JPlatform. So far I like what I see, but now I got stuck when using JSession and JApplication::loadSession. I am trying to use the JUser object and store it in JSession, but every time I call JApplication::loadSession, the user object is reset. Is it supposed to work that way?

Further, the JUser class is not optimal for my needs, is it possible to override it and make JFactory::getUser use my custom user class?

Thanks in advance

[Donald Gilbert]

You can register you own JUser class using JLoader::register('JUser', JPATH_ROOT . 'path/to/your/class/juser.php');

Put this in your application bootstrap, immediately after the call to JLoader::setup();

For another approach, look at https://github.com/JTracker/jissues. It registers the J prefix to the libraries/tracker folder, and then the autoloader looks in that directory first for all classes that it loads, and then moves on to check the other folders if it can't find them in libraries/tracker.

As for your session/user issue, I don't think it's supposed to work that way. What version of the platform are you using. In the latest version, I am not even seeing the loadSession method in JApplication. Further, JApplication exists in the Legacy tree, are you meaning that you are using JApplicationWeb::loadSession? because I see that exists.

[qson]

Sorry, I meant JApplicationWeb. There was not a problem with loadSession as I thought. I was worried when I saw $session->set('user', new JUser); but that was only in a new session, which is ok.
The problem was bad coding from me. Sorry.

Thanks for the tip about JLoader::register.

[Donald Gilbert]

Great - glad I could help.

[Michael Babker]

As Don said, let the autoloader be your friend.  The order in which the list is defined makes a difference.  In our case with the tracker project, registering our custom libraries first allows us to override any of the classes in the joomla, legacy, and cms trees, allowing us to keep those trees clean with the code straight from the CMS and Platform, but if there are things we do need to override (i.e. The form fields and HTML helpers that were modified in the CMS to work with Bootstrap), we can drop them in the tracker tree and they'll take precedence over the "official" versions.  I personally prefer that over having to register every overridden class in the framework's bootstrap or using the CMS's plugin trick.