HOME DIRECTIONS HOTEL SCHEDULE TOPICS SPEAKERS REGISTRATION Special Offer More CLASSES SPREAD THE WORD Latest NEWS Photos

CF Conf Central
August 30th - September 1st, 2003
Las Vegas, NV

NEWS

Each week from now until the Fusebox conference (Aug 31 - Sep 1), we're talking with one of the conference speakers.

WEEK 3: John Quarto-von Tivadar

FB: We're talking with John Quarto-vonTivadar this week. John is
speaking on plugins and security at the upcoming Fusebox conference.
John is also one of the authors on the upcoming "Discovering Fusebox 4"
book from Techspedition Press (techspedition.com). So, John, what is
a "plugin"?

JQ: It's a way of extending the core functionality of Fusebox. When
Fusebox 3 was released, we saw that people had special needs that
they wanted handled by the Fusebox core files. They had to change the
core files to meet those needs and of course, that introduced problems.

FB: What sort of problems?

JQ: Well, one of the advantages of Fusebox is that it is a well-known
standard. It means that my code can work with your code, pretty much
seamlessly. But if, when we say "Fusebox", we're talking about two
separate things-

FB. Which happens if you have different core files.

JQ: Exactly. And when that happens, it means that interoperability goes
out the window. It also means that the code you write for one version
almost certainly won't work with the next version.

FB: You're talking about versions of Fusebox?

JQ: Yes. If you write your code counting on some functionality in
Fusebox that's there because you changed the core files, then when
version 4 comes out-

FB: Which is out now.

JQ: Yep, officially released. Anyway, when Fusebox 4 was released,
then the old code wouldn't work with the new version.

FB: And plugins solve this?

JQ: Yes. They solve it because Fusebox 4 is made to accommodate
those changes. Fusebox 4 has "plugin points"-different phases of the
code which will include any plugin code you write, making them, in
effect, part of the core files. When there's a new version, you just drop
your existing plugins in and you're up and running.

FB: That does sound like a great idea. What exactly is a "plugin point"
though?

JQ: There are certain points in the processing of a Fusebox request that
we identified as points where someone might want to insert some code.
For example, there's a "preprocess" plugin point. Any plugins that are
registered to run in the preprocess phase will be included before virtually
anything else happens in the processing of a fuseaction request.

FB: So there's probably a "postprocess"?

JQ: Right. We identified all of the points we thought would make sense.
There are a total of six of them. One thing that will interest people is
that one of the phases is "fuseactionException". When an exception is
thrown, the core files will check to see what plugins are registered and
will pass control to those plugins. That means that we have a really nice
way of doing exception handling-something that was lacking in Fusebox
3.

FB: That's very nice.

JQ: It does work very well. We're really pleased with Fusebox 4.

FB: So what about security? How did that get built into the core file?

JQ: We thought for a long time about security. The problem is that
there is no universal security model. But we didn't want to just punt the
ball. Security is too important. What we did was introduce an attribute
to the new <fuseaction> tag called "permissions". That allows architects
to provide a value that will be available to the core files.

FB: And the core files then check the value of "permissions" with a
database of user permissions?

JQ: Well, that might be the way that you would want to handle it, but
then again, you might have a completely different mechanism. It's why I
say there's no universal security model that fits everyone. Instead of
Fusebox trying to impose a one-size-fits-all solution, we provide
this "permissions" attribute and then let the architect determine what to
do with that in a.

FB: In a what?

JQ: That's your cue. Your supposed to jump in with the right answer.

FB. Oh. Um.in a "security module"?

JQ: Yes-sort of. And how would that security module be implemented?

FB: In a plugin!

JQ: Exactly. It's a perfect application for a plugin. Security can be as
simple or as complex as you wish it to be. And you only write one
security module, as you called it, and it will be applied for all
fuseactions
that you wish.

FB: What if I don't want any security applied at all?

JQ: Just don't register any security plugin. It's not like you'll pay any
performance penalty. The value, if any, of the "permissions" attribute
will just be ignored. For that matter, the "permissions" attribute, itself,
is
optional.

FB: I'm seeing that plugins can be very powerful.

JQ: Yes, and just as importantly, they are very simple to implement.
Plus, there are already pre-built plugins available.

FB: You're going to be sharing tips and tricks on plugins and security at
the conference?

JQ: Yes, I've got a fun application that graphically shows how to create
a pretty involved security model. And we'll see how plugins can span
phases-all sorts of cool stuff.

FB: Where do people sign up?

JQ: That would be at www.cfconf.org/fusebox2003.

FB: And if people want to buy a copy of your new book?

JQ: It will be available at the conference or you can buy it from
techspedition.com. People preordering the book will get a 25% discount.
Of course, there's a way to get the book for free.

FB. What's that?

JQ: Hal and I are doing a "FastTrack to Fusebox 4" class in Las Vegas
immediately prior to the conference. Come to the class (halhelms.com)
and you'll get a free book AND a pass to the conference.

FB: Thanks, John.


Previous weeks:
Week 1: Ben Edwards
Week 2: Michael Smith
Week 4: Hal Helms
Week 5: Jeff Peters


If you have any questions, contact michael@teratech.com


|  HOME  |  DIRECTIONS  |  HOTEL  |  SCHEDULE  |
|  TOPICS  |  SPEAKERS  |  REGISTER  |  CF CONF CENTRAL  |