
Originally Posted by
FragFrog
Do you have any idea just how many open source CMS systems there are out there? And from the looks of it, yours is in no way special (or even looks pretty). So sure, go ahead, make a SourceForge page, open it up, but I really doubt you'll get anyone to pitch in - sad but true. Might as well not bother

You know, I really like that response because that's sort of how I feel. I could release the source, but what's the point? I don't know how many CMS systems there are out there (I've been all over the web looking at 100's).. There's gotta be 1,000's.
It's a great start for people making thier own CMS, and since so many people demand versatile CMS systems here for different servers, I figure it could possibly evolve into a few different systems.
My thinking in the whole thing was around the simplicity of WysGui and it's ability to grow. There's no redundant module API that involves inteligent programmers to learn something more primitive then they. All of the technology is done the same way a normal site is.
Let me explain how modules are implemented in WysGui as opposed to Drupal:
Drupal modules:
WysGui Modules:
(Full Article Here ->
http://www.wysgui.com/tutorials/wysgui_modules.php )
A Module (on WysGui) could be a number of forms or functions that make WysGui work. Every form in WysGui is a module. Everything up to the very Administration panel and File Browsers. Some modules are simple, and some complex. Every WysGui Module, no matter what shape or form, consists of one-to-four things:
Settings:
Initial functions and pre-loaded data needed before anything else on the page is loaded (including mark-up)
Actions:
Functions that commit actions on a file, database, or form request. For example, the action to a login form would check to all of your information and log you in, or display an error message. Actions are loaded after settings, but before any mark-up. (This includes but is not limited to Head Data and Form/Content)
Head Data:
functions, settings, or actions that may use JavaScript or JScript to perform certain tasks. This data resides between the <head> </head> tags. Head Data may also consist of CSS styles and various other things.
Form/Content:
HTML used to create the display of the module. This may be blank for some modules, or it may be the sole purpose of others. Admins can sort this as if it were a regular piece of content in WysGui.
Obviously mine follows a more commonly used approach. Every app on the web can be summarized into these 4 parts. Note that you can include local files in any of these 4 parts. By including your ready-made form application into a WysGui module, you can do anything you can do on a site without a CMS, only WysGui makes it a bit easier to manage it, sort it, and coming soon: simply secure it.
I've looked and looked for a CMS that handles modules this way, after giving up, I made WysGui.
Don't you agree this is a better, more stable approach?