[Catalyst] [RFC] refactoring of component resolution methods + warnings

Brian Cassidy brian.cassidy at nald.ca
Fri May 30 14:56:37 BST 2008

Hey All,

Further to my message from the 27th of May about component resolution, I 
have created a branch [1] to refactor how it works behind the scenes.

Here is the excerpt from my updates to the Changes file:

- Refactored component resolution (component(), models(), model(), et 
al). We now
   throw warnings for two reasons:
   1) model() or view() was called with no arguments, and two results 
are returned
      -- set default_(model|view), current_(model|view) or 
   2) you call a component resolution method with a string, and it 
resorts to a regexp
      fallback wherein a result is returned -- if you really want to 
search, call the
      method with a regex as the argument

In detail, I've gutted most of the private methods that were used for 
this task. In their place are 3 methods:

(1) _filter_component() -- this hasn't changed. it handles components 
(2) _comp_names() -- a slight implementation change. used, for example, 
when you need to grab all of the valid values for controllers.
(3) _comp_search_prefixes() -- this combines the old _comp_singular, 
_comp_explicit and _comp_search methods in to one method.

Although combining the 3 methods in to 1 sounds bad, the result is 32 
lines long -- 19 if you take out blank lines and comments.

Besides the refactoring, there is now an explicit regexp behavior for 
component searching. All of model(), view(), controller() and 
component() will accept a regexp and return (in list context) the matches.

Example from the docs:

# find all views that start with Foo
my @foo_views = $c->view(qr{^Foo});

FYI: all of the existing tests pass, plus I've added a number of new 
tests for the regexp behavior.

Please take a look and pass along your comments.



More information about the Catalyst mailing list