https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37815

--- Comment #2 from David Cook <[email protected]> ---
(In reply to David Cook from comment #1)
> This is a good reminder that we need to do more in modules and less in Perl
> scripts.

Looking again at members/memberentry.pl, this is how we create a patron:

Koha::Patron->new( \%newdata )->store( { guarantors => \@guarantors } );

I keep coming up with designs and then forgetting them because of other
priorities, but something like...

try {
  Koha::Patron->create({
    user => $user,
    data => $newdata,
    guarantors => $guarantors,
  });
} catch {
  #blah blah blah
}

Maybe even a "policy" attribute if we want to compute things like system
preferences in advance for better performance on bulk changes.

Or maybe we update the "new" constructor to take a user object. 

In theory, the controller should just be managing input/output. 

--

But... that's easy for me to say. Doing that kind of refactoring is a huge pain
so we let inertia keep us going with the status quo...

Maybe there's some kind of transitional middleground we just haven't thought of
yet. I know there's other bugs for doing data validation. It's something that
needs to happen at some point, but we'll need a good design and some agreement.
I think the scariest bit is actually the perceived effort in doing UI work for
the exception handling...

I'm actually doing some local work on restrictions. Maybe I'll have a think
about a lightweight way to start doing this which can be gently applied...
hmmm...

Anyway, I'll get off my soapbox heh.

-- 
You are receiving this mail because:
You are watching all bug changes.
You are the assignee for the bug.
_______________________________________________
Koha-bugs mailing list
[email protected]
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Reply via email to