Guiding Principles
In order to achieve the project aims, all framework code is developed under the following guiding
principles:
- Independence
Classes, objects, components and applications should just be regular Java, testable using regular testing
tools (such as JUnit), and without needing complex server-test-injection frameworks, staring up and tearing down a
server during testing, or building and deploying a whole application to test a small section of functionality.
Code produced for use with mojasef should be readable and understandable by anyone who knows Java, whether or
not they have ever encountered the mojasef framework.
- Self-Similarity
When you put some static text on the web it can be at the top of a domain, in a deeply nested
folder, or included as part of a page. Dynamic content on the web should not care how it is accessed. Applications and
application components should be interchangeable. Complex applications should be easily to construct
by arranging smaller applications without needing to change the code, and simple components should be usable as
complete applications if they do what's needed.
- User Serviceable Parts
If an application designer/developer or deployer/configurer needs to change some decision to suit a
particular deployment (from a simple text value such as a database password to the replacement
of the class used for generating session cookies and beyond) it should be achievable without recompiling
the server or the application, or its components. Configurations should be as concise as possible, and
each configuration should be stated in only one place. Configurations should not need tool support beyond
a basic text editor.
- Graceful Defaults
The system should run effectively and sensibly with no external configurations. Where configurations are
desired which change or enhance the default behaviour, only the changes need be specified. No change or
extension should require re-stating default behaviour or configurations that require telling the system to
"use the default".
- Unobtrusiveness
Existing code should be directly usable without needing to rewrite it to fit a particular
class framework. Applications and components should not need to extend framework-specific base classes
or need to be wrapped in cumbersome, framework-specific (and often largely untestable) objects. Existing Java
programming experience should be directly usable without needing to spend a lot of time and effort studying
complex APIs and learning different ways to do things.
- Respect
Above all, the framework should respect the underlying culture of the implementation language. For Java,
that includes things like using regular member variables for storage between requests, and static variables
for sharing between sessions/threads. It includes being able to write output to System.out, just as you can
in a console application, and the use of normal Java visibility modifiers ("private", "protected", "public")
to indicate which methods and member variables are visible to the framework and to users. These conventions
are openly flouted by the servlet API, which can lead to misunderstandings, frustration, and poor application
design.

This site is licensed under a