CI3dev App Shell (HMVC like core extensions)

[eluser]jonez[/eluser]
Hi, I've enjoyed working with CI so I thought I'd package up some of my modifications and release them back to the community. The documentation isn't the best yet, if you have questions or want more examples let me know where and I'll do my best to add them.

Note: This is for CI3dev, not the current public release 2.1.4.

GitHub: https://github.com/monsterlane/codeigniter3-app

This project is meant as a starting point for modular high performance web and SAAS apps. If you use CSS sprite maps and the included asset caching, your site will meet every requirement of Yahoo's best practices for loading speed. See more here.

Features:

* HMVC like folder structure (controllers are in folders, views and assets are in controller folders, models are all in one folder for convenience)
* Automatic client side includes (controller/assets/js/script.js and controller/assets/css/style.css)
* Automatic client side module binding (with inheritance)
* Automatic css/js merging/minify/caching by group (system, controller level)
* Automatic favicon include (add favicon.ico to web root)
* Faux controller name-spacing (controllers are suffixed with _controller, models are not suffixed)
* Basic page templating (title, meta, css, js, page content)
* Basic email templating (email->template replaces email->message)
* Database logging of PHP errors (post controller construct)
* New methods for the output class (images with modified headers)
* Shorthand methods for the output class (string, json, appended output)
* Alternative html regex for the output class with better support for inline-block layouts
* Additional form validation methods (date)
* Additional array helpers
* Additional file helper
* Additional security helpers
* Upload helper
* Client side JS tools- modules, conduits, automatic error checking
* Includes latest jQuery (1.10.2) http://jquery.com/
* Includes modified normalize.css (2.1.3) http://necolas.github.io/normalize.css/

This package enforces a server side design pattern (required for the asset caching) that is very similar to HMVC. Like HMVC, controllers are in folders, and views/assets are in a controller's sub-folder. Models however, are stored in the default location (application/models) for convenience. If you need true HMVC this is not the package for you, if you used HMVC for the structure this is likely a better option.

This package also enforces a client side module pattern for JavaScript. If you aren't using AMD modules with requireJS, this is the layout I've found most useful for creating re-usable, extendable modules. The client tools includes a super global to namespace all your app's functionality, a base system module, examples of extended modules, a conduit system for managing AJAX calls, and automatic error checking of server responses.

For the automatic client side error checking to work you have to use the conduit system. Every server response you send back to the client via AJAX *must* be a JSON object. The conduit will attempt to parse the response, if it fails it will throw and your module's error handler (this can be extended to use any popular notification library).

If you use database transactions and follow the design patterns in this package virtually every error from the server can be gracefully displayed to the user without breaking the client.

The code is licensed under MIT, feel free to do whatever you want with it. If you find any bugs please report them, and if you find the code useful and make any modifications on your own please share them.

Enjoy!

[eluser]jonez[/eluser]
I'm getting an error trying to update my post.

Notes on the asset caching:

Assets (js/css) are added using $this->_include which adds files to an internal array. Grouping is done using numeric keys of arrays, group 0 is external files (pass in a URL starting with // so it supports HTTP(s)), 1 is system files (every page), 2 are controller level assets. Include statements are built and injected into the head (css) and just before the close body tag (js).

If caching is disabled (dev), normal per file includes are generated and a timestamp is appended to each file name (date modified for the file). This should block browser cache so you don't have to clear cache after changes.

If caching is enabled (testing/production), files are concatenated by their group and numeric key to ensure proper stacking. Any file without a minify suffix (.min, .pack etc) is minified using the third party library Minify. Any file that is already minified will be not be processed again, and will be concatenated with the other files in the group.

Cache is written to the /files/cache folder. Here's an example of what you'll see:

/files/cache/system.12312001323.min.js
/files/cache/example.23424134123.min.js

All system wide assets are compiled into 'system'. All controller level assets are compiled into 'controller' (example). For any given page view you will have at most 2 includes of each type.

The only gotcha with this system is how the cache is generated. On page view, if cache doesn't exist (for either system or controller) or it is outdated it will be regenerated. This usually takes ~1s extra then every subsequent view will server the cache.

The timestamp in the cache file name is the most recent last modified for all files in the group. If any file changes, the timestamp changes, and cache is regenerated. The gotcha with this is if you add a file to an existing group that already has cache, and the datemodified is old, cache will not be updated. The chances of this happening are rare, and working around it is not worth the hassle. Be aware of this when adding files. If you want to be 100% sure just delete the cache files for that module, or open any other file in the group change something and save it.

Notes about the HVMC folder structure and includes (images etc):

Use base_url when you include images, assets are served using the same pattern as routing. So if there's an image called 'test.png' in the /applications/controllers/example/assets/img folder, the correct path to display the image is /example/assets/img/test.png. In the root htaccess file there is a URL rewrite to fix the actual path (longhand) with the friendly one (like routing). In the application folder there is an htaccess file that blocks access to any file that isn't JS, CSS, or an image format. User files should all be placed in the /files directory so you shouldn't need to change that but if you run into a 403 trying to serve other types of files from a controllers asset folder that's why.

Notes on output:

Always use the output class. Using echo will break everything. Shorthand methods have been added to the output class to reduce the amount of typing you have to do to use it effectively.

If you output a page, use $this->page.
If you output from an AJAX call, use $this->output->json($data).

If you use the conduit system (recommended) attempting to output raw HTML will throw an error. Conduits automatically parse and return server responses for you. You do not have to check every request manually, if the request makes it to your callback it was successful and has already been decoded for you. If parsing failed your module will throw it's alert method. Alert is intended as a bridge to a notification library like jQueryUI or Bootstrap. This way if you ever want to change your library you update one method, not individual calls all throughout the code.

Other considerations:

* This package includes a modified version of normalize that applies 1em margins to block level elements (HTML5) for you. This will space most elements for you if you use proper HTML5 tags.
* The alternate HTML minify regex will not leave spaces between tags as the default one does. This is preferred for inline-block layouts (good) vs floats (bad).
* Use CSS sprite maps: http://www.spritecow.com/
* Use Tinypng on your sprite maps: https://tinypng.com/
* AJAX everything possible