CF Camp Notes: Secrets of a Mura Code Ninja, Grant Shepert

October 22, 2014

Secrets of a Mura Code Ninja, Grant Shepert

Core concepts --
Core files should NEVER change.
2 sections in a normal Mura install
1. core base install (admin and api)
2. the site
these 2 concepts have "auto updaters" built into them


Update safe methodology
you can override "by context"

/includes folder
ALL the files used for rendering files on the front pages of a site.

/custom folder
can override anything in the /includes folder by just copy/pasting into here and modifying that.

Extend a page via Class Extension

$ can access EVERYTHING in Mura via the $ scope
-the api, current content, create feeds
added directly to display objects, theme templates
[ mura ]$...[ /mura ]
to call it inline content
BUT make sure people adding content are people you trust first.
can disable by setting "dynamic content" = 0 in Mura Admin

$.content()
current content object when your'e on a page


-same thing

Automate --

Class extensions --

Mura is a platform, not a framework
not as restrictive of an environment as a true "framework"

Core: Page, Folder, Gallery, File, Component

Can import/export Class Extensions now too

Can bind settings for class extensions on the "site" and "theme" level

Code example:
/[siteid]/includes/themes/[theme name]/config.xml.cfm

DIFFERENT from doing it in the Admin because this way makes a FILE whereas Admin puts it in the database. So saving and using via "deploy site bundle" etc is somewhat different (there's a plugin coming later that might help with this sort of thing).

Feeds and Iterators --
Feed: a list of Mura content objects
a container of objects that are collected based on certain criteria
generally it's "content" but you could also make feeds of users.

iterator: a mechanism for looping over that content
-- avoids us having to write custom queries to get "all the pages with the word 'bob' in the title" etc
-- also gives us a way to edit the objects, not just loop over them for read-only stuff
they're fast. accesses data efficiently, and only "on demand"

every time you do a query, it gets into a big long complicated join so you'll see a big performance drop.
so if you do things like "find all pages with a param between x and y value", really better to break that functionality out into a plugin, for efficiency.
take a look at the query mura generates


can also use "setQuery()" for really REALLY custom queries that have performance issues if you do them the way way above.

contentRenderer.cfc
if you put a function in here, it magically BECOMES available in the $ scope



Mura ORM --
Hibernate and CFORM doesn't play well inside Mura because it's at the "app level"
3 plugins using ORM (for example), any time you do a flush/transaction, it cascades thru ALL the plugins
so Matt wrote his own
it's not ORM as in "Hibernate", it's a way of rapidly building out apps.
Creates objects with many Mura properties
-feeds, iterators
-access via $.getBean()