Bug 7359 - Begin migration to a new "Koha" namespace from the old "C4" namespace
Summary: Begin migration to a new "Koha" namespace from the old "C4" namespace
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Architecture, internals, and plumbing (show other bugs)
Version: 3.6
Hardware: All All
: P1 - high critical (vote)
Assignee: Galen Charlton
QA Contact: Marcel de Rooy
URL:
Keywords:
Depends on:
Blocks: 929 5549 7248
  Show dependency treegraph
 
Reported: 2011-12-14 15:33 UTC by Chris Nighswonger
Modified: 2019-06-27 09:24 UTC (History)
5 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Add a new directory for the Koha:: namespace (2.13 KB, patch)
2011-12-14 19:24 UTC, Chris Nighswonger
Details | Diff | Splinter Review
Bug 7359 - Begin migration to a new "Koha" namespace from the old "C4" namespace (2.20 KB, patch)
2011-12-31 02:03 UTC, Jared Camins-Esakov
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Nighswonger 2011-12-14 15:33:31 UTC
2011/3/30 Ian Walls <ian.walls at bywatersolutions.com>:
> All this indicate to me that we REALLY need to start thinking about imposing
> some kind of structure on C4.  I'm thinking something with two-levels:
>
> Level 1 :  Calls to the database, other direct interaction with stored data
> Level 2:   Calls to Level 1 functions to manipulate data

Thanks for doing the analysis.  Regarding the overall project of
restructuring C4, I suggest a slightly different way of looking at it:
*not* restructuring C4 as such, but using it as a springboard for its
successor.

In other words, we'd still be creating a better structure, just in a
different namespace.  Let's pick a name randomly for that namespace.
I reach into my hat and pull out ... "Koha".  Fancy that. :)

The Koha namespace would be for Perl modules that meet the following
mandatory conditions:

- usable by mod_perl (or its equivalent)
- export the minimum number of routines necessary
- follow stricture, warnings, documentation, and test case standards
- separating data access methods from business logic

and preferably the following optional conditions:

- purely OO

Obviously, the conditions and whether they would be mandatory or
optional is a topic for discussion.

Modules in C4 could use (and would be encouraged to use) routines in
the Koha namespace.  Modules in Koha could not in general use C4
modules; any C4 module that was safe to be depended on by a Koha
module would be a candidate for being renamed to Koha.

The advantage of carving out a new namespace is that it doesn't
require that we refactor the entirety of C4 to support persistance or
to untangle the dependency tree.  Instead, the only C4 code we would
have to reimplement for the Koha namespace right away would be
authentication, basic session management, and basic output.  That,
along with data access using DBIx::Class, would allow us to start
using mod_perl right away for specific functions.  One example of
something that would then be easy to transform to a service running
under mod_perl would be the unapi and OAI-PMH services.  As
functionality gets detangled from C4 and moved into Koha, we can
increase the number of services running under mod_perl while still
keeping the CGI scripts that still depend on C4.

Regards,

Galen
Comment 1 Chris Nighswonger 2011-12-14 19:24:23 UTC Comment hidden (obsolete)
Comment 2 Magnus Enger 2011-12-15 08:35:24 UTC
This is a topic for the General IRC Meeting, 4 January 2012: 
http://wiki.koha-community.org/wiki/General_IRC_Meeting,_4_January_2012

See also: http://wiki.koha-community.org/wiki/Namespace_QA_Rules
Comment 3 Jared Camins-Esakov 2011-12-31 02:03:12 UTC
Created attachment 6987 [details] [review]
Bug 7359 - Begin migration to a new "Koha" namespace from the old "C4" namespace

The Koha namespace is for Perl modules that meet the following mandatory
conditions:

* use "strict" and "warning" pragmata
* include valid POD
* include complete and functioning documented test cases
* not create circular dependencies
* use Object Oriented (OO) style everywhere possible
* minimize exports
* maintain mod_perl, etc. compatibility
* separate data access methods from business logic

Modules in C4 can use (and are encouraged to use) routines in
the Koha namespace.  Modules in Koha should not in general use C4
modules; any C4 module that is safe to be depended on by a Koha
module is a candidate for being renamed to Koha.

The advantage of carving out a new namespace is that it doesn't
require that we refactor the entirety of C4 to support persistance or
to untangle the dependency tree.  Instead, the only C4 code we would
have to reimplement for the Koha namespace right away would be
authentication, basic session management, and basic output.

(Gratuitous use made of gmcharlt's recommendations found in the
post mentioned below.)

Related info:

http://lists.koha-community.org/pipermail/koha-devel/2011-March/035302.html
http://wiki.koha-community.org/wiki/Namespace_QA_Rules

Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Comment 4 Marcel de Rooy 2012-01-26 14:26:22 UTC
While running this patch, I see that the first file in Koha module dir, Koha::Template::Plugin::KohaDates, contains a use C4::Dates !
Comment 5 Chris Cormack 2012-01-26 15:17:47 UTC
Yep, C4::Dates is one of the very few clean ones, (along with C4::Debug and C4::Context).

They are the ones that don't cause any circular dependencies. Now the namespace has been created, someone could easily copy C4::Dates to Koha::Dates, and patch that.

It was hard enough just getting the plugin in, I saw what happened to Jared's 1633 patch so wasn't going to waste time moving C4::Dates if it was going to be rejected.
Comment 6 Paul Poulain 2012-01-26 17:08:14 UTC
(In reply to comment #5)

> They are the ones that don't cause any circular dependencies.
Just a reminder: bug 6875 contains many patches that try to remove circular dependancies as much as possible. Some patches don't apply anymore (i plan to rebase), but some still applies and could be signed-off. All those patches are independant (unless otherwise stated)
Comment 7 Jared Camins-Esakov 2012-01-30 01:24:08 UTC
This needs to be pushed to both Master and Stable. As of right now, all non-dev installs ARE BROKEN. The patch for Bug 929 added Koha/Template/Plugin/KohaDates.pm, but without the patch for this bug, that file will not be installed. This is true for 3.4.x, 3.6.x, and 3.7.x.
Comment 8 Chris Cormack 2012-01-30 04:28:24 UTC
Actually its not that bad, precisely 2 pages will be broken, the 2 that use the new plugin. ANd the rest of Koha just keeps working

You get this error
http://192.168.2.135:8080/cgi-bin/koha/acqui/ordered.pl?fund=229&fund_code=BF

But
Everything else works just fine. 

But yes this should be pushed, to get rid of the error on those two pages.
Comment 9 Marcel de Rooy 2012-01-30 07:54:24 UTC
(In reply to comment #7)
> This needs to be pushed to both Master and Stable. As of right now, all non-dev
> installs ARE BROKEN.

Maybe I overlook something, but it seems to me that the standard install already is broken before this patch?? I tested it a few times but I seem not to come past installing ERROR: Can't create '/etc/zzz' while that should be DESTDIR/usr/share/koha/zzz/etc ..

Can you confirm?
Comment 10 Chris Cormack 2012-01-30 07:56:05 UTC
Was that during make, or make install

if make install, sudo is needed for that

It seemed to work fine for me, barring the error on the 2 new pages introduced by 929
Comment 11 Marcel de Rooy 2012-01-30 07:58:57 UTC
(In reply to comment #9)
> Maybe I overlook something, but it seems to me that the standard install
> already is broken before this patch?
Appears so. Matter of rights..
Comment 12 Marcel de Rooy 2012-01-30 08:09:12 UTC
QA Comment: One liner. But vital for new Koha module dir. Marked as Passed QA.
Comment 13 Paul Poulain 2012-01-30 21:00:51 UTC
I'm not sure I fully understand what/why it fixes the problem, but patch pushed
(it add /Koha directory in the PERL_MODULE directory, with C4. Before this patch /Koha stays in the scope of .pl, and is not found by use Koha/blabla; Am I right ?)
Comment 14 Jared Camins-Esakov 2012-01-30 21:02:29 UTC
Paul,

Yes, you understand correctly.