Obviously, there is no one single solution that would satisfy everyone’s needs; an architecture is always a trade-off. I want to create a framework, originally aimed at RAD of web games. Target language is PHP, although the architecture should be widely applicable.
Goals that I have in head for this framework are: flexibility in ways you can achieve the result; maximal comfort for developers; connecting modules like LEGO® blocks; many types of input, many types of output, one format for processing.
The goals that are not a priority are speed, enterprise use and making money. It’s supposed to be an open source project.
The cornerstone of this design is that all content, before transformation, is processed in XML (idea based on EAI system I’ve worked with, eGate). The data abstraction layer – hopefully some smart ORM – is not important now. The output will be generated using XSLT or any other custom modules, for virtually any client – HTML for old browsers, XHTML/HTML5 for modern browsers, simple HTML for mobile clients, XML for AJAX/XMLRPC, etc.
Main reasons for using XML are:
it’s a well-known standard
existing tools like XPath, SimpleXML and DOM for navigating and modifying the content
XSLT providing a powerful and unified way to transform the code into any tag soup
I find the XML markup very easily readable, therefore I don’t think that advantages of JSON or YAML make a difference here
The content can be stacked easily, and it the order of the content doesn’t really matter as long as it’s transformed correctly with XSLT
The page generation process would consist of these phases:
Pre-processing: initializing modules, processing GPCS data, applying default [XML] templates
Processing/generation: main part of business logic, generating the bloated XML with maximum data (although hopefully optimized not to generate balast)
Processing: some additional business logic, e.g. cutting down some of the markup, preparing for transformation, reporting, statistics, etc.
Post-processing: parsing XML through the transformation engine (most probably just XSLT), output.
The content would be generated with a lot of meta-data (e.g. tags, permissions, importance, necessity, aimed output type), which would be stripped down during post-processing.
So, my question is: except for speed, what is the downfall of this solution? Where it could go wrong both during the development/maintenance of the framework, and its applications? What are the downsides of this architecture?
2 ANSWERS
You must be logged in to reply to this topic.
