Re: [Koha-devel] Re: A Win32 circulation client (beginning stages)
Hi, [It seems that you are not cc'ing to the list.] On Sun, Jan 19, 2003 at 08:37:33PM +1300, Patrick Quinn-Graham wrote:
I've started to look at the circulation.pl script (certainly not the nicest of the perl scripts I've seen in my life time. Can some one tell me why it has to be _one_ script? Couldn't there be a borrower_prompt.pl issueing.pl issuebook.pl that would be way easier to read...) - and lots of things are pushed through to C4::Circulation::Circ2, so it could feasibly have a wrapper put around the necessary functions. Perhaps a WebService? I'm sure you can do those in Perl. I can't say I like sending things like that over the HTTP, even if it was going over https. Perhaps I just don't like programming in that model (open connection, make request, close connection).
yes, Koha's perl code is not very pretty. In 1.3.x Koha is being "templatized" (I mean separating the presentation from the code using HTML templates), and this is not finished yet; and unfortunately circulation.pl is one of those that has not yet gone through "templatization", so it is messier than most other scripts. There are quite a few other important scripts that are still "untemplatized" and thus can't be localized into another language. (Of course by this I don't mean Perl can't do localization any other way, just that the Koha developers had decided on a certain way to localize Koha.)
I'm not really familiar with getting perl to do something over a network other than through a webbrowser, so I don't know how much I could help in that regard.
If you don't mind working within the existing framework for the moment, then you don't have to worry about knowing how to send things over the network. A CGI-type script doesn't have to directly send things to the network; it only communicates with the web server using an API that involves only sending and receiving through standard input, standard output, and the environment (the CGI "protocol"). With perl you don't even need to worry about the input and the environment. Same thing with communicating with the SQL server; all is done through API's provided by classes.
A shame about the telnet-type-client being broken...
But then, a lot seems to be broken (using the web-based demo is kind of tragic, my local copy still gives JavaScript errors in the catalogue editing section).
Could you file a bug report in bugs.koha.org about these JavaScript errors?
My biggest issue right now: authenticating users... how does Koha do it? I can't quite seem to figure it out just by looking at the code.
I believe the logic is mostly in the C4::Auth module; of course the scripts need to be written a certain way in order for authentication to work. I believe the user names and passwords are in a MySQL table, and at the "browser" level the user sees it as a cookie-based authentication. -- Ambrose Li <a.c.li@ieee.org>
On Sun, Jan 19, 2003 at 03:07:59AM -0500, Ambrose Li said:
Hi,
[It seems that you are not cc'ing to the list.]
But then, a lot seems to be broken (using the web-based demo is kind of tragic, my local copy still gives JavaScript errors in the catalogue editing section).
Could you file a bug report in bugs.koha.org about these JavaScript errors?
Broken may be a little harsh, bearing in mind koha has been running the HLT library for 3 years now. And they still use the curses based client occasionally. It certainly has issues, mainly that the cdk library coredumps under load. It also hasnt had much love in the last 2 years. It shouldnt be very hard at all to write another curses/text based interface. All the logic needed is in C4::Circulation::Circ2. The scripts just have to handle the interface and program flow. The demo page is my fault, ive been using it to test new versions. I need to clean it out and do a clean install of 1.2.3rc26. This might get done this holiday weekend.
My biggest issue right now: authenticating users... how does Koha do it? I can't quite seem to figure it out just by looking at the code.
I believe the logic is mostly in the C4::Auth module; of course the scripts need to be written a certain way in order for authentication to work. I believe the user names and passwords are in a MySQL table, and at the "browser" level the user sees it as a cookie-based authentication.
2 ways. If http based authentication is being used, as is used at HLT for the librarian interface (specifically Apache::AuthDBI) the C4::Auth will not prompt the user to login again. Otherwise it uses a cookie based authentication. Cookies came about because of the need for users to be able to logout of the OPAC. Hope this helps Chris
-----Original Message----- From: Ambrose Li On Sun, Jan 19, 2003 at 08:37:33PM +1300, Patrick Quinn-Graham wrote:
I've started to look at the circulation.pl script (certainly
yes, Koha's perl code is not very pretty.
In 1.3.x Koha is being "templatized" (I mean separating the presentation from the code using HTML templates), and this is not finished yet; and unfortunately circulation.pl is one of those that has not yet gone through "templatization", so it is messier than most other scripts. There are quite a few other important scripts that are still "untemplatized" and thus can't be localized into another language.
That's got to be one of my sorepoints - I'm used to the way I code in PHP with Smarty to template all of my design from my content. Makes life a whole lot easier.
I'm not really familiar with getting perl to do something over a network other than through a webbrowser, so I don't know how much I could help in that regard.
If you don't mind working within the existing framework for the moment, then you don't have to worry about knowing how to send things over the network. A CGI-type script doesn't have to directly send things to the network; it only communicates with the web server using an API that involves only sending and receiving through standard input, standard output, and the environment (the CGI "protocol"). With perl you don't even need to worry about the input and the environment. Same thing with communicating with the SQL server; all is done through API's provided by classes.
I'm perfectly fine with CGI - what I meant by this was for communicating in ways other than over the web (as HTTP isn't the best for application requests really)
Could you file a bug report in bugs.koha.org about these JavaScript errors?
I'll go do that shortly.
My biggest issue right now: authenticating users... how does Koha do it? I can't quite seem to figure it out just by looking at the code.
I believe the logic is mostly in the C4::Auth module; of course the scripts need to be written a certain way in order for authentication to work. I believe the user names and passwords are in a MySQL table, and at the "browser" level the user sees it as a cookie-based authentication.
I'll go look at that now too. -- Patrick.
participants (3)
-
Ambrose Li -
Chris Cormack -
Patrick Quinn-Graham