Open danielmarschall opened 2 months ago
I would suggest to add the changes step by step so we do not have great breaking change. By developing in an API driven way, you do not have to change the OIDplus branding or class names or so, as the UI can be designed by several OIDplus-API using SDKs/Softwares? E.g. Although there can be "Core Modules"/Plugins developed by you/me/the OIDplus core team..., which may be available by default? E:g. for CMS/contact form, RDAP (coming by me), and the plugins existing already...!?
A VERY far milestone/idea I had for some time:
With OID+ we have a very nice system with a flexible UI, a treeview on the left side, public page plugins, a goto box on the top right, languages, and much more. Wouldn't it be great if completely different applications use the same interface and technology? For example, you could even create a CRM or ERP software by re-using the OID+ interface!
But this would be a very hard task, so it is in the far far future, or might be scrapped.
includes/classes/
as well as the PHP files in the base directory) and find out what has to do with OIDs / Objects / RAs, and try to encapsulate them into the publicPage plugin "000_objects, 001_ra" or something.raPages
oradminPages
, since they are dependant on the concept of OID+. The only real page plugin ispublicPages
. Remember,raPages
andadminPages
are called by the publicPage "Login". So, if you remove the Login-Plugin, then you also loseraPages
andadminPages
, so the core should not require them.