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/