Hi Paul, Mainly a question for you. It looks to me like it's possible in rel_2_2 to define different mappings to the koha tables for different frameworks such that the editor ends up saving data to different fields depending on the definition. However, I don't see any search facility that uses frameworks to discover which fields to search. As a result, if you create an record using a framework that has mappings that disagree with the default framework, I'm assuming that the fields won't be searchable. If I'm correct, then we need to either: not allow frameworks to disagree on koha mappings or create a way to search using the alternate frameworks (seems very difficult). Let me know what you think ... Cheers, -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
Joshua Ferraro a écrit :
Hi Paul,
Mainly a question for you. It looks to me like it's possible in rel_2_2 to define different mappings to the koha tables for different frameworks such that the editor ends up saving data to different fields depending on the definition. However, I don't see any search facility that uses frameworks to discover which fields to search. As a result, if you create an record using a framework that has mappings that disagree with the default framework, I'm assuming that the fields won't be searchable. If I'm correct, then we need to either: not allow frameworks to disagree on koha mappings or create a way to search using the alternate frameworks (seems very difficult).
Let me know what you think ...
Cheers,
Seems you are right for the first part :
As a result, if you create an record using a framework that has mappings that disagree with the default framework, I'm assuming that the fields won't be searchable. For the second, not allow frameworks to disagree on koha mappings or create a way to search using the alternate frameworks (seems very difficult).
It doesnot sound to me (at first glance) THAT difficult to me as long as we use marc_biblio which contains a link with the biblio_framework. BUT we would have to store somewhere a hash of frameworks and tags/subfields with all the mappings (if exists) With mod_perl, this wouldnot be time consuming but without, could be ??? (I don't know) ... And maybe, since you are designing an API, it could be the moment to think over using XML files rather than Mysql to store frameworks. But this is another story... :D My two cents. PAUL?? -- Henri-Damien LAURENT
Joshua Ferraro a écrit :
Hi Paul,
Mainly a question for you. It looks to me like it's possible in rel_2_2 to define different mappings to the koha tables for different frameworks such that the editor ends up saving data to different fields depending on the definition. However, I don't see any search facility that uses frameworks to discover which fields to search. As a result, if you create an record using a framework that has mappings that disagree with the default framework, I'm assuming that the fields won't be searchable. If I'm correct, then we need to either: not allow frameworks to disagree on koha mappings or create a way to search using the alternate frameworks (seems very difficult).
Let me know what you think ...
Cheers,
Seems you are right for the first part :
As a result, if you create an record using a framework that has mappings that disagree with the default framework, I'm assuming that the fields won't be searchable. For the second, not allow frameworks to disagree on koha mappings or create a way to search using the alternate frameworks (seems very difficult).
It doesnot sound to me (at first glance) THAT difficult to me as long as we use marc_biblio which contains a link with the biblio_framework. BUT we would have to store somewhere a hash of frameworks and tags/subfields with all the mappings (if exists) With mod_perl, this wouldnot be time consuming but without, could be ??? (I don't know) ... I guess one question is, is there ever a use for having different mappings for different frameworks? What purpose is there having this
And maybe, since you are designing an API, it could be the moment to think over using XML files rather than Mysql to store frameworks. But this is another story... :D For the 3.0 API, I question whether we need as many mappings at all. It seems like we only need mappings for fields that Koha directly uses for circulation, reserves, etc. That is, bibid, authid, itemtype, etc. It may also be useful to have MARC::Record's $record->title() and $record->author() (and other such) stored purely for debugging
On Wed, Jul 26, 2006 at 09:57:22PM +0200, Henri-Damien LAURENT wrote: option? purposes (not used for display or search in any way, unless as a failover). -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
Hi all, I think the framework idea was quite fine but has been taken to the extreme. If frame works were used just as subsets of the default just to allow the cataloger to see the necessary fields depending on what they are cataloguing than its a wonderful idea. But the way it is being used is messing everything up. I suggest we keep the frameworks but change the usability to just closing and opening fields for editor purposes. Apart from that everything should be mapped in the default framework otherwise nobody will be able to search anything. Even with the new koha_attr table. That one i designed it so that it only looks in the default framewok if ever it need to lookup, otherwise god knows who wants to store where. So just simply remove the kohafield mapping from child frameworks and we can go ahead designing this new API. We may run into more problems later on if we just map title,author and itemtype when somebody comes who wants some other unusual field displayed on their serachresult templates later on. Well thats another cent of idea Cheers Tumer -----Original Message----- From: koha-devel-bounces+tgarip=neu.edu.tr@nongnu.org [mailto:koha-devel-bounces+tgarip=neu.edu.tr@nongnu.org] On Behalf Of Henri-Damien LAURENT Sent: Wednesday, July 26, 2006 10:57 PM To: Joshua Ferraro Cc: koha-devel@nongnu.org Subject: Re: [Koha-devel] Frameworks in rel_2_2 Joshua Ferraro a écrit :
Hi Paul,
Mainly a question for you. It looks to me like it's possible in rel_2_2 to define different mappings to the koha tables for different frameworks such that the editor ends up saving data to different fields depending on the definition. However, I don't see any search facility that uses frameworks to discover which fields to search. As a
result, if you create an record using a framework that has mappings that disagree with the default framework, I'm assuming that the fields
won't be searchable. If I'm correct, then we need to either: not allow
frameworks to disagree on koha mappings or create a way to search using the alternate frameworks (seems very difficult).
Let me know what you think ...
Cheers,
Seems you are right for the first part :
As a result, if you create an record using a framework that has mappings that disagree with the default framework, I'm assuming that the fields won't be searchable. For the second, not allow frameworks to disagree on koha mappings or create a way to search using the alternate frameworks (seems very difficult).
It doesnot sound to me (at first glance) THAT difficult to me as long as we use marc_biblio which contains a link with the biblio_framework. BUT we would have to store somewhere a hash of frameworks and tags/subfields with all the mappings (if exists) With mod_perl, this wouldnot be time consuming but without, could be ??? (I don't know) ... And maybe, since you are designing an API, it could be the moment to think over using XML files rather than Mysql to store frameworks. But this is another story... :D My two cents. PAUL?? -- Henri-Damien LAURENT _______________________________________________ Koha-devel mailing list Koha-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/koha-devel
Tümer Garip a écrit :
Hi all, I think the framework idea was quite fine but has been taken to the extreme. If frame works were used just as subsets of the default just to allow the cataloger to see the necessary fields depending on what they are cataloguing than its a wonderful idea. But the way it is being used is messing everything up. I suggest we keep the frameworks but change the usability to just closing and opening fields for editor purposes. Apart from that everything should be mapped in the default framework otherwise nobody will be able to search anything. Even with the new koha_attr table. That one i designed it so that it only looks in the default framewok if ever it need to lookup, otherwise god knows who wants to store where.
So just simply remove the kohafield mapping from child frameworks and we can go ahead designing this new API. We may run into more problems later on if we just map title,author and itemtype when somebody comes who wants some other unusual field displayed on their serachresult templates later on.
Well thats another cent of idea
Cheers Tumer
Well, then it is only a display problem... With a TMPL_IF if could be solved... ;) But what if user would like to : 1) get some default values for issues and some other with monographies (for instance) ? 2) get different lists to pick up values depending on the framework used ? I came across the question and said : Koha doesnot do that. Friendly yours. -- Henri-Damien LAURENT
Tümer Garip a écrit :
Hi all, I think the framework idea was quite fine but has been taken to the extreme. If frame works were used just as subsets of the default just to allow the cataloger to see the necessary fields depending on what they are cataloguing than its a wonderful idea. But the way it is being used is messing everything up. I suggest we keep the frameworks but change the usability to just closing and opening fields for editor purposes. Apart from that everything should be mapped in the default framework otherwise nobody will be able to search anything. Even with the new koha_attr table. That one i designed it so that it only looks in the default framewok if ever it need to lookup, otherwise god knows who wants to store where.
Tumer is completly right here : I just want to remind you that the frameworks did not exist in Koha 2.0. when I created them for 2.2, I go the the quickest -shame on me-, and just added a row in the structure tables, to select the framework. but in real life, the only interesting values in frameworks are the tab & the hidden ones (+ constraints like authorities, authorized values & plugins) All the values related to search construction are useless. More (or worst) than this, they are ignored if you modify them outside from default framework. If you modify a non default framework, you'll see that 1 (and only 1, we should have more probably) field don't appear, you get a "this is meaningful only for default value) For Koha 3, we could, it's true, separate frameworks (= display & input) from search setup (attset ...) -- Paul POULAIN et Henri Damien LAURENT Consultants indépendants en logiciels libres et bibliothéconomie (http://www.koha-fr.org) Tel : 04 91 31 45 19
participants (4)
-
Henri-Damien LAURENT -
Joshua Ferraro -
Paul POULAIN -
Tümer Garip