[dancer-users] Dancer Advent Calendar 2015

Sawyer X xsawyerx at gmail.com
Sun Nov 1 15:46:47 GMT 2015


It sounds to me like you want to change the URLs in the DB and add a
small Rewrite Middleware around your app to change all older URLs to
the new scheme. Maybe one line of code for the rewrite, additional 2-3
for wrapping it with Plack::Builder (if you aren't already) in order
to enable the middleware.

On Fri, Oct 30, 2015 at 5:16 PM, John Stoffel <john at stoffel.org> wrote:
>
> Sawyer> Taking two steps back from the current position of this
> Sawyer> thread, I think John is raising a valid point here: He uses
> Sawyer> Dancer in a certain way. It might not be the responsibility of
> Sawyer> the main documentation to document his usage, but it would be
> Sawyer> nice to have an article which does.
>
> Thanks for the vote of confidence in my needs/wants, I appreciate it.
>
> Sawyer> We hope to have the Dancer Advent Calendar cover new features
> Sawyer> and tips, but also useful articles - whether they are
> Sawyer> Dancer-specific or around the perimeter of Dancer usage (like
> Sawyer> a service or website written in it, or an example on a common
> Sawyer> application usage).
>
> Another subject for the calendar just hit me yesterday.  My wife's
> website has a column in the DB called 'url' which is just what it
> says, a long ass URL pointing to image(s) for a record.  They moved
> them, so the URL had to change.
>
> I ended up doing a quick:
>
>   <% a.url = a.url.replace('old','new') %>
>
> inside the view, but I know that this isn't really the best way, since
> it puts application logic into the view.
>
> I really should A) fix the damn DB to 1) have the correct URL or 2)
> just have the single parameter number I really need listed, with the
> rest of the URL built since the .pm file.
>
> But I did this because it was simpler than messing about with the
> results returned from the Dancer::Plugin::DBIC when doing the query.
>
> Basically, I do the ultra simple:
>
>   if (length $query) {
>     @results = _perform_search($regexp,$limit);
>   }
>
>   template 'search', { query => $query,
>                        regexp => $regexp,
>                        tobold => $tobold,
>                        results => \@results,
>                        count => $#results+1,
>                        #limit => $limit,
>                        title => "Search the Collection",
>                      };
> };
>
>
> Where my query is simply:
>
>   my @r = $schema->resultset('Name')->search( { full_name =>
>                                                 { regexp =>
>                                                 '[[:<:]]'.$regexp.'[[:>:]]'
>                                                 }
>                                               },
>                                               {
>                                                order_by => { -asc =>
>                                                'full_name' },
>                                                prefetch => 'account',
>                                                #rows => $limit,
>                                               })->all;
>   return @r;
>
>
> And yes, I need to convert this to a FULLTEXT match instead to speed
> it up.
>
> But!! The key idea was to fun a simple foreach loop on @results and
> massage the data.  But since it's down two levels, it was a pain.
>
> So, after all this ... maybe I should just write an actual article on
> the tradeoffs of doing work in the view vs doing it in the
> controller.  It's ideal to do it all in the controller, but sometimes
> the view is simpler...
>
> Comments?
> John
> _______________________________________________
> dancer-users mailing list
> dancer-users at dancer.pm
> http://lists.preshweb.co.uk/mailman/listinfo/dancer-users


More information about the dancer-users mailing list