wwevo / guildhome

Day to day guild management tool and community hub for Guild Wars 2
0 stars 2 forks source link

Plan: Profile options #26

Closed AniOnGit closed 7 years ago

AniOnGit commented 8 years ago

Make a plan which profile options should be available and how to cover them on database side. ONLY A PLAN, did you hear me??

AniOnGit commented 7 years ago

Okay, listen up, this is the plan:

Additional profile options on profile page:

I can't think of much more right now, anyone else ideas?

Now to the 'how do I save this information' side. If you want it straight and simple: I suggest a new database table 'user_profile' with user_id as PK and one column for each profile option. Done.

If you aim for a highly modular solution where maybe profile options are delivered by several certain modules you could use a model like this: Table profile_option with columns id, name. Table profile_option_value with columns user_id, option_id, value. This would make the data structure as well as the SQL statements a bit more difficult, but I could help with that one if you want to implement it like that. The benefit would be an extensionable profile where any module can hang options/settings in. That would also require overworking the existing profile base I guess, cause you'd need to ask every module around for things that should be included in the profile page/settings.

wwevo commented 7 years ago

Well, as it is now, every module has an opportunity to make a initial call before any logic gets involved. I load the class, execute the init-function and nothing else. This should be the perfect moment to register any menu-items, options or other stuff the module needs to integrate with the website. This would be done at runtime. No interaction with other modules would be possible though, settings would have to be moved to core. I'm not really keen on building a module dependencies manager YET :)

So I'd make the modules call the settings not the other way around.

We also could use the database to do this, I fear though that we'd then need a managed backend where you can set all the stuff up. Which we might need later on anyways... But not sure about now. Maybe for the eol_guildhome_v1.5rehaul_onthe_roadto2.0

AniOnGit commented 7 years ago

I consider this being done as the current implementation is flexible enough to handle any new profile options in a dynamic way.