pm structure : Acquisition.pm modifications
the Acquisition.pm (aka : Catalogue.pm for MARC version) contains too much subs imho. It's hard to read, and not always very coherent : sub addwebsite { sub basket { sub bookfundbreakdown { sub bookfunds { sub bookseller { sub branches { sub breakdown { sub curconvert { sub deletebiblioitem { sub deletewebsite { sub delorder { sub findall { sub getallorders { sub getbiblio { sub getbiblioitem { sub getbiblioitembybiblionumber { sub getcurrencies { sub getcurrency { sub getitemsbybiblioitem { sub getitemtypes { sub getorders { sub getrecorders { sub getsingleorder { sub insertsup { sub invoice { sub isbnsearch { sub modaddauthor { sub modbibitem { sub modbiblio { sub moditem { sub modnote { sub modorder { sub modsubject { sub modsubtitle { sub newbasket { sub newbiblio { sub newbiblioitem { sub newitems { sub neworder { sub newordernum { sub newsubject { sub newsubtitle { sub ordersearch { sub receiveorder { sub updatecurrencies { sub updatesup { sub updatewebsite { sub websitesearch { It contains sub used to administer biblios (addBiblio, addBiblioitem, addItem, modBiblio...) and sub used to administer loans and orders. I propose to divide the script in 2 differents ones. the first would be Biblio.pm (used only for biblio management : biblio/biblioitems/items/additionalauthor/subtitle tables), the second would remain Acquisition.pm (Catalogue.pm for MARC) Is there someone against this idea ? -- Paul
On Mon, Jun 10, 2002 at 10:35:58PM +0200, paul POULAIN wrote:
the Acquisition.pm (aka : Catalogue.pm for MARC version) contains too much subs imho. It's hard to read, and not always very coherent :
I propose to divide the script in 2 differents ones. the first would be Biblio.pm (used only for biblio management : biblio/biblioitems/items/additionalauthor/subtitle tables), the second would remain Acquisition.pm (Catalogue.pm for MARC)
I like the idea of separating the routines for biblio handling from the routines for order processing. If the proposed Catalogue.pm is going to handle Marc record processing, which is biblio information, doesn't that mean that Catalogue.pm would replace Biblio.pm, not Acquisition.pm? Better yet, instead of replacing Biblio.pm later, it could perhaps turn into a higher-level abstraction of Catalogue.pm - Alan ---- Alan Millar --==> am12@bolis.com <==--
(pate puts on his Unit Testing hat.) On Mon, 10 Jun 2002, Alan Millar wrote:
On Mon, Jun 10, 2002 at 10:35:58PM +0200, paul POULAIN wrote:
the Acquisition.pm (aka : Catalogue.pm for MARC version) contains too much subs imho. It's hard to read, and not always very coherent :
I propose to divide the script in 2 differents ones. the first would be Biblio.pm (used only for biblio management : biblio/biblioitems/items/additionalauthor/subtitle tables), the second would remain Acquisition.pm (Catalogue.pm for MARC)
I like the idea of separating the routines for biblio handling from the routines for order processing. If the proposed Catalogue.pm is going to handle Marc record processing, which is biblio information, doesn't that mean that Catalogue.pm would replace Biblio.pm, not Acquisition.pm?
As we split subroutines out into new files, let's please try to write tests for them using the Test::Harness framework. Being able to run a testsuite automagically and verify that we've not added new bugs will help all of us sleep better at night. -pate
Better yet, instead of replacing Biblio.pm later, it could perhaps turn into a higher-level abstraction of Catalogue.pm
- Alan
---- Alan Millar --==> am12@bolis.com <==--
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink
_______________________________________________ Koha-devel mailing list Koha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/koha-devel
Pat Eyler wrote:
(pate puts on his Unit Testing hat.)
On Mon, Jun 10, 2002 at 10:35:58PM +0200, paul POULAIN wrote:
the Acquisition.pm (aka : Catalogue.pm for MARC version) contains too much subs imho. It's hard to read, and not always very coherent :
I propose to divide the script in 2 differents ones. the first would be Biblio.pm (used only for biblio management : biblio/biblioitems/items/additionalauthor/subtitle tables), the second would remain Acquisition.pm (Catalogue.pm for MARC)
I like the idea of separating the routines for biblio handling from the routines for order processing. If the proposed Catalogue.pm is going to handle Marc record processing, which is biblio information, doesn't that mean that Catalogue.pm would replace Biblio.pm, not Acquisition.pm?
As we split subroutines out into new files, let's please try to write tests for them using the Test::Harness framework. Being able to run a testsuite automagically and verify that we've not added new bugs will help all of us sleep better at night.
If my great-loved-super-hyper-best benevolent dictator agree, for instance, i'll just split the file in 2. Test::harness will come later. If my benevolent dictator disagree to this solution, he can do this f@#{#@g job himself ;-))) -- Paul
On Tue, 11 Jun 2002, paul POULAIN wrote:
Pat Eyler wrote:
(pate puts on his Unit Testing hat.)
On Mon, Jun 10, 2002 at 10:35:58PM +0200, paul POULAIN wrote:
the Acquisition.pm (aka : Catalogue.pm for MARC version) contains too much subs imho. It's hard to read, and not always very coherent :
I propose to divide the script in 2 differents ones. the first would be Biblio.pm (used only for biblio management : biblio/biblioitems/items/additionalauthor/subtitle tables), the second would remain Acquisition.pm (Catalogue.pm for MARC)
I like the idea of separating the routines for biblio handling from the routines for order processing. If the proposed Catalogue.pm is going to handle Marc record processing, which is biblio information, doesn't that mean that Catalogue.pm would replace Biblio.pm, not Acquisition.pm?
As we split subroutines out into new files, let's please try to write tests for them using the Test::Harness framework. Being able to run a testsuite automagically and verify that we've not added new bugs will help all of us sleep better at night.
If my great-loved-super-hyper-best benevolent dictator agree, for instance, i'll just split the file in 2. Test::harness will come later. If my benevolent dictator disagree to this solution, he can do this f@#{#@g job himself ;-)))
you split, and I'll work on tests ... then when the framework is built and we all have time on our hands, we can sit around and write tests and eat milk and honey ... ;) -pate
-- Paul
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink
_______________________________________________ Koha-devel mailing list Koha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/koha-devel
participants (3)
-
Alan Millar -
Pat Eyler -
paul POULAIN