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@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@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users