To give sense of direction to an open source project, it's good to have
a mission statement.
The Mission Statement
The aim of The Good Suite is to provide a richly featured framework that
provides tools to minimize the effort required to create a (secure) website, to
decouple the application from the underlying technologies and to make the different
parts or aspects of the website loosely coupled. The Good Suite aims to promote proper
design and fully cater both to more traditional websites and to web applications,
while keeping a special focus on both modularity and universal usability.
Because the mission statement is rather dense in meaning, there is a number of notes
that help with its interpretation. All in all it is a rather long read, but worth it
in the sense that it creates a clear direction for the project.
- The mention of being richly featured means that the framework aims to
simplify as many tasks that are shared by many websites as possible as well as to
provide easy access to features that are less commonly used but are complicated to use
or require a lot of code without using the framework. These latter features should
generally be not too uncommonly used or possibly hindered mostly by the fact that
they are this complicated or require that much code.
- When talking about minimizing the effort, creating a (secure) website
is mentioned. This means both that the effort to create a website should be minimized
and that making that website secure should also be minimized.
- Minimizing the effort is first and the foremost about making it possible to
write code while expending less effort on things other than the content and special
features of the website or web application. An example of this is abstracting the
writing of SQL queries, which possibly leads to more code, but makes the code easier
- Though it takes a backseat to how much thought needs to be put into the code,
reducing the amount of code required is a secondary aim.
- One way the framework decouples the application from the underlying
technologies is to provide a layer of abstraction between the required functionality
and the underlying technology, so that swapping the layer for a different one changes
which technology is used without any (further) change to the code.
- Another way to decouple the application from the used technology is to have the
framework provide functionality based on the task a user wants to accomplish while the
framework chooses the best available technology. This strategy may be a good approach
when the task adds semantics to the particular use of the technology, when users have
little reason to change which underlying technology is used, when it is clear which
technology is best and the availability is the main decision point and/or when users
are known to not always make a good choice when tasked with choosing a technology
- Promoting proper design involves but is not limited to neatly sticking to the
specifications (eg. providing a domain name when changing the location header), using
the best technology available (eg. using proper hashing for passwords, with a separate
salt for each password) and not providing functionality that the web is and never was
meant for (eg. trying to force cookies through methods like flash cookies).
- Traditional websites and web applications are mentioned separately. This is
because the more traditional website has different requirements than a site designed to
function as an application inside your browser. The latter often has only a single page,
interaction with either your computer or other humans. The aim of The Good Suite is to
provide shared functionality as well as functionality specifically for both types of
websites. Any mention of the word website outside of the original mention of those two
types and this explanation should be taken to mean both traditional websites and web
- Modularity is achieved through a system of modules which can be installed
individually. The aim is to decouple the usage of the modules wherever possible, so
that users can cherry pick the features they want to use. However, modules may freely
use other modules internally wherever that does not require the users to do the same.
- Universal usability refers to making sure that users are able to use the framework
in almost any setup. This is achieved by choosing widely supported languages and not relying
on certain extensions or functionality to be present when possible. When such extensions
or functionality are required it should be limited to a single module. Furthermore,
providing alternatives for when certain functionality is unavailable can also be used as
a way to increase the usability.
- From time to time certain functionality might be lost to other aims. Examples
would be losing SQL features because it is abstracted in a way that's broader than SQL
and losing some flexibility when using the framework's method to change the session storage
system compared to defining your own session handler. This is a direct result of the other
aims of the framework. It should be avoided when possible without compromising the other
aims. However, it is an acceptable side-effect because the framework can be used alongside
normal PHP, which means that if the provided functionality isn't enough for the user,
he can use normal PHP to supplement what we provide.
- It should be noted that no language is mentioned the mission statement. One of
html and css. Another reason is that the framework isn't limited to a single language.
PHP is chosen server side because it is an industry standard and thus nicely fits in with
the aim to be universally usable. It is not completely unthinkable that the framework will
one day (also) target another language entirely. Much more likely would be a version of the
framework that is a PHP extension, which allows it to run much faster for those who can
install it, while the same interface will be available to those who can't through the php
version. This too is not an aim for the near future at all.
- It should also be noted that there is no mention of speed or performance. Being
a framework it is still a requirement and drives design quite a bit. General guidelines on
this issue are that no complexity should be added unless it is needed to provide extra
functionality. When it adds extra functionality, it still shouldn't add complexity when
the usage is typical. Optimizations reducing the overhead of using a framework that can be
done opaquely to the user should be done, though if the gain isn't too big or the required
effort is big, it should have quite a low priority. Additionally, compiling to php can be
done to make sure a big performance hit is only done once instead of upon each request.
Also, the modularity of the system should be optimally used for performance, meaning that
files shouldn't be included unless used.