Plug it in Plug it in Glade Tidings

  • Slides: 10
Download presentation
"Plug it in, Plug it in" Glade Tidings of Plugins in Fusebox 4 John

"Plug it in, Plug it in" Glade Tidings of Plugins in Fusebox 4 John Quarto-von. Tivadar Future Now, Inc johnq@futurenowinc. com

What is a Plugin? l l l developers often need to extend the functionality

What is a Plugin? l l l developers often need to extend the functionality of Fusebox the real question: is this for a particular Fusebox app or all Fusebox apps? for particular Fusebox, solution is a fuseaction and its associated fuses for all Fusebox apps, solution is core mod Plugins: middle ground. Non app specific functionality yet not common to all Fuseboxes

Thought Experiment #1 l l suppose users are required to log in to a

Thought Experiment #1 l l suppose users are required to log in to a app option: modify the core file l l what if next app doesn't need authentication? "log in" is a business rule of the project, business rules have nothing to do with core files Therefore we need a fuseaction (and possibly a circuit? )

Thought Experiment #2 l l suppose related login fuseactions are grouped together in a

Thought Experiment #2 l l suppose related login fuseactions are grouped together in a circuit "Security" how does FB know what to do with a circuit? how circuits (and their FAs) are accessed are not specific to a particular app – all FB apps need to be able to access circuits a general requirement requires an abstract solution

Thought Experiment #3 l l suppose when an exception occurs an email should be

Thought Experiment #3 l l suppose when an exception occurs an email should be sent to the administrator Two parts: l part 1: send an email. l l part 2: handle an exception l l A business rule! should be a fuseaction not all apps send emails all apps need some way to handle exceptions what we need is …. . a Plugin!

Therefore… l Plugins occupy the solution space between a functional requirement for your app

Therefore… l Plugins occupy the solution space between a functional requirement for your app versus available functionality for every app

Plugin Points l l l pre. Process pre. Fuseaction post. Fuseaction fuseaction. Exception post.

Plugin Points l l l pre. Process pre. Fuseaction post. Fuseaction fuseaction. Exception post. Process process. Error

Now you try: l l suppose you wanted to load a file "Constants" each

Now you try: l l suppose you wanted to load a file "Constants" each request – where would it go? You decide against normally logging procedures and instead want to write your own – where would this go? what about users who request a non-existant fuseaction? how would that be handled? You decide to check the permissions accorded a user before executing some functionality – where would this go?

Example Plugin section of Fusebox. xml <plugins> <phase name="pre. Process"> <plugin name="Global. Settings" template="Globals.

Example Plugin section of Fusebox. xml <plugins> <phase name="pre. Process"> <plugin name="Global. Settings" template="Globals. cfm" /> </phase> <plugins>

Sharing Plugins l l If plugins are properly written, they can work with all

Sharing Plugins l l If plugins are properly written, they can work with all FB 4 apps no matter what other plugins may also be in use visit www. fusebox. org for a growing library of publicly available plugins