mirrors/zotero
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
zotero/components/zotero-service.js

234 lines
6.9 KiB
JavaScript
Raw Normal View History

Merged 1.0 branch back to trunk
2007-10-23 07:11:59 +00:00
const ZOTERO_CONTRACTID = '@zotero.org/Zotero;1';
Sorry, it was now or never, and now is better: Changed "Scholar" to "Zotero", everywhere Apologies to anyone with working copy changes, but there are probably the fewer at this moment than there will be again. Hopefully this won't break anything, though existing prefs will be lost. I avoided scholar.google.com--if you know any other legitimate "scholar"s in the code, be sure to fix them once I'm done here. This is a multi-commit change--there's at least one more coming. *Do not update to this version! It won't work!*
2006-10-02 23:15:27 +00:00
const ZOTERO_CLASSNAME = 'Zotero';
const ZOTERO_CID = Components.ID('{e4c61080-ec2d-11da-8ad9-0800200c9a66}');
Merged 1.0 branch back to trunk
2007-10-23 07:11:59 +00:00
const ZOTERO_IID = Components.interfaces.chnmIZoteroService; //unused
- Implemented singleton XPCOM component to store core Scholar objects More details coming on Basecamp: http://chnm.grouphub.com/W161222 *** Important note: after checking out this code, be sure to delete the compreg.dat and xpti.dat files in your FF profile directory or else the extension will not load. They'll be regenerated when you start FF again, and you won't have to do it again unless we add interfaces or other components. Once I set up the XPI packaging system, this step won't be necessary. *** - Localization properties are now loaded directly via nsIStringBundleService and available via Scholar.getString(name) -- removed stringbundle from XUL - Updated status line in bottom right to reflect whether Scholar is loaded correctly or not (temporary, obviously)
2006-05-27 00:20:27 +00:00
const Cc = Components.classes;
const Ci = Components.interfaces;
// Assign the global scope to a variable to passed via wrappedJSObject
Sorry, it was now or never, and now is better: Changed "Scholar" to "Zotero", everywhere Apologies to anyone with working copy changes, but there are probably the fewer at this moment than there will be again. Hopefully this won't break anything, though existing prefs will be lost. I avoided scholar.google.com--if you know any other legitimate "scholar"s in the code, be sure to fix them once I'm done here. This is a multi-commit change--there's at least one more coming. *Do not update to this version! It won't work!*
2006-10-02 23:15:27 +00:00
var ZoteroWrapped = this;
- Implemented singleton XPCOM component to store core Scholar objects More details coming on Basecamp: http://chnm.grouphub.com/W161222 *** Important note: after checking out this code, be sure to delete the compreg.dat and xpti.dat files in your FF profile directory or else the extension will not load. They'll be regenerated when you start FF again, and you won't have to do it again unless we add interfaces or other components. Once I set up the XPI packaging system, this step won't be necessary. *** - Localization properties are now loaded directly via nsIStringBundleService and available via Scholar.getString(name) -- removed stringbundle from XUL - Updated status line in bottom right to reflect whether Scholar is loaded correctly or not (temporary, obviously)
2006-05-27 00:20:27 +00:00
/********************************************************************
* Include the core objects to be stored within XPCOM
*********************************************************************/
Cc["@mozilla.org/moz/jssubscript-loader;1"]
.getService(Ci.mozIJSSubScriptLoader)
OK, this might be it, assuming I got the build script right
2006-10-03 00:29:42 +00:00
.loadSubScript("chrome://zotero/content/xpcom/zotero.js");
- Implemented singleton XPCOM component to store core Scholar objects More details coming on Basecamp: http://chnm.grouphub.com/W161222 *** Important note: after checking out this code, be sure to delete the compreg.dat and xpti.dat files in your FF profile directory or else the extension will not load. They'll be regenerated when you start FF again, and you won't have to do it again unless we add interfaces or other components. Once I set up the XPI packaging system, this step won't be necessary. *** - Localization properties are now loaded directly via nsIStringBundleService and available via Scholar.getString(name) -- removed stringbundle from XUL - Updated status line in bottom right to reflect whether Scholar is loaded correctly or not (temporary, obviously)
2006-05-27 00:20:27 +00:00
Cc["@mozilla.org/moz/jssubscript-loader;1"]
.getService(Ci.mozIJSSubScriptLoader)
OK, this might be it, assuming I got the build script right
2006-10-03 00:29:42 +00:00
.loadSubScript("chrome://zotero/content/xpcom/db.js");
- Implemented singleton XPCOM component to store core Scholar objects More details coming on Basecamp: http://chnm.grouphub.com/W161222 *** Important note: after checking out this code, be sure to delete the compreg.dat and xpti.dat files in your FF profile directory or else the extension will not load. They'll be regenerated when you start FF again, and you won't have to do it again unless we add interfaces or other components. Once I set up the XPI packaging system, this step won't be necessary. *** - Localization properties are now loaded directly via nsIStringBundleService and available via Scholar.getString(name) -- removed stringbundle from XUL - Updated status line in bottom right to reflect whether Scholar is loaded correctly or not (temporary, obviously)
2006-05-27 00:20:27 +00:00
Made the schema update system moderately less convoluted - Broke schema functions into separate object and got rid of DB_VERSION config constant in favor of a toVersion variable in the _migrateSchema command (which isn't technically necessary either, since the version number at the top of schema.sql is now always compared to the DB version at startup) but will help reduce the chance that someone will update the schema file without adding migration steps) - Removed Amazon scraper from schema.sql, as it will be loaded with the rest of the scrapers
2006-06-07 01:02:59 +00:00
Cc["@mozilla.org/moz/jssubscript-loader;1"]
.getService(Ci.mozIJSSubScriptLoader)
OK, this might be it, assuming I got the build script right
2006-10-03 00:29:42 +00:00
.loadSubScript("chrome://zotero/content/xpcom/schema.js");
Made the schema update system moderately less convoluted - Broke schema functions into separate object and got rid of DB_VERSION config constant in favor of a toVersion variable in the _migrateSchema command (which isn't technically necessary either, since the version number at the top of schema.sql is now always compared to the DB version at startup) but will help reduce the chance that someone will update the schema file without adding migration steps) - Removed Amazon scraper from schema.sql, as it will be loaded with the rest of the scrapers
2006-06-07 01:02:59 +00:00
- Implemented singleton XPCOM component to store core Scholar objects More details coming on Basecamp: http://chnm.grouphub.com/W161222 *** Important note: after checking out this code, be sure to delete the compreg.dat and xpti.dat files in your FF profile directory or else the extension will not load. They'll be regenerated when you start FF again, and you won't have to do it again unless we add interfaces or other components. Once I set up the XPI packaging system, this step won't be necessary. *** - Localization properties are now loaded directly via nsIStringBundleService and available via Scholar.getString(name) -- removed stringbundle from XUL - Updated status line in bottom right to reflect whether Scholar is loaded correctly or not (temporary, obviously)
2006-05-27 00:20:27 +00:00
Cc["@mozilla.org/moz/jssubscript-loader;1"]
.getService(Ci.mozIJSSubScriptLoader)
OK, this might be it, assuming I got the build script right
2006-10-03 00:29:42 +00:00
.loadSubScript("chrome://zotero/content/xpcom/data_access.js");
- Implemented singleton XPCOM component to store core Scholar objects More details coming on Basecamp: http://chnm.grouphub.com/W161222 *** Important note: after checking out this code, be sure to delete the compreg.dat and xpti.dat files in your FF profile directory or else the extension will not load. They'll be regenerated when you start FF again, and you won't have to do it again unless we add interfaces or other components. Once I set up the XPI packaging system, this step won't be necessary. *** - Localization properties are now loaded directly via nsIStringBundleService and available via Scholar.getString(name) -- removed stringbundle from XUL - Updated status line in bottom right to reflect whether Scholar is loaded correctly or not (temporary, obviously)
2006-05-27 00:20:27 +00:00
Moving Scholar.Attachments to its own file
2006-10-02 21:41:38 +00:00
Cc["@mozilla.org/moz/jssubscript-loader;1"]
.getService(Ci.mozIJSSubScriptLoader)
OK, this might be it, assuming I got the build script right
2006-10-03 00:29:42 +00:00
.loadSubScript("chrome://zotero/content/xpcom/attachments.js");
Moving Scholar.Attachments to its own file
2006-10-02 21:41:38 +00:00
Item.inCollection(collectionID) -- test if an item belongs to a given collection (currently uses a DB call--I'll optimize that later) Scholar.Notifier framework to handle update notifications between data layer and interface - Notifier.registerColumnTree(ref) and Notifier.registerItemTree(ref) pass back a unique hash that can be used to unregister the tree later with unregister*(hash) (and must be, lest we leak treeViews and probably entire browser windows if the browser window is closed without unregistering the treeView) - Data layer calls Scholar.Notify.trigger(event, type, id) after various events (only two calls in the data layer at the moment--more coming later) - Notify.trigger() calls notify(event, type, id) on all registered trees of the appropriate type -- the data layer usually knows what collection the action pertains to, but we decided that it's cleaner to just let the tree decide what it wants to do rather than add all that logic into the data layer) (Note: Item collection adds appear to be buggy on the interface side, but removes seem to be working)
2006-06-01 20:03:53 +00:00
Cc["@mozilla.org/moz/jssubscript-loader;1"]
.getService(Ci.mozIJSSubScriptLoader)
OK, this might be it, assuming I got the build script right
2006-10-03 00:29:42 +00:00
.loadSubScript("chrome://zotero/content/xpcom/notifier.js");
Item.inCollection(collectionID) -- test if an item belongs to a given collection (currently uses a DB call--I'll optimize that later) Scholar.Notifier framework to handle update notifications between data layer and interface - Notifier.registerColumnTree(ref) and Notifier.registerItemTree(ref) pass back a unique hash that can be used to unregister the tree later with unregister*(hash) (and must be, lest we leak treeViews and probably entire browser windows if the browser window is closed without unregistering the treeView) - Data layer calls Scholar.Notify.trigger(event, type, id) after various events (only two calls in the data layer at the moment--more coming later) - Notify.trigger() calls notify(event, type, id) on all registered trees of the appropriate type -- the data layer usually knows what collection the action pertains to, but we decided that it's cleaner to just let the tree decide what it wants to do rather than add all that logic into the data layer) (Note: Item collection adds appear to be buggy on the interface side, but removes seem to be working)
2006-06-01 20:03:53 +00:00
Scholar.History -- i.e. undo/redo functionality Partially integrated into data layer, but I'm waiting to commit that part until I'm sure it won't break everything
2006-06-22 14:01:54 +00:00
Cc["@mozilla.org/moz/jssubscript-loader;1"]
.getService(Ci.mozIJSSubScriptLoader)
OK, this might be it, assuming I got the build script right
2006-10-03 00:29:42 +00:00
.loadSubScript("chrome://zotero/content/xpcom/history.js");
Scholar.History -- i.e. undo/redo functionality Partially integrated into data layer, but I'm waiting to commit that part until I'm sure it won't break everything
2006-06-22 14:01:54 +00:00
Closes #7, Add advanced search functionality to data layer Implemented advanced/saved search architecture -- to use, you create a new search with var search = new Scholar.Search(), add conditions to it with addCondition(condition, operator, value), and run it with search(). The standard conditions with their respective operators can be retrieved with Scholar.SearchConditions.getStandardConditions(). Others are for special search flags and can be specified as follows (condition, operator, value): 'context', null, collectionIDToSearchWithin 'recursive', 'true'|'false' (as strings!--defaults to false if not specified, though, so should probably just be removed if not wanted), null 'joinMode', 'any'|'all', null For standard conditions, currently only 'title' and the itemData fields are supported -- more coming soon. Localized strings created for the standard search operators API: search.setName(name) -- must be called before save() on new searches search.load(savedSearchID) search.save() -- saves search to DB and returns a savedSearchID search.addCondition(condition, operator, value) search.updateCondition(searchConditionID, condition, operator, value) search.removeCondition(searchConditionID) search.getSearchCondition(searchConditionID) -- returns a specific search condition used in the search search.getSearchConditions() -- returns search conditions used in the search search.search() -- runs search and returns an array of item ids for results search.getSQL() -- will be used by Dan for search-within-search Scholar.Searches.getAll() -- returns an array of saved searches with 'id' and 'name', in alphabetical order Scholar.Searches.erase(savedSearchID) -- deletes a given saved search from the DB Scholar.SearchConditions.get(condition) -- get condition data (operators, etc.) Scholar.SearchConditions.getStandardConditions() -- retrieve conditions for use in drop-down menu (as opposed to special search flags) Scholar.SearchConditions.hasOperator() -- used by Dan for error-checking
2006-08-08 02:04:02 +00:00
Cc["@mozilla.org/moz/jssubscript-loader;1"]
.getService(Ci.mozIJSSubScriptLoader)
OK, this might be it, assuming I got the build script right
2006-10-03 00:29:42 +00:00
.loadSubScript("chrome://zotero/content/xpcom/search.js");
Closes #7, Add advanced search functionality to data layer Implemented advanced/saved search architecture -- to use, you create a new search with var search = new Scholar.Search(), add conditions to it with addCondition(condition, operator, value), and run it with search(). The standard conditions with their respective operators can be retrieved with Scholar.SearchConditions.getStandardConditions(). Others are for special search flags and can be specified as follows (condition, operator, value): 'context', null, collectionIDToSearchWithin 'recursive', 'true'|'false' (as strings!--defaults to false if not specified, though, so should probably just be removed if not wanted), null 'joinMode', 'any'|'all', null For standard conditions, currently only 'title' and the itemData fields are supported -- more coming soon. Localized strings created for the standard search operators API: search.setName(name) -- must be called before save() on new searches search.load(savedSearchID) search.save() -- saves search to DB and returns a savedSearchID search.addCondition(condition, operator, value) search.updateCondition(searchConditionID, condition, operator, value) search.removeCondition(searchConditionID) search.getSearchCondition(searchConditionID) -- returns a specific search condition used in the search search.getSearchConditions() -- returns search conditions used in the search search.search() -- runs search and returns an array of item ids for results search.getSQL() -- will be used by Dan for search-within-search Scholar.Searches.getAll() -- returns an array of saved searches with 'id' and 'name', in alphabetical order Scholar.Searches.erase(savedSearchID) -- deletes a given saved search from the DB Scholar.SearchConditions.get(condition) -- get condition data (operators, etc.) Scholar.SearchConditions.getStandardConditions() -- retrieve conditions for use in drop-down menu (as opposed to special search flags) Scholar.SearchConditions.hasOperator() -- used by Dan for error-checking
2006-08-08 02:04:02 +00:00
XPCOM-ize ingester, fix swapped first and last name in ingested info, stop ingesting pages field (this should be for pages of the source used, not the total number of pages, right?)
2006-06-02 03:19:12 +00:00
Cc["@mozilla.org/moz/jssubscript-loader;1"]
.getService(Ci.mozIJSSubScriptLoader)
OK, this might be it, assuming I got the build script right
2006-10-03 00:29:42 +00:00
.loadSubScript("chrome://zotero/content/xpcom/ingester.js");
addresses #78, figure out import/export architecture - changes scrapers table to translators table; all import/export/web translators now belong in this table - adds Scholar.Translate to handle translation issues. eventually, Scholar.Ingester.Document will become part of this interface - adds Scholar_File_Interface (in fileInterface.js) to handle UI for export and eventually import. (David, when you have time, please connect Scholar_File_Interface.exportFile to a button.) - adds an export translator for MODS. all of our metadata, but not our hierarchy (projects, etc.) translates directly and unambiguously into valid MODS. eventually, we can use RDF or another format to handle hierarchy. - adds utilities.getVersion() and utilities.inArray() for simplified scraper coding - fixes minor interface issues with the nifty chrome scraping status window
2006-06-29 00:56:50 +00:00
Cc["@mozilla.org/moz/jssubscript-loader;1"]
.getService(Ci.mozIJSSubScriptLoader)
OK, this might be it, assuming I got the build script right
2006-10-03 00:29:42 +00:00
.loadSubScript("chrome://zotero/content/xpcom/translate.js");
make generic Scholar.Utilities class and HTTP-dependent Scholar.Utilities.Ingester and Scholar.Utilities.HTTP classes in preparation for import/export filters; split off into separate javascript file
2006-06-26 14:46:57 +00:00
references #110, implement CSL for citation styling add Scholar.Cite and Scholar.CSL for parsing items into a bibliography using CSL. unfortunately, the output is not very good at the moment, and the format likely needs some changes, but I'm working with a few other people on getting it to that point.
2006-07-22 01:25:46 +00:00
Cc["@mozilla.org/moz/jssubscript-loader;1"]
.getService(Ci.mozIJSSubScriptLoader)
OK, this might be it, assuming I got the build script right
2006-10-03 00:29:42 +00:00
.loadSubScript("chrome://zotero/content/xpcom/cite.js");
references #110, implement CSL for citation styling add Scholar.Cite and Scholar.CSL for parsing items into a bibliography using CSL. unfortunately, the output is not very good at the moment, and the format likely needs some changes, but I'm working with a few other people on getting it to that point.
2006-07-22 01:25:46 +00:00
Merged 1.0 branch back to trunk
2007-10-23 07:11:59 +00:00
Cc["@mozilla.org/moz/jssubscript-loader;1"]
.getService(Ci.mozIJSSubScriptLoader)
.loadSubScript("chrome://zotero/content/xpcom/cite_compat.js");
Cc["@mozilla.org/moz/jssubscript-loader;1"]
.getService(Ci.mozIJSSubScriptLoader)
.loadSubScript("chrome://zotero/content/xpcom/quickCopy.js");
Cc["@mozilla.org/moz/jssubscript-loader;1"]
.getService(Ci.mozIJSSubScriptLoader)
.loadSubScript("chrome://zotero/content/xpcom/report.js");
Cc["@mozilla.org/moz/jssubscript-loader;1"]
.getService(Ci.mozIJSSubScriptLoader)
.loadSubScript("chrome://zotero/content/xpcom/timeline.js");
make generic Scholar.Utilities class and HTTP-dependent Scholar.Utilities.Ingester and Scholar.Utilities.HTTP classes in preparation for import/export filters; split off into separate javascript file
2006-06-26 14:46:57 +00:00
Cc["@mozilla.org/moz/jssubscript-loader;1"]
.getService(Ci.mozIJSSubScriptLoader)
OK, this might be it, assuming I got the build script right
2006-10-03 00:29:42 +00:00
.loadSubScript("chrome://zotero/content/xpcom/utilities.js");
Add library, hooks for scraping MARC records.
2006-06-03 22:26:01 +00:00
add basic Word integration. to see it in action, copy Zotero.dot to Microsoft Office 2004/Office/Startup/Word. if the gods are with you, you should see a new toolbar the next time you open Word. not yet implemented: - formatted in-text citations, rather than placeholders - footnotes - selection of citation style (for now, only APA is available) - support for non-ASCII characters - exclusion of notes from select items window - Windows support (although it shouldn't be difficult) - probably much more...
2006-08-28 05:38:37 +00:00
Cc["@mozilla.org/moz/jssubscript-loader;1"]
.getService(Ci.mozIJSSubScriptLoader)
OK, this might be it, assuming I got the build script right
2006-10-03 00:29:42 +00:00
.loadSubScript("chrome://zotero/content/xpcom/integration.js");
add basic Word integration. to see it in action, copy Zotero.dot to Microsoft Office 2004/Office/Startup/Word. if the gods are with you, you should see a new toolbar the next time you open Word. not yet implemented: - formatted in-text citations, rather than placeholders - footnotes - selection of citation style (for now, only APA is available) - support for non-ASCII characters - exclusion of notes from select items window - Windows support (although it shouldn't be difficult) - probably much more...
2006-08-28 05:38:37 +00:00
Fix #191, calling Scholar.Attachments.importFromURL on a PDF without PDF plug-in installed results in a prompt to save the file to the disk Attachments.importFromURL() now first does a HEAD request to get the MIME type and passes that through Scholar.MIME.hasInternalHandler() (now abstracted from Scholar.File, along with the other MIME functions) -- if it can handle the MIME type, it uses a hidden browser; otherwise, it use a remote web page persist to save the file directly
2006-08-19 20:51:01 +00:00
Cc["@mozilla.org/moz/jssubscript-loader;1"]
.getService(Ci.mozIJSSubScriptLoader)
OK, this might be it, assuming I got the build script right
2006-10-03 00:29:42 +00:00
.loadSubScript("chrome://zotero/content/xpcom/file.js");
Fix #191, calling Scholar.Attachments.importFromURL on a PDF without PDF plug-in installed results in a prompt to save the file to the disk Attachments.importFromURL() now first does a HEAD request to get the MIME type and passes that through Scholar.MIME.hasInternalHandler() (now abstracted from Scholar.File, along with the other MIME functions) -- if it can handle the MIME type, it uses a hidden browser; otherwise, it use a remote web page persist to save the file directly
2006-08-19 20:51:01 +00:00
Fulltext search support There are currently two types of fulltext searching: an SQL-based word index and a file scanner. They each have their advantages and drawbacks. The word index is very fast to search and is currently used for the find-as-you-type quicksearch. However, indexing files takes some time, so we should probably offer a preference to turn it off ("Index attachment content for quicksearch" or something). There's also an issue with Chinese characters (which are indexed by character rather than word, since there are no spaces to go by, so a search for a word with common characters could produce erroneous results). The quicksearch doesn't use a left-bound index (since that would probably upset German speakers searching for "musik" in "nachtmusik," though I don't know for sure how they think of words) but still seems pretty fast. * Note: There will be a potentially long delay when you start Firefox with this revision as it builds a fulltext word index of your existing items. We obviously need a notification/option for this. * The file scanner, used in the Attachment Content condition of the search dialog, offers phrase searching as well as regex support (both case-sensitive and not, and defaulting to multiline). It doesn't require an index, though it should probably be optimized to use the word index, if available, for narrowing the results when not in regex mode. (It does only scan files that pass all the other search conditions, which speeds it up considerably for multi-condition searches, and skips non-text files unless instructed otherwise, but it's still relatively slow.) Both convert HTML to text before searching (with the exception of the binary file scanning mode). There are some issues with which files get indexed and which don't that we can't do much about and that will probably confuse users immensely. Dan C. suggested some sort of indicator (say, a green dot) to show which files are indexed. Also added (very ugly) charset detection (anybody want to figure out getCharsetFromString(str)?), a setTimeout() replacement in the XPCOM service, an arrayToHash() method, and a new header to timedtextarea.xml, since it's really not copyright CHNM (it's really just a few lines off from the toolkit timed-textbox binding--I tried to change it to extend timed-textbox and just ignore Return keypress events so that we didn't need to duplicate the Mozilla code, but timed-textbox's reliance on html:input instead of html:textarea made things rather difficult). To do: - Pref/buttons to disable/clear/rebuild fulltext index - Hidden prefs to set maximum file size to index/scan - Don't index words of fewer than 3 non-Asian characters - MRU cache for saved searches - Use word index if available to narrow search scope of fulltext scanner - Cache attachment info methods - Show content excerpt in search results (at least in advanced search window, when it exists) - Notification window (a la scraping) to show when indexing - Indicator of indexed status - Context menu option to index - Indicator that a file scanning search is in progress, if possible - Find other ways to make it index the NYT front page in under 10 seconds - Probably fix lots of bugs, which you will likely start telling me about...now.
2006-09-21 00:10:29 +00:00
Cc["@mozilla.org/moz/jssubscript-loader;1"]
.getService(Ci.mozIJSSubScriptLoader)
OK, this might be it, assuming I got the build script right
2006-10-03 00:29:42 +00:00
.loadSubScript("chrome://zotero/content/xpcom/fulltext.js");
Fulltext search support There are currently two types of fulltext searching: an SQL-based word index and a file scanner. They each have their advantages and drawbacks. The word index is very fast to search and is currently used for the find-as-you-type quicksearch. However, indexing files takes some time, so we should probably offer a preference to turn it off ("Index attachment content for quicksearch" or something). There's also an issue with Chinese characters (which are indexed by character rather than word, since there are no spaces to go by, so a search for a word with common characters could produce erroneous results). The quicksearch doesn't use a left-bound index (since that would probably upset German speakers searching for "musik" in "nachtmusik," though I don't know for sure how they think of words) but still seems pretty fast. * Note: There will be a potentially long delay when you start Firefox with this revision as it builds a fulltext word index of your existing items. We obviously need a notification/option for this. * The file scanner, used in the Attachment Content condition of the search dialog, offers phrase searching as well as regex support (both case-sensitive and not, and defaulting to multiline). It doesn't require an index, though it should probably be optimized to use the word index, if available, for narrowing the results when not in regex mode. (It does only scan files that pass all the other search conditions, which speeds it up considerably for multi-condition searches, and skips non-text files unless instructed otherwise, but it's still relatively slow.) Both convert HTML to text before searching (with the exception of the binary file scanning mode). There are some issues with which files get indexed and which don't that we can't do much about and that will probably confuse users immensely. Dan C. suggested some sort of indicator (say, a green dot) to show which files are indexed. Also added (very ugly) charset detection (anybody want to figure out getCharsetFromString(str)?), a setTimeout() replacement in the XPCOM service, an arrayToHash() method, and a new header to timedtextarea.xml, since it's really not copyright CHNM (it's really just a few lines off from the toolkit timed-textbox binding--I tried to change it to extend timed-textbox and just ignore Return keypress events so that we didn't need to duplicate the Mozilla code, but timed-textbox's reliance on html:input instead of html:textarea made things rather difficult). To do: - Pref/buttons to disable/clear/rebuild fulltext index - Hidden prefs to set maximum file size to index/scan - Don't index words of fewer than 3 non-Asian characters - MRU cache for saved searches - Use word index if available to narrow search scope of fulltext scanner - Cache attachment info methods - Show content excerpt in search results (at least in advanced search window, when it exists) - Notification window (a la scraping) to show when indexing - Indicator of indexed status - Context menu option to index - Indicator that a file scanning search is in progress, if possible - Find other ways to make it index the NYT front page in under 10 seconds - Probably fix lots of bugs, which you will likely start telling me about...now.
2006-09-21 00:10:29 +00:00
Fix #191, calling Scholar.Attachments.importFromURL on a PDF without PDF plug-in installed results in a prompt to save the file to the disk Attachments.importFromURL() now first does a HEAD request to get the MIME type and passes that through Scholar.MIME.hasInternalHandler() (now abstracted from Scholar.File, along with the other MIME functions) -- if it can handle the MIME type, it uses a hidden browser; otherwise, it use a remote web page persist to save the file directly
2006-08-19 20:51:01 +00:00
Cc["@mozilla.org/moz/jssubscript-loader;1"]
.getService(Ci.mozIJSSubScriptLoader)
OK, this might be it, assuming I got the build script right
2006-10-03 00:29:42 +00:00
.loadSubScript("chrome://zotero/content/xpcom/mime.js");
Fix #191, calling Scholar.Attachments.importFromURL on a PDF without PDF plug-in installed results in a prompt to save the file to the disk Attachments.importFromURL() now first does a HEAD request to get the MIME type and passes that through Scholar.MIME.hasInternalHandler() (now abstracted from Scholar.File, along with the other MIME functions) -- if it can handle the MIME type, it uses a hidden browser; otherwise, it use a remote web page persist to save the file directly
2006-08-19 20:51:01 +00:00
closes #209, Scholar does not refresh the item pane when a new collection is clicked it's possible that this fix will introduce some bugs, but it appears to work fine
2006-08-25 19:15:03 +00:00
Cc["@mozilla.org/moz/jssubscript-loader;1"]
.getService(Ci.mozIJSSubScriptLoader)
OK, this might be it, assuming I got the build script right
2006-10-03 00:29:42 +00:00
.loadSubScript("chrome://zotero/content/xpcom/itemTreeView.js");
closes #209, Scholar does not refresh the item pane when a new collection is clicked it's possible that this fix will introduce some bugs, but it appears to work fine
2006-08-25 19:15:03 +00:00
Cc["@mozilla.org/moz/jssubscript-loader;1"]
.getService(Ci.mozIJSSubScriptLoader)
OK, this might be it, assuming I got the build script right
2006-10-03 00:29:42 +00:00
.loadSubScript("chrome://zotero/content/xpcom/collectionTreeView.js");
closes #209, Scholar does not refresh the item pane when a new collection is clicked it's possible that this fix will introduce some bugs, but it appears to work fine
2006-08-25 19:15:03 +00:00
Copied out scraping progress window for general use -- I'll use this for fulltext indexing notification, and ideally the scraper will use this instead now (Simon, let me know if there's any problem with that) Example usage: var windowWatcher = Components.classes["@mozilla.org/embedcomp/window-watcher;1"]. getService(Components.interfaces.nsIWindowWatcher); var progress = new Scholar.ProgressWindow(windowWatcher.activeWindow); progress.changeHeadline('Indexing item...'); progress.addLines(['All About Foo'], ['chrome://scholar/skin/treeitem-book.png']); progress.addDescription('Bar bar bar bar bar'); progress.show(); progress.fade();
2006-09-21 07:54:18 +00:00
Cc["@mozilla.org/moz/jssubscript-loader;1"]
.getService(Ci.mozIJSSubScriptLoader)
OK, this might be it, assuming I got the build script right
2006-10-03 00:29:42 +00:00
.loadSubScript("chrome://zotero/content/xpcom/progressWindow.js");
Copied out scraping progress window for general use -- I'll use this for fulltext indexing notification, and ideally the scraper will use this instead now (Simon, let me know if there's any problem with that) Example usage: var windowWatcher = Components.classes["@mozilla.org/embedcomp/window-watcher;1"]. getService(Components.interfaces.nsIWindowWatcher); var progress = new Scholar.ProgressWindow(windowWatcher.activeWindow); progress.changeHeadline('Indexing item...'); progress.addLines(['All About Foo'], ['chrome://scholar/skin/treeitem-book.png']); progress.addDescription('Bar bar bar bar bar'); progress.show(); progress.fade();
2006-09-21 07:54:18 +00:00
Merged 1.0 branch back to trunk
2007-10-23 07:11:59 +00:00
Cc["@mozilla.org/moz/jssubscript-loader;1"]
.getService(Ci.mozIJSSubScriptLoader)
.loadSubScript("chrome://zotero/content/xpcom/annotate.js");
closes #209, Scholar does not refresh the item pane when a new collection is clicked it's possible that this fix will introduce some bugs, but it appears to work fine
2006-08-25 19:15:03 +00:00
Cc["@mozilla.org/moz/jssubscript-loader;1"]
.getService(Ci.mozIJSSubScriptLoader)
.loadSubScript("chrome://global/content/nsTransferable.js");
Cc["@mozilla.org/moz/jssubscript-loader;1"]
.getService(Ci.mozIJSSubScriptLoader)
.loadSubScript("chrome://global/content/nsDragAndDrop.js");
- Implemented singleton XPCOM component to store core Scholar objects More details coming on Basecamp: http://chnm.grouphub.com/W161222 *** Important note: after checking out this code, be sure to delete the compreg.dat and xpti.dat files in your FF profile directory or else the extension will not load. They'll be regenerated when you start FF again, and you won't have to do it again unless we add interfaces or other components. Once I set up the XPI packaging system, this step won't be necessary. *** - Localization properties are now loaded directly via nsIStringBundleService and available via Scholar.getString(name) -- removed stringbundle from XUL - Updated status line in bottom right to reflect whether Scholar is loaded correctly or not (temporary, obviously)
2006-05-27 00:20:27 +00:00
/********************************************************************/
Sorry, it was now or never, and now is better: Changed "Scholar" to "Zotero", everywhere Apologies to anyone with working copy changes, but there are probably the fewer at this moment than there will be again. Hopefully this won't break anything, though existing prefs will be lost. I avoided scholar.google.com--if you know any other legitimate "scholar"s in the code, be sure to fix them once I'm done here. This is a multi-commit change--there's at least one more coming. *Do not update to this version! It won't work!*
2006-10-02 23:15:27 +00:00
// Initialize the Zotero service
- Implemented singleton XPCOM component to store core Scholar objects More details coming on Basecamp: http://chnm.grouphub.com/W161222 *** Important note: after checking out this code, be sure to delete the compreg.dat and xpti.dat files in your FF profile directory or else the extension will not load. They'll be regenerated when you start FF again, and you won't have to do it again unless we add interfaces or other components. Once I set up the XPI packaging system, this step won't be necessary. *** - Localization properties are now loaded directly via nsIStringBundleService and available via Scholar.getString(name) -- removed stringbundle from XUL - Updated status line in bottom right to reflect whether Scholar is loaded correctly or not (temporary, obviously)
2006-05-27 00:20:27 +00:00
//
Sorry, it was now or never, and now is better: Changed "Scholar" to "Zotero", everywhere Apologies to anyone with working copy changes, but there are probably the fewer at this moment than there will be again. Hopefully this won't break anything, though existing prefs will be lost. I avoided scholar.google.com--if you know any other legitimate "scholar"s in the code, be sure to fix them once I'm done here. This is a multi-commit change--there's at least one more coming. *Do not update to this version! It won't work!*
2006-10-02 23:15:27 +00:00
// This runs when ZoteroService is first requested.
- Implemented singleton XPCOM component to store core Scholar objects More details coming on Basecamp: http://chnm.grouphub.com/W161222 *** Important note: after checking out this code, be sure to delete the compreg.dat and xpti.dat files in your FF profile directory or else the extension will not load. They'll be regenerated when you start FF again, and you won't have to do it again unless we add interfaces or other components. Once I set up the XPI packaging system, this step won't be necessary. *** - Localization properties are now loaded directly via nsIStringBundleService and available via Scholar.getString(name) -- removed stringbundle from XUL - Updated status line in bottom right to reflect whether Scholar is loaded correctly or not (temporary, obviously)
2006-05-27 00:20:27 +00:00
// Calls to other XPCOM components must be in here rather than in top-level
// code, as other components may not have yet been initialized.
function setupService(){
Sorry, it was now or never, and now is better: Changed "Scholar" to "Zotero", everywhere Apologies to anyone with working copy changes, but there are probably the fewer at this moment than there will be again. Hopefully this won't break anything, though existing prefs will be lost. I avoided scholar.google.com--if you know any other legitimate "scholar"s in the code, be sure to fix them once I'm done here. This is a multi-commit change--there's at least one more coming. *Do not update to this version! It won't work!*
2006-10-02 23:15:27 +00:00
Zotero.init();
- Implemented singleton XPCOM component to store core Scholar objects More details coming on Basecamp: http://chnm.grouphub.com/W161222 *** Important note: after checking out this code, be sure to delete the compreg.dat and xpti.dat files in your FF profile directory or else the extension will not load. They'll be regenerated when you start FF again, and you won't have to do it again unless we add interfaces or other components. Once I set up the XPI packaging system, this step won't be necessary. *** - Localization properties are now loaded directly via nsIStringBundleService and available via Scholar.getString(name) -- removed stringbundle from XUL - Updated status line in bottom right to reflect whether Scholar is loaded correctly or not (temporary, obviously)
2006-05-27 00:20:27 +00:00
}
Sorry, it was now or never, and now is better: Changed "Scholar" to "Zotero", everywhere Apologies to anyone with working copy changes, but there are probably the fewer at this moment than there will be again. Hopefully this won't break anything, though existing prefs will be lost. I avoided scholar.google.com--if you know any other legitimate "scholar"s in the code, be sure to fix them once I'm done here. This is a multi-commit change--there's at least one more coming. *Do not update to this version! It won't work!*
2006-10-02 23:15:27 +00:00
function ZoteroService(){
this.wrappedJSObject = ZoteroWrapped.Zotero;
- Implemented singleton XPCOM component to store core Scholar objects More details coming on Basecamp: http://chnm.grouphub.com/W161222 *** Important note: after checking out this code, be sure to delete the compreg.dat and xpti.dat files in your FF profile directory or else the extension will not load. They'll be regenerated when you start FF again, and you won't have to do it again unless we add interfaces or other components. Once I set up the XPI packaging system, this step won't be necessary. *** - Localization properties are now loaded directly via nsIStringBundleService and available via Scholar.getString(name) -- removed stringbundle from XUL - Updated status line in bottom right to reflect whether Scholar is loaded correctly or not (temporary, obviously)
2006-05-27 00:20:27 +00:00
setupService();
}
/**
* Convenience method to replicate window.alert()
**/
function alert(msg){
Cc["@mozilla.org/embedcomp/prompt-service;1"]
.getService(Ci.nsIPromptService)
.alert(null, "", msg);
}
window.confirm() replacement for XPCOM
2006-06-01 21:57:12 +00:00
/**
* Convenience method to replicate window.confirm()
**/
function confirm(msg){
return Cc["@mozilla.org/embedcomp/prompt-service;1"]
.getService(Ci.nsIPromptService)
.confirm(null, "", msg);
}
- Implemented singleton XPCOM component to store core Scholar objects More details coming on Basecamp: http://chnm.grouphub.com/W161222 *** Important note: after checking out this code, be sure to delete the compreg.dat and xpti.dat files in your FF profile directory or else the extension will not load. They'll be regenerated when you start FF again, and you won't have to do it again unless we add interfaces or other components. Once I set up the XPI packaging system, this step won't be necessary. *** - Localization properties are now loaded directly via nsIStringBundleService and available via Scholar.getString(name) -- removed stringbundle from XUL - Updated status line in bottom right to reflect whether Scholar is loaded correctly or not (temporary, obviously)
2006-05-27 00:20:27 +00:00
Fulltext search support There are currently two types of fulltext searching: an SQL-based word index and a file scanner. They each have their advantages and drawbacks. The word index is very fast to search and is currently used for the find-as-you-type quicksearch. However, indexing files takes some time, so we should probably offer a preference to turn it off ("Index attachment content for quicksearch" or something). There's also an issue with Chinese characters (which are indexed by character rather than word, since there are no spaces to go by, so a search for a word with common characters could produce erroneous results). The quicksearch doesn't use a left-bound index (since that would probably upset German speakers searching for "musik" in "nachtmusik," though I don't know for sure how they think of words) but still seems pretty fast. * Note: There will be a potentially long delay when you start Firefox with this revision as it builds a fulltext word index of your existing items. We obviously need a notification/option for this. * The file scanner, used in the Attachment Content condition of the search dialog, offers phrase searching as well as regex support (both case-sensitive and not, and defaulting to multiline). It doesn't require an index, though it should probably be optimized to use the word index, if available, for narrowing the results when not in regex mode. (It does only scan files that pass all the other search conditions, which speeds it up considerably for multi-condition searches, and skips non-text files unless instructed otherwise, but it's still relatively slow.) Both convert HTML to text before searching (with the exception of the binary file scanning mode). There are some issues with which files get indexed and which don't that we can't do much about and that will probably confuse users immensely. Dan C. suggested some sort of indicator (say, a green dot) to show which files are indexed. Also added (very ugly) charset detection (anybody want to figure out getCharsetFromString(str)?), a setTimeout() replacement in the XPCOM service, an arrayToHash() method, and a new header to timedtextarea.xml, since it's really not copyright CHNM (it's really just a few lines off from the toolkit timed-textbox binding--I tried to change it to extend timed-textbox and just ignore Return keypress events so that we didn't need to duplicate the Mozilla code, but timed-textbox's reliance on html:input instead of html:textarea made things rather difficult). To do: - Pref/buttons to disable/clear/rebuild fulltext index - Hidden prefs to set maximum file size to index/scan - Don't index words of fewer than 3 non-Asian characters - MRU cache for saved searches - Use word index if available to narrow search scope of fulltext scanner - Cache attachment info methods - Show content excerpt in search results (at least in advanced search window, when it exists) - Notification window (a la scraping) to show when indexing - Indicator of indexed status - Context menu option to index - Indicator that a file scanning search is in progress, if possible - Find other ways to make it index the NYT front page in under 10 seconds - Probably fix lots of bugs, which you will likely start telling me about...now.
2006-09-21 00:10:29 +00:00
/**
* Convenience method to replicate window.setTimeout()
**/
function setTimeout(func, ms){
var timer = Components.classes["@mozilla.org/timer;1"].
createInstance(Components.interfaces.nsITimer);
// {} implements nsITimerCallback
timer.initWithCallback({notify:func}, ms,
Components.interfaces.nsITimer.TYPE_ONE_SHOT);
}
- Implemented singleton XPCOM component to store core Scholar objects More details coming on Basecamp: http://chnm.grouphub.com/W161222 *** Important note: after checking out this code, be sure to delete the compreg.dat and xpti.dat files in your FF profile directory or else the extension will not load. They'll be regenerated when you start FF again, and you won't have to do it again unless we add interfaces or other components. Once I set up the XPI packaging system, this step won't be necessary. *** - Localization properties are now loaded directly via nsIStringBundleService and available via Scholar.getString(name) -- removed stringbundle from XUL - Updated status line in bottom right to reflect whether Scholar is loaded correctly or not (temporary, obviously)
2006-05-27 00:20:27 +00:00
//
// XPCOM goop
//
Sorry, it was now or never, and now is better: Changed "Scholar" to "Zotero", everywhere Apologies to anyone with working copy changes, but there are probably the fewer at this moment than there will be again. Hopefully this won't break anything, though existing prefs will be lost. I avoided scholar.google.com--if you know any other legitimate "scholar"s in the code, be sure to fix them once I'm done here. This is a multi-commit change--there's at least one more coming. *Do not update to this version! It won't work!*
2006-10-02 23:15:27 +00:00
ZoteroService.prototype = {
- Implemented singleton XPCOM component to store core Scholar objects More details coming on Basecamp: http://chnm.grouphub.com/W161222 *** Important note: after checking out this code, be sure to delete the compreg.dat and xpti.dat files in your FF profile directory or else the extension will not load. They'll be regenerated when you start FF again, and you won't have to do it again unless we add interfaces or other components. Once I set up the XPI packaging system, this step won't be necessary. *** - Localization properties are now loaded directly via nsIStringBundleService and available via Scholar.getString(name) -- removed stringbundle from XUL - Updated status line in bottom right to reflect whether Scholar is loaded correctly or not (temporary, obviously)
2006-05-27 00:20:27 +00:00
QueryInterface: function(iid){
if (!iid.equals(Components.interfaces.nsISupports) &&
Merged 1.0 branch back to trunk
2007-10-23 07:11:59 +00:00
!iid.equals(ZOTERO_IID)){ // interface unused
- Implemented singleton XPCOM component to store core Scholar objects More details coming on Basecamp: http://chnm.grouphub.com/W161222 *** Important note: after checking out this code, be sure to delete the compreg.dat and xpti.dat files in your FF profile directory or else the extension will not load. They'll be regenerated when you start FF again, and you won't have to do it again unless we add interfaces or other components. Once I set up the XPI packaging system, this step won't be necessary. *** - Localization properties are now loaded directly via nsIStringBundleService and available via Scholar.getString(name) -- removed stringbundle from XUL - Updated status line in bottom right to reflect whether Scholar is loaded correctly or not (temporary, obviously)
2006-05-27 00:20:27 +00:00
throw Components.results.NS_ERROR_NO_INTERFACE;
}
return this;
}
};
Sorry, it was now or never, and now is better: Changed "Scholar" to "Zotero", everywhere Apologies to anyone with working copy changes, but there are probably the fewer at this moment than there will be again. Hopefully this won't break anything, though existing prefs will be lost. I avoided scholar.google.com--if you know any other legitimate "scholar"s in the code, be sure to fix them once I'm done here. This is a multi-commit change--there's at least one more coming. *Do not update to this version! It won't work!*
2006-10-02 23:15:27 +00:00
var ZoteroFactory = {
- Implemented singleton XPCOM component to store core Scholar objects More details coming on Basecamp: http://chnm.grouphub.com/W161222 *** Important note: after checking out this code, be sure to delete the compreg.dat and xpti.dat files in your FF profile directory or else the extension will not load. They'll be regenerated when you start FF again, and you won't have to do it again unless we add interfaces or other components. Once I set up the XPI packaging system, this step won't be necessary. *** - Localization properties are now loaded directly via nsIStringBundleService and available via Scholar.getString(name) -- removed stringbundle from XUL - Updated status line in bottom right to reflect whether Scholar is loaded correctly or not (temporary, obviously)
2006-05-27 00:20:27 +00:00
createInstance: function(outer, iid){
if (outer != null){
throw Components.results.NS_ERROR_NO_AGGREGATION;
}
Sorry, it was now or never, and now is better: Changed "Scholar" to "Zotero", everywhere Apologies to anyone with working copy changes, but there are probably the fewer at this moment than there will be again. Hopefully this won't break anything, though existing prefs will be lost. I avoided scholar.google.com--if you know any other legitimate "scholar"s in the code, be sure to fix them once I'm done here. This is a multi-commit change--there's at least one more coming. *Do not update to this version! It won't work!*
2006-10-02 23:15:27 +00:00
return new ZoteroService().QueryInterface(iid);
- Implemented singleton XPCOM component to store core Scholar objects More details coming on Basecamp: http://chnm.grouphub.com/W161222 *** Important note: after checking out this code, be sure to delete the compreg.dat and xpti.dat files in your FF profile directory or else the extension will not load. They'll be regenerated when you start FF again, and you won't have to do it again unless we add interfaces or other components. Once I set up the XPI packaging system, this step won't be necessary. *** - Localization properties are now loaded directly via nsIStringBundleService and available via Scholar.getString(name) -- removed stringbundle from XUL - Updated status line in bottom right to reflect whether Scholar is loaded correctly or not (temporary, obviously)
2006-05-27 00:20:27 +00:00
}
};
Sorry, it was now or never, and now is better: Changed "Scholar" to "Zotero", everywhere Apologies to anyone with working copy changes, but there are probably the fewer at this moment than there will be again. Hopefully this won't break anything, though existing prefs will be lost. I avoided scholar.google.com--if you know any other legitimate "scholar"s in the code, be sure to fix them once I'm done here. This is a multi-commit change--there's at least one more coming. *Do not update to this version! It won't work!*
2006-10-02 23:15:27 +00:00
var ZoteroModule = {
- Implemented singleton XPCOM component to store core Scholar objects More details coming on Basecamp: http://chnm.grouphub.com/W161222 *** Important note: after checking out this code, be sure to delete the compreg.dat and xpti.dat files in your FF profile directory or else the extension will not load. They'll be regenerated when you start FF again, and you won't have to do it again unless we add interfaces or other components. Once I set up the XPI packaging system, this step won't be necessary. *** - Localization properties are now loaded directly via nsIStringBundleService and available via Scholar.getString(name) -- removed stringbundle from XUL - Updated status line in bottom right to reflect whether Scholar is loaded correctly or not (temporary, obviously)
2006-05-27 00:20:27 +00:00
_firstTime: true,
registerSelf: function(compMgr, fileSpec, location, type){
if (!this._firstTime){
throw Components.results.NS_ERROR_FACTORY_REGISTER_AGAIN;
}
this._firstTime = false;
compMgr =
compMgr.QueryInterface(Components.interfaces.nsIComponentRegistrar);
Sorry, it was now or never, and now is better: Changed "Scholar" to "Zotero", everywhere Apologies to anyone with working copy changes, but there are probably the fewer at this moment than there will be again. Hopefully this won't break anything, though existing prefs will be lost. I avoided scholar.google.com--if you know any other legitimate "scholar"s in the code, be sure to fix them once I'm done here. This is a multi-commit change--there's at least one more coming. *Do not update to this version! It won't work!*
2006-10-02 23:15:27 +00:00
compMgr.registerFactoryLocation(ZOTERO_CID,
ZOTERO_CLASSNAME,
ZOTERO_CONTRACTID,
- Implemented singleton XPCOM component to store core Scholar objects More details coming on Basecamp: http://chnm.grouphub.com/W161222 *** Important note: after checking out this code, be sure to delete the compreg.dat and xpti.dat files in your FF profile directory or else the extension will not load. They'll be regenerated when you start FF again, and you won't have to do it again unless we add interfaces or other components. Once I set up the XPI packaging system, this step won't be necessary. *** - Localization properties are now loaded directly via nsIStringBundleService and available via Scholar.getString(name) -- removed stringbundle from XUL - Updated status line in bottom right to reflect whether Scholar is loaded correctly or not (temporary, obviously)
2006-05-27 00:20:27 +00:00
fileSpec,
location,
type);
},
unregisterSelf: function(compMgr, location, type){
compMgr =
compMgr.QueryInterface(Components.interfaces.nsIComponentRegistrar);
Sorry, it was now or never, and now is better: Changed "Scholar" to "Zotero", everywhere Apologies to anyone with working copy changes, but there are probably the fewer at this moment than there will be again. Hopefully this won't break anything, though existing prefs will be lost. I avoided scholar.google.com--if you know any other legitimate "scholar"s in the code, be sure to fix them once I'm done here. This is a multi-commit change--there's at least one more coming. *Do not update to this version! It won't work!*
2006-10-02 23:15:27 +00:00
compMgr.unregisterFactoryLocation(ZOTERO_CID, location);
- Implemented singleton XPCOM component to store core Scholar objects More details coming on Basecamp: http://chnm.grouphub.com/W161222 *** Important note: after checking out this code, be sure to delete the compreg.dat and xpti.dat files in your FF profile directory or else the extension will not load. They'll be regenerated when you start FF again, and you won't have to do it again unless we add interfaces or other components. Once I set up the XPI packaging system, this step won't be necessary. *** - Localization properties are now loaded directly via nsIStringBundleService and available via Scholar.getString(name) -- removed stringbundle from XUL - Updated status line in bottom right to reflect whether Scholar is loaded correctly or not (temporary, obviously)
2006-05-27 00:20:27 +00:00
},
getClassObject: function(compMgr, cid, iid){
Sorry, it was now or never, and now is better: Changed "Scholar" to "Zotero", everywhere Apologies to anyone with working copy changes, but there are probably the fewer at this moment than there will be again. Hopefully this won't break anything, though existing prefs will be lost. I avoided scholar.google.com--if you know any other legitimate "scholar"s in the code, be sure to fix them once I'm done here. This is a multi-commit change--there's at least one more coming. *Do not update to this version! It won't work!*
2006-10-02 23:15:27 +00:00
if (!cid.equals(ZOTERO_CID)){
- Implemented singleton XPCOM component to store core Scholar objects More details coming on Basecamp: http://chnm.grouphub.com/W161222 *** Important note: after checking out this code, be sure to delete the compreg.dat and xpti.dat files in your FF profile directory or else the extension will not load. They'll be regenerated when you start FF again, and you won't have to do it again unless we add interfaces or other components. Once I set up the XPI packaging system, this step won't be necessary. *** - Localization properties are now loaded directly via nsIStringBundleService and available via Scholar.getString(name) -- removed stringbundle from XUL - Updated status line in bottom right to reflect whether Scholar is loaded correctly or not (temporary, obviously)
2006-05-27 00:20:27 +00:00
throw Components.results.NS_ERROR_NO_INTERFACE;
}
if (!iid.equals(Components.interfaces.nsIFactory)){
throw Components.results.NS_ERROR_NOT_IMPLEMENTED;
}
Sorry, it was now or never, and now is better: Changed "Scholar" to "Zotero", everywhere Apologies to anyone with working copy changes, but there are probably the fewer at this moment than there will be again. Hopefully this won't break anything, though existing prefs will be lost. I avoided scholar.google.com--if you know any other legitimate "scholar"s in the code, be sure to fix them once I'm done here. This is a multi-commit change--there's at least one more coming. *Do not update to this version! It won't work!*
2006-10-02 23:15:27 +00:00
return ZoteroFactory;
- Implemented singleton XPCOM component to store core Scholar objects More details coming on Basecamp: http://chnm.grouphub.com/W161222 *** Important note: after checking out this code, be sure to delete the compreg.dat and xpti.dat files in your FF profile directory or else the extension will not load. They'll be regenerated when you start FF again, and you won't have to do it again unless we add interfaces or other components. Once I set up the XPI packaging system, this step won't be necessary. *** - Localization properties are now loaded directly via nsIStringBundleService and available via Scholar.getString(name) -- removed stringbundle from XUL - Updated status line in bottom right to reflect whether Scholar is loaded correctly or not (temporary, obviously)
2006-05-27 00:20:27 +00:00
},
canUnload: function(compMgr){ return true; }
};
Sorry, it was now or never, and now is better: Changed "Scholar" to "Zotero", everywhere Apologies to anyone with working copy changes, but there are probably the fewer at this moment than there will be again. Hopefully this won't break anything, though existing prefs will be lost. I avoided scholar.google.com--if you know any other legitimate "scholar"s in the code, be sure to fix them once I'm done here. This is a multi-commit change--there's at least one more coming. *Do not update to this version! It won't work!*
2006-10-02 23:15:27 +00:00
function NSGetModule(comMgr, fileSpec){ return ZoteroModule; }
Reference in a new issue Copy permalink