Le 12/12/2011 17:24, Ian Walls a écrit :
My difficulty with this patch is that it sets precedent for implementing both commandline and staff client interfaces for a single script. Up until now, that's not be the case (as far as my research has shown; counter-examples welcome). I just think we need, for consistency sake, to either make this the standard practice, or require separate cronjobs.
So, I don't have any issue with the feature, but the potential shift in coding practices that the patch represents. Is the rest of the Koha developer community comfortable with having dual-purpose scripts like this? Are there are any best practices that can be cited for or against such practice?
Cheers,
-Ian
Hi, in my opinion, it is not "dual-purpose" script, command-line or web interface, it is the same process you want. duplicating code and editing to make the code commandline compliant would be far harder to maintain and keep synched than having the script callable via command-line and web. In my opinion, we have enough exemples of copy paste edit code in Koha, to see how un maintainable that behaviour is and to be willing to restrain from that from now on. This is my opinion. cheers -- Henri-Damien LAURENT
On Mon, Dec 12, 2011 at 11:07 AM, Paul Poulain <paul.poulain@biblibre.com <mailto:paul.poulain@biblibre.com>> wrote:
Le 12/12/2011 14:06, Marcel de Rooy a écrit : > Hi all, > Patch 5636 should be next in passing qa now, but these questions > remained open: > Style question to the community: should core pages in the staff client > (like > > tools/cleanborrowers.pl <http://cleanborrowers.pl>) have both a templated page in the staff client > AND a > command-line presence, or should the commandline tool be a separate > script in misc/? > At this time, there doesn't seem to be any precedent for inclusion in > the core > > script. Before passing this patch for QA, I'd like to get some feedback, as > this may both open doors for us, as well as create additional work to create > consistency of implementation for existing jobs.
My comment here : if an ENH don't break any existing behaviour, do what it announces, and is consistent with existing features and code, then we must welcome any patch and don't request for an improvement of the improvement: if you want more, just do it yourself, everybody is acting on a volunteer basis !
In this case (speaking as RM here, not as owner of the company submitting the patch ;-) ), it should just be "passed QA", as it passes the 3 questions: don't break existing behaviour, do what it announces, consistent with existing feature & code. (double check if there can be a security issue !)
-- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
-- Ian Walls Lead Development Specialist ByWater Solutions ALA Midwinter Booth #2048 Phone # (888) 900-8944 http://bywatersolutions.com ian.walls@bywatersolutions.com <mailto:ian.walls@bywatersolutions.com> Twitter: @sekjal
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/