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
Created attachment 6794 [details] [review] Add a new directory for the Koha:: namespace Suggested patch to kick off the move.
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
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>
While running this patch, I see that the first file in Koha module dir, Koha::Template::Plugin::KohaDates, contains a use C4::Dates !
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.
(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)
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.
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.
(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?
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
(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..
QA Comment: One liner. But vital for new Koha module dir. Marked as Passed QA.
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 ?)
Paul, Yes, you understand correctly.