I'm thinking about trimming down the Nexista code base some more. Based on my recent experiences with phing, I'm wondering if it makes sense for Nexista to have a foundry class at all. The foundry class is used to "make" sites from their configuration files. That includes merging configuration files, and converting the sitemap from an XML document to a PHP file containing arrays. Even if phing can't perform this task out of the box, I'm pretty sure I could setup a task to do this using some of the code from nexista.Moving the builder / make / foundry process would free up nexista to focus more on the runtime process, where in my opinion nexista truly performs with its handling of SQL queries, authorization, and XML and XSL transformations.
Builder / Make Process
builder.php: * This class provides abstract functionality to build the cached php gate files * for each action based on the sitemap. * * It should be extended for each possible tags in the sitemap. In your class * extend the getCodeStart() and getCodeEnd() functions. * The attributes of the tag are available in the $params array * * If your tag does not allow nesting of other tag (such as validate, if) then * you can disregard the getCodeEnd() method *. * You should also add any required files into the $required array * by extending it and setting new values in your class.Foundry, also Make Process
foundry.php: * This class is reponsible for building a site/application * based on desired sitemap and configuration settings. * * The build process creates a compiled php file from the sitemap * definition as well as the necessary file to handle the logic of * presenting these files based on request. * * A typical build would output: * - A loader file such as index.php which is used as the 'entrance' file for the application. * - A switchbox file which is responsible for returning the proper data based on request * - A number of 'gate' php files, one for each section or 'page' of the sitema which * are responsible for handling the per request logic and will load the * necessary module files such as query definitions, php scripts, xsl stylesheets, * - A configuration file based on our preferences.Configuration
The config.php file is also a make process of sorts, especially since I've been using XML entities more and more over the recent past. Actually its the same case with the query handler. It might make sense to explore the possibility of using phing to manipulate and work with the entities that are used in both the config.xml file (it is not converted to php until runtime) and the query files (they are also not converted or "cached" into php files, they are parsed on the fly during runtime). Though config uses the native simple xml object format, it might be more appropriate to cache that object in memcached or xcache, if available. Actually I'm not sure if xcache supports caching objects yet. Correct * **:Warning : At the moment, It is not possible to store resources, callbacks or objects using xcache_* functions.Anyway, simplXML objects cannot be cached via serialization. *Hmm. I've changed my mind about php based configuration files. I really like using simpleXML for configuration files, and with a little work (especially with respect to entities and database connections), it will work better for customization and exceptions.Just taking notes here: * queries also use simpleXML* design, build, customize, test, publish* make, config, run, cache* During make process, foundry calls builder. * During config process, config parses config.xml* Config process occurs upon initialization of run process* phing could be used to initialize a project, initialize or add applications, and set hostname access, either explicit or built on runtime.* how many config files would it be feasible to merge before the final once is written / cached?Other changes: * remove lib/gdimage.php or rename lib plugins?* move xsl and datasources out of kernel/ to...* base environment / mode configurations (dev, test, production, different branding, etc.) solely on host names - would environments / modes each require their own make process, or only their own configuration?* clarify that auth.php is really only authorization, not authentication - that is handled by an external library of your choice, such as the auth nexista application (which should be renamed authn), and auth.php should be renamed authz, along the lines of how Apache's modules are setup.
SimpleXML Improvements
SimpleXML has improved lately, including the ability to pass libxml parameters, like LIBMXL_NOCDATA and even better LIBXML_DTDLOAD. This is a better way to create and store the entities that are used for customizing the config and queries at runtime. I just added LIBXML_DTDLOAD to the current SVN of kernel/config.php. Note: this feature requires PHP > 5.2 and libxml2 > 2.6.0.Eventually, it would be appropriate to also reference the configuration data as an associative array, which can be cached in xcache or memcached (xcache can store associative arrays). The only issue I see with storing the configuration data in an associative array is the mode xml attribute. It is used to specify different values for the same setting to be used depending upon the runtime mode, like dev, test, and production. Attributes are also used for datasource ids. The ability to override settings using additional configuration files can assist with the datasource ids, and the use of runtime-defined entities could replace the need for modes. This reminds me, I would like to also differentiate configurations based upon request_method (ie. get, post, head, delete, put). I believe it will be appropriate to use the server_name as the mode, meaning that the configuration file can have the mode attribute, but the values will be the server names used to access the application. When the masterconfig is built and cached on a per-host basis, only the settings for that mode will be written. <runtime host="dev.nexista.org" method="get"> <cache>0</cache> <debug>off</debug> </runtime>