CB 3 best practices

I was just going through and checking out some of the cfeclipse
snippets and such and the EventHandler skeleton brought up a question
for me as to what is the recommended setup for CB 3 as we get closer
to a release.

The skeleton creates a cfcomponent tag that extends
coldbox.system.EventHandler. I know that this isn't required but is it
recommended? It seems like the general direction of CB is toward doing
less through inheritance and more through composition.

The skeleton does not creation an init function that returns an
instance of the object and calls super.init How are handlers invoked
in CB 3? Do they need an init function that calls the parent init? I
suppose it doesn't if extending coldbox.system.EventHandler is
optional as there wouldn't be a parent to init. Does anything even
look at the init function of a handler in CB 3?

The cfcomponent declaration doesn't have a name attribute. I seem to
recall that there were some issues with certain versions of CF that
had problems if the name attribute wasn't present but I could be
making that up. Is there a good reason to have a display name or to
not have one?

Cheers,
Judah

I believe one of the goals is to simplify as much as possible. I would recommend placing ‘name’ in the declaration of every CFC as well as a comment/hint for your self-documentation.

I don’t extend my event handlers. I also do not use an init method.

I can’t answer if the above is best practice.

Yes, all the cfeclipse/builder snippets have to be updated, they have not been touched yet as they are auxiliary thhings until the core is finalized.

But yes, best practice on handlers is to not use th einheritance and no constructor unless you really need one.

Luis F. Majano
President
Ortus Solutions, Corp

ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com

Ok, thanks Luis. I suspected that was the case. Speaking of updating
the snippets and such, I know that you've opened up the project on
github, which I think is fantastic. The hard part for me, however, as
a potential volunteer is that I don't really know what is most useful
to help out with. Do you have a list anywhere of "things that need to
get done" so that volunteers can grab one and do it?

Cheers,
Judah

Well, I have the tickets but not a full list.

I would gladly create one, but don’t know where to put it, any ideas? Maybe just a list here?

Luis F. Majano
President
Ortus Solutions, Corp

ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com

Maybe here or perhaps a Wiki so that people could annotate them and
say "I got it". That way if I had a couple hours in an evening I could
go look and say, "oh yeah, I'll update some of the cfeclipse stuff" or
document the new handler setup or whatsomever.

Judah

I recommend opening the ‘coldbox-community’ Assembla space to allow anyone to join. Tickets for auxiliary projects could be contained there and then anyone could contribute–even if they only ever solve one ticket.

Aaron, I thought that was available now? Can you try, it should be open in the community space.

Luis F. Majano
President
Ortus Solutions, Corp

ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com

What about creating community tickets: http://coldbox.assembla.com/spaces/coldbox-community/tickets

I think the space is free for anybody to join the space and be part of it. Then they have access to modify, add, etc tickets, messages etc.

We could drive all community projects via this space and leave the core in the platform space. Ideas, thoughts, etc?

Luis F. Majano
President
Ortus Solutions, Corp

ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com

That sounds good. So documentation, cfeclipse dictionaries, plugins,
interceptors...everything that is non-core, ja?

I just signed up to that space and was able to use my Google account.

Judah

Awesome.

Here is a list Judah if you want to add as tickets:

  • cfeclipse/builder snippets

  • cfeclipse/builder syntax dictionaries and dictionary generator (this is under /testing/tools in the core)

  • cheat sheet

  • Modify the current cheat sheet but would be great to do the following

  • Simple 1 page cheatsheet for core

  • Simple 1 page cheatsheet for module developers

  • Cheatsheet for all ColdBox plugins

  • Cheatsheet for all ColdBox interceptors

  • A simplestart cheatsheet like those out there on refcardz.com

  • Update of the sample apps to version 3.0

  • Blog entries

Luis F. Majano
President
Ortus Solutions, Corp

ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com

orly?

News to me :slight_smile:

When exactly did that happen? Was it one of the M builds or earlier?

So CB3 mixes in the otherwise inherited methods? (getPlugin() etc)

On the question of construction, if init() is present (and doesn't
have to call super.init() - yay!), when exactly is it called? At what
point of the lifecycle, in relation to other components and
configuration?

/me looking forward to removing extends and super.init() crap from his
event handlers...

Inheritance is optional. If you like clean simple CFCs then you can just build a simple Cfc and coldbox will decorate it at runtime. If it has a constructor it will use it.

If you use inheritance then that's fine too but the constructor must match the one in the docs and must call super.init

The simple cfc does not need to call super. But I it needs to override anything in the super class it talks to to $super.

Does this help clarify?