SLB: Notes – Options: Building Output
Setting options for building output
Collections, groups, items, etc.
Options
- Hooks: Set hooks in various points in output-building code
- Similar to operations in WP core (query, etc.)
+Uses built-in functionality (WP filters/actions)- Methodology
- Calling function sets hooks (collection, items, etc.)
- Call
buildmethod - Remove hooks
+Modular – no need to set default variables & validate callbacks when building- Simply apply hooks and move on.
- Easier for managing modification of output independently
- Hooks can be set for other operations (methods) in output building process, not just
buildmethod -Potential conflicts by overly-aggressive hooks- e.g. Setting and then forgetting to remove hooks
- Solution: Callbacks should validate request (context, etc.) prior to modifying output (if they are not removed immediately after building)
- Just like standard WP hooks
-Requires 2-steps (add & remove hooks) whenever building output- Extra work
- Build variables passed to
buildmethod - Used to customize output
-Must be passed down hierarchy:Collection > Group > Item- Different objects (collections, groups, items, etc.) require different options
- Same option property may not suffice for different object types
- Would need to namespace option names to avoid collisions (e.g.
'collection_limit','item_limit', etc.) -Would be hassle to parse+Options reset eat time build is called (independent)- No conflicts with other code (clean request every time)
- Methodology
- Create options array in calling function
- Pass options to
buildmethod buildmethod parses/validates options- Sets options as object properties
buildpasses variables to group, item, etc. building methods (e.g.$item->build($options), etc.)- Options used to build output
-More steps and data management than 1- Hooks + Options: Use hooks and pass options where most appropriate
- e.g. Callbacks should be hooks, layouts should be passed via options, etc.
?Hook or option?- Collection pre/post build: hook
- Group pre/post build: hook
- Item pre/post build: hook
- Layout ID: option
- Layout retrieval: hook
- Context: option
- Groups to build: option
Returning or printing output
Options
- Return generated output
-Must remember to print in calling function (not difficult)+Flexible – Output can simple be returned for additional processing or printed (decided by calling function)+Potentially faster – Adding output to array (for returning to calling function) instead of printing line by line-Cannot use actions – generally used for printing output, not returning values- Must convert all hooks to filters (relatively simple)
- Actions can be used if output array is passed to hook (e.g.
do_action('action-name', $this->output)) - Actions vs filters is mostly semantics (can print from filters if necessary)
-Must use output buffering to capture raw HTML (outside of PHP tags)- Raw HTML is printed immediately
-Need to manage long strings (PHP not especially good at this)- Print output as created in code
+Output automatically printed-Must useechooften (slower performance?)+Able to use action and filtersdo_actionto print immediatelyapply_filtersto filter then print (headers, etc.)-Less flexible – all content is output immediately?How to handle when printing is not desired?- Very rare
ACan use output buffering in calling function+Can use raw HTML (outside of PHP tags)