| | 1 | == Why a rewrite? == |
| | 2 | |
| | 3 | Rewriting a large, working application is not something to be undertaken lightly. |
| | 4 | It is a lot of work & the payback at this stage isn't clear. |
| | 5 | |
| | 6 | It is being done to address some real problems with the the current Sahana codebase: |
| | 7 | * Sahana is currently based on design principles which have since become sub-optimal due to the emergence of new Rapid Application Development frameworks & highly-interactive Web 2.0 UIs. |
| | 8 | |
| | 9 | * The current codebase has grown organically since it was originally designed - this has meant that standards have broken down & the code is becoming harder to maintain & add new functionality to. |
| | 10 | |
| | 11 | * It is currently hard to access data from modules via consistent methods...this is required for serious integration e.g. in GIS & Messaging. |
| | 12 | |
| | 13 | * PHP is not a good language for building large, maintainable applications: http://www.ukuug.org/events/linux2002/papers/html/php/index.html |
| | 14 | * especially when using it to write out complex Javascript (the syntaxes are always tripping you up) |
| | 15 | * doesn't enforce Object Orientation |
| | 16 | * poor separation of Presentation & Code |
| | 17 | |
| | 18 | * Whilst there is a fairly coherent framework, it isn't adhered to consistently - different developers have done very different things in different modules |
| | 19 | * The Javascript components especially are very varied with lots of manual AJAX & the use of several different libraries |
| | 20 | * using a modern library means no issues with browser incompatibilities |
| | 21 | * consistency means less headers for clients to download |
| | 22 | ---- |
| | 23 | FrequentlyAskedQuestions |
