Here are some of the Appy's underlying principles.
Developers, too, have the right to (h)appyness
Developers are often wandering and haggard human beings. Some think this is because software development is so exciting that everything else is poorly considered. Most probably, the reason is to be found in these complex problems that never go away from their minds. Nobody understands them. Their family? Their managers? Their clients? Their friends? No. Nobody. Nobody is able to imagine how huge and complex their tasks are. Consequently, what they do is underestimated. Worst: they can't communicate. Don't believe this is due to some intrinseque geek attitude. Their geekness results from the global incapacity to apprehend the very nature of their abilities. So they are forced to work harder while experiencing the true impossibility to share their permanent software experience. Of course, it may lead to social disasters.
By publishing this high-level, easy-to-use Python-based software construction kit,
our crazy hope is to empower developers in such a way that they can leave more often
their software prison and spend more time to discover real life.
But (h)appyness has a price. Appy developers themselves accepted to pay. They have dealed their social life for one of the highest forms of social denial (their working conditions can't be revealed), hoping their sacrifice will free the users of their work. If, one day, you meet one of them, please be gentle and patient. But they will probably not discuss with you.
The null-IT principle
Appy was built with this idea in mind:
Information Technology (IT) should be as transparent and invisible as possible.
While this may seem obvious, this principle is largely ridiculed by a great number of widespread technologies.
The following other principles underlie Appy.
A code-centric but conceptual approach
Violating the model-view-controller pattern (and a lot of other patterns, too)
Some design patterns are elegant low-level constructs used to overcome the limitations of programming languages or frameworks. Using some of them implies adding classes just for making the plumbery work; it augments code complexity and, again, spreads information at several places. Separating code describing data from code presenting it produces the same problem. Appy takes the approach of grouping everything at the same place. For example, information that dictates how a given field will be displayed in the user interface, manipulated in "business logic" and stored in the database will be grouped together as part of a unique field definition.
As a consequence, Appy objects (which are plain old Python objects: you do not even have to inherit from a base class) are self-sufficient. If you want to understand some (group of) functionality within a well-designed Appy app, you will not loose yourself walking through an intricate web of Python classes and XML definition files.
Building complex and shared web applications
While some out-of-the-box tools are mainly targeted at building websites of specific categories (informative sites, blogs...), they provide poor support for those who want to build complex and shared web applications.
By "complex", we mean real "business applications" (or "information systems", like accounting systems, HR systems or online booking systems) whose interfaces are web interfaces; a classical CMS-based website being a particular case whose main purpose is to provide information, with some limited degree of interaction with the user. Web business applications are characterized by (1) a rich conceptual model featuring a complex web of inter-related classes and (2) the need for complex searching and reporting facilities, be it through-the-web or within generated documents.
Currently, free software is widespread within the "IT infrastructure" (operating systems, networking components, web servers, application servers...) and contaminates more and more general-purpose software applications, like word processors, spreadsheets or multimedia players. For the most of it, the free movement currently reaches domains where requirements are either perfectly known by the developers themselves, deduced from observing proprietary software or part of some general cultural background. In order to raise freedom at the higher levels of business and innovation, we need new mechanisms allowing to tackle (business-)specific requirements, while maintaining the possibility to spread and share software from one organization to the other. Appy was built to cope with this new scale of challenges and proposes a set of built-in constructs for creating generic business kernels implementing common requirements and allowing to tailor it to the specific needs of a given organization.