Inbox ===== * Change all use of Solar_Registry::get() to Solar::dependency(), and add config keys as needed * find a way to automate release notices - solarphp.com - paul-m-jones.com - twitter solarphp - retweet through pmjones - link on facebook * docs - integrate api docs into release process, add link to downloadable docs - Add support for inherited constants in Solar_Docs_Apiref - do a release of the existing codebase * other - start on orbit system (members/bookmarks/blog/gallery/status) - start on solar v2? - membership management system on solar site: tie all passwords together, incl. writing to .htaccess as needed - add a role management system on solar site, or proxima? - change release process so we can release from a branch? or deal with that only when we get to 1.2 ? - form not showing invalids from relateds. ran into this when checking proxima; not showing errors from "taggings" in the main part - publish proxima bookmarks as an example app. point is not to show off any JS libs, but the organization and structure of a solar app. - identity map for model objects Feature Additions ================= - create "start" or "setup" solar app to let user know it's working - debugger profile - optimize chained to-one queries - zero or very few known bugs or corrections - default auth partials and layout? - add a "strict" option to front controller or uri rewriter, so that if no rewrite rule matches, it won't proceed to auto-find the controller? - All docs - All tests - Unified controller/dispatcher system across front, page, console, command, etc - Solar_Sql_UnionModel, Record, Collection (extends model?) - "Model browser" from Jeff Moore - Identity map - Reciprocal relateds (esp. w/ belongs-to) - More unit-of-work-ishness - Grid - Dispatcher/controller (not a BC break which is nice) - Query language vs. array (design, not necessarily implement) - Bulk edit example - In controller, a "mediator" object to note which vars to pass to the view ... example modes would be "send all public" and "send only whitelist" - Locale fixes (*starred*) - Template system for string-replacement in views - Real properties in model records - add "on delete cascade" and "on delete nullify" behaviors Docs/Website ============ * Write up notes on when to use config keys for dependency injection, and when to use method-based injection (e.g., Page::setFrontController()). * Add links to other vendors (external Solar library collections) * Credentials management system on SolarWeb * change api docs so that public methods are listed first * allow comments on apidoc pages and manual pages System ====== * Default exception handler for pre-controller exceptions? New Classes =========== * Add a Solar_Static class to allow for building configs, getting locale strings, and throwing exceptions? Cf. Solar_Dir::rmdir() and the use of $self for throwing exceptions. * Add a Solar_Plugin class to allow for standard plugin architecture? (Would apply to View helpers and Filter plugins, among others.) Or would it be a compositional element and interface? Move Classes ============ * call it solar_form_load_record, not *_model? or, put it over at Solar_Sql_Model? Core Classes ============ * Solar_App* * Create a "Config" or "Setup" app to examine config/setup/etc, like Symfony/Cake/etc * Solar_Base * Add a $_log property and _log() method for universal logging? Would need a 'log' config element too, for injections. Maybe call it _debug() instead, since the idea is it's for debugging? Or perhaps by calls to Solar::debug()? * Add a _getConfig() method for safely getting config values? * Solar_Cli_MakeDocs * add 'fluent' return type? 'self'? '$this'? * make-docs, use separate PHP process (or Apiref?) * Solar_Cli_MakeModel * include Locale dir even for STI models * Solar_Cli_RunTests * start checking for Test_* and test*() in the command? * add run-tests --report-fail, --report-todo, --report-skip to show the respective tests at the end of the run * Solar_Controller_Page * Augment $_view_class with a search of the parents for Vendor_View? * Use reflection to count action method args, and throw 500 (or something) if there are more info elements than args? (To prevent ignoring of elements from making it look like the URI actually exists.) * $_action_format: "If an action is not listed, it will not respond to alternative formats." * Solar_Docs_Apiref * Find a way to document magic __get, __set, and __call. * Solar_Http_Request_Adapter * Need file uploads and multipart/form-data * From Nicholas Sloan: When presenting with the following error: "failed to open stream: no suitable wrapper could be found," which can appear as a result of a call to both include/require/require_once/include_once and fopen (and other stream functions), change the allow_url_include and/or allow_url_fopen values to "On" in your php.ini file, or using ini_set() in your application's code. * Solar_Markdown plugins * Macros? {{macro-name key=val key=val key=val}} * Blocks? {{note: }} {{warning: }} * PropertySynopsis? * Solar_Sql * Make profiling use a log adapter, instead of just returning? * Better reporting of "file not found" when SQLite has to create the DB * Solar_Sql_Model * On 'eager', force the needed cols into the selection, otherwise you get "index not found" when merging related results. * Rename default catalog to 'sql_model_catalog' ? Is more in line with the existing names, where we drop the vendor name. * Abstract model behavior for polymorphics * how to avoid re-counting the main fetch result IDs? * put inherit_col fixing into its own method (separate from fixTableName and fixPropertyCols) ... involves inherit_name, inherit_base, and model_name * Solar_Sql_Model_Record * Default to using gmdate(), not date(), for now()? * How to load() has-one elements of a record from a $_POST? How to represent in a form? * How to load() has-many and has-many-through elements of a record from a $_POST? And, how to represent in a form? * Record::load() for has-many and has-many-through elements of a record from a $_POST, and how to represent in a form. * ... wow, difficult problem. * Record::load() for has-one elements of a record from a $_POST, and how to represent in a form. (Hope this is easier than has-many.) * Solar_View * Add 'routing'-like behavior to map helper names directly to specific classes. * Solar_View_Helper_Form and FormElement * Allow nested fieldsets in forms? * Add support for disabled elements: on 'disable' mark the attribute 'readonly="readonly"'. * Have group use attribs? $view->form()->group($label, $attribs) * Add $view->form()->beginDiv($attibs) and endDiv() ? * Add formBegin($attribs) and formEnd() helpers? * Add formFeedback($list) helper? * move element-modifying stuff (like IDs, classes etc) from Form to the Element helpers ... also status and require indicators? * becomes difficult to track duplicate IDs on different elements, need to have at least that part in both places. * would also want to streamline ID, class, etc. output. * add feedback messages as well? * add IDs to Form helper for the form tag itself?