Add ability to pass arbitrary data into breadcrumbs

[levacic]

Closes #35

[coveralls]

Coverage increased (+0.39%) when pulling 6e63e53 on levacic:custom-breadcrumb-options into a658ae7 on davejamesmiller:master.

[levacic]

Wasn't sure about the "data" vs. "options" naming inconsistency, so I just went with what you suggested in #35.

I think I would actually prefer to have a Breadcrumb class (each breadcrumb would be an instance of that class), with a __get() magic method to return the passed data, so you could do something like $breadcrumb->icon in your template - however, this might be a bit of an overkill, since the current solution is hardly less readable, and you're only gonna write your template once - it's not like you'll access individual breadcrumbs all over the place. So yeah, here's the PR, if anything needs to be fixed, just say so.

Cheers!

[d13r]

"data" does sound better so I'd be happy with that.

I like the $breadcrumb->icon shorthand idea. Perhaps it doesn't need a whole class though - you could do something like this instead:

         $this->breadcrumbs[] = (object) array_merge($data, array(
             'title' => $title,
             'url' => $url,
             // These will be altered later where necessary:
             'first' => false,
             'last' => false,
         ));

What do you think? Or is there any advantage to making a class for it? I'd be happy with that too.

Thanks!

[levacic]

One advantage in making a class might be more flexibility in handling breadcrumbs - we could, for example, add something like a hasOption($option) method that checks whether or not an option is passed to the breadcrumb, and option($option) which would throw an exception if the option isn't passed (this might make templates more readable, so we could avoid manual isset() checks).

Additionally, we could have a way for the user to set their own breadcrumb class (e.g. an entry in the config file, which is how many other packages do this), in which case this package would become slightly more generic, like some sort of a "breadcrumbs framework".

But honestly, after giving the idea further thought - unless someone actually has a good use case for such a level of abstraction, which isn't already covered by this package, I'd stay away from needlessly refactoring it, since it already performs the job nicely. The template for breadcrumbs is fairly simple, and I can't imagine it being much more complex, so it doesn't seem to me like there's a lot of benefit in trying too hard to make the package more generic.

Anyway, if you're okay with that, I'll make another PR with "options" changed to "data" everywhere, and change the behavior to use your suggested array_merge() solution, so we could simplify views a bit (this PR's source branch is custom-breadcrumb-options which I'd like to change too, and GitHub doesn't allow changing source/target branches for PRs).

[d13r]

That all sounds fine to me. 👍