OOP versus non-OOP? Should we put this to a list-wide vote, or is there some
sort of policy encouraging one way or the other? I know that Koha as it
stands is not generally object-oriented, but established conventions don't
always reflect policy.
In any case, here's my vote:
+1 No OOP
-1 OOP
I'm not a programmer, but am a Librarian... What about the 028 music/av item
numbers(often ISBN's are not part of a video record as they may change) but
often the producer number stays the same. I'll also mention a SuDoc number
index, but I don't use them so will walk away now and hope nobody is
Most Excellent! That is exactly what I need!
Thanks!
Nicole Engard wrote:
>
> You know, I have to go do training tomorrow and they have one staff
> member who they only want editing items - this sounds like the perfect
> fit for them. Just thought I'd chime in :)
>
> Nicole
>
> On Tue, May
On Wed, May 14, 2008 at 2:43 PM, Jesse <[EMAIL PROTECTED]> wrote:
> Eek. There's already a... plethora of modules in C4::. At the very least, we
> would be adding C4::ISBN, C4::OCLC and C4::LCCN. If we really need an OOP
> interface (seems like overkill for the simple reformatting this would be
> d
On Wed, May 14, 2008 at 2:41 PM, Henri-Damien LAURENT
<[EMAIL PROTECTED]> wrote:
> I am not really going in for that.
> Having pieces written in OO and others in procedural mode is not really
> good for me.
> Unless we get into a work of rewriting the code into OO Programming,
> which would be
> For some reason, emails from liblime.com aren't reaching me promptly
> today, so I'll reply to both of the above at once:-
>
> I suspect C4::Normalize would have poor cohesion (probably logical
> cohesion) so would prefer creating C4::ISBN and similar, with methods
> like new($), raw(), normal(),
On Wed, May 14, 2008 at 2:15 PM, MJ Ray <[EMAIL PROTECTED]> wrote:
> I suspect C4::Normalize would have poor cohesion (probably logical
> cohesion) so would prefer creating C4::ISBN and similar, with methods
> like new($), raw(), normal(), display() and so on.
If we're voting, I'm voting for an
Galen Charlton a écrit :
> Hi,
>
>
Hi,
I also think this could be a good thing to have a C4::Normalize. (Maybe
not for 3.0)
Maybe we could broaden the scope.
UTF8 Normalize,
Normalizing publication dates and acquisition dates, and prices, and
maybe even itemcallnumber could also enter this modul
Jesse <[EMAIL PROTECTED]> wrote:
[ Galen wrote (I think):]
> > Yes, I think this should be moved to C4. I've been noodling around
> > with the notion of creating a C4::Normalize or the like to centralize
> > these kinds of normalizations (as ISSNs, LC card numbers, OCLC
> > numbers, etc. could ben
Hi,
On Wed, May 14, 2008 at 1:59 PM, Jesse <[EMAIL PROTECTED]> wrote:
> Do you think we could also put standard formatting of these types of numbers
> in there, and make a naming scheme?
>
> Example:
>
> ISBNInternalForm('0-7434-3602-4') eq '0743436024'
> ISBNDisplayForm('0743436024') eq '0-7434-
Woops, forgot to CC the list.
Yes, I think this should be moved to C4. I've been noodling around
> with the notion of creating a C4::Normalize or the like to centralize
> these kinds of normalizations (as ISSNs, LC card numbers, OCLC
> numbers, etc. could benefit from this as well), but haven't d
Hi Frederic,
Many thanks for your useful feedback! My comments and questions follow inline:
On Wed, May 14, 2008 at 6:32 PM, Frederic Demians <[EMAIL PROTECTED]> wrote:
> > 18:01:28-14/05 zebraidx(22552) [warn] Index 'char-encoding' not found
> > in attset(s)
> > 18:01:28-14/05 zebraidx(22552) [
Hi,
On Wed, May 14, 2008 at 12:32 PM, MJ Ray <[EMAIL PROTECTED]> wrote:
> Joe Atzberger <[EMAIL PROTECTED]> wrote: [...]
> > +++ b/opac/opac-detail.pl
> [...]
> > +sub isbn_cleanup ($) {
[snip]
> Should this be moved into C4 somewhere, expanded to strip non-[0-9X]s
> and convert UPC barcodes
Joe Atzberger <[EMAIL PROTECTED]> wrote: [...]
> +++ b/opac/opac-detail.pl
[...]
> +sub isbn_cleanup ($) {
> + my $isbn=shift;
> + if (
> + $isbn =~ /\b(\d{13})\b/ or
> + $isbn =~ /\b(\d{10})\b/ or
> + $isbn =~ /\b(\d{9}X)\b/i
> + ) {
> +
> 18:01:28-14/05 zebraidx(22552) [warn] Index 'tpubdate' not found in
> attset(s)
> 18:01:28-14/05 zebraidx(22552) [warn] Index 'Modified-code' not found
> in attset(s)
> 18:01:28-14/05 zebraidx(22552) [warn] Index 'char-encoding' not found
> in attset(s)
> 18:01:28-14/05 zebraidx(22552) [warn] I
Hi Kyle,
On Wed, May 14, 2008 at 5:27 PM, Kyle Hall <[EMAIL PROTECTED]> wrote:
> > Have you tried running rebuild-zebra.pl ? Run that, then search for your
> items.
> My bad, the file is rebuild_zebra.pl with an underscore, not a dash.
Thanks for your help. Yes, I have run rebuild_zebra.pl. He
Another dependency I have seen on my recent installation on Debian Etch
is for Image::Magick. It is better to do an apt-get install of
perlmagick.
John
+-+
John Chadwick, Ed.D. Information Technology Manager
New Mexico State Library
"Joshua Ferraro" <[EMAIL PROTECTED]> wrote:
> On Mon, May 12, 2008 at 5:08 PM, MJ Ray <[EMAIL PROTECTED]> wrote:
> > Sorry for posting before reaching the end of the thread but I'd much
> > prefer the next RM to be from a different enterprise and country from
> > the last, to preserve the streng
By bad, the file is rebuild_zebra.pl with an underscore, not a dash.
Kyle
On Wed, May 14, 2008 at 12:26 PM, Kyle Hall <[EMAIL PROTECTED]> wrote:
> Have you tried running rebuild-zebra.pl ? Run that, then search for your
> items.
>
> Kyle
>
> On Wed, May 14, 2008 at 6:59 AM, Ricardo Dias Marques
Have you tried running rebuild-zebra.pl ? Run that, then search for your items.
Kyle
On Wed, May 14, 2008 at 6:59 AM, Ricardo Dias Marques
<[EMAIL PROTECTED]> wrote:
> Hi Galen,
>
> First of all, thank you very much for trying to help. My comments follow
> inline:
>
> On Tue, May 13, 2008, Galen
Thanks for reporting this. I have sent a patch to correct Makefile.PL.
-- Joe Atzberger
On Wed, May 14, 2008 at 9:21 AM, Zeno Tajoli <[EMAIL PROTECTED]> wrote:
> Hi to all,
>
> I have installed Koha 3 beta 2 with all new fix availables on git.
> I use debian
> I have installed koha in 'dev' mode
Hi,
On Tue, May 13, 2008 at 3:56 PM, Paul POULAIN <[EMAIL PROTECTED]> wrote:
> Galen Charlton a écrit :
>
> > As Joshua mentioned, I currently work on nothing but Koha, spending
> > perhaps three quarters of my time on development and bugfixing and a
> > quarter on customer migration projects.
>
> Lloyd and I have been discussing a feature to automatically email
> account details to patrons upon account creation.
> The primary details are the user's userird and password.
I think this is a great idea.
> There may be a few sysprefs needed for this feature, but initially
> just the one will
Hi Galen,
First of all, thank you very much for trying to help. My comments follow inline:
On Tue, May 13, 2008, Galen Charlton <[EMAIL PROTECTED]> wrote:
> >
> > tcp:@:11001
> >
> > /var/lib/koha/zebradb/biblios
> > /etc/koha/zebradb/zebra-biblios.cfg
> > /etc/koha/zebrad
Hi All,
Lloyd and I have been discussing a feature to automatically email
account details to patrons upon account creation.
The primary details are the user's userird and password.
The feature will need to have the ability to manage (eg: add/edit/
save) an account-creation email - per branch.
Hi to all,
I have installed Koha 3 beta 2 with all new fix availables on git.
I use debian
I have installed koha in 'dev' mode
Until now all is working.
During test I have found a new perl module required (only for test):
HTML::Scrubber
It is used in C4::Scrubber.pm
It isn't listed in Makefile.PL
"Joshua Ferraro" <[EMAIL PROTECTED]> wrote:
> On Tue, May 13, 2008 at 11:25 AM, MJ Ray <[EMAIL PROTECTED]> wrote:
> > To be clear, I don't mean anyone posted the above as deception, but it
> > is now chock-full of false statements that koha.org is making.
>
> MJ, I find these kinds of posts by y
27 matches
Mail list logo
