Do you have a roadmap/plan for the transition to TT? This process also seems like a good time to start separating out the monolithic "get_template_and_user" function. It would be very handy and allow for more elegant design if we were able to specify the template just prior to rendering it rather than at the very beginning. One method of breaking up the circularity that appears in many areas of Koha is by splitting functions out in a MVC-style arrangement. If you're finding yourself tempted to introduce a circularity in your data schema, it's often the case that that relationship can be expressed through a View or Controller class instead. Having worked with Catalyst, it's a fine framework, but it's cumbersome and not worth porting existing code to. If writing an app from the ground up it would be a consideration. Clay 2010/11/4 Chris Cormack <chrisc@catalyst.net.nz>
* Kyle Hall (kyle.m.hall@gmail.com) wrote:
How much work would it be to move Koha to the Catalyst framework? Kyle
Only a complete rewrite.
The work we are doing with Plack and Starman will give us a persistent environment, that will, in all likelihood outperform any framework unless it was also running under Plack.
Back to DBIx::Class, I have no plans to use it for anything other than schema abstraction for 3.4. April 22 isn't far away. However if someone sends in patches for a module that uses DBIx::Class and we don't take a big performance hit, (and it passes QA and the rest of the tests) it would go in.
Small steps, we have a 6 month release, getting Template::Toolkit, Schema abstraction, C4/Search fixes, all the RFC in is going to be enough. Lets work on small manageable improvements. Anyone who wanted to work on finding the circular object references we have, and breaking them would move us a lot closer to being able to run the whole of Koha under a persistent tool.
Currently people are testing with the Opac, and circulation, with good results.
Chris
http://www.kylehall.info Mill Run Technology Solutions ( http://millruntech.com ) Crawford County Federated Library System ( http://www.ccfls.org ) Meadville Public Library ( http://www.meadvillelibrary.org )
On Wed, Oct 27, 2010 at 2:27 AM, Frederic Demians <frederic@tamil.fr> wrote:
My experience is that the startup overhead introduced by DBIx::Class is not sufficiently offset by its caching features in a CGI environment. Running under Plack or something similar would easily recoup that overhead, of course.
Yes, this is the solution. We need in 2010 a persistent environment to execute Koha in: an execution environment, in which they are application-level, session and page objects Memcaching everything isn't the solution. -- Frederic
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
_______________________________________________ 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/
-- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux)
iEYEARECAAYFAkzTCNkACgkQZgbcHEvgMLMERACfaf1UurKAXRc+yZ+t4ie5n2dg FPwAnRfenGuZCDlW8j2SK4Z0Ydy04v2v =odUu -----END PGP SIGNATURE-----
_______________________________________________ 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/