Changes between Version 5 and Version 6 of Development/1.2/Plugin


Ignore:
Timestamp:
08/28/2009 01:41:33 AM (13 years ago)
Author:
andar
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Development/1.2/Plugin

    v5 v6  
    137137}}} 
    138138 
    139 Whoa, what's this?  It's our first two rpc exported methods of course! 
     139Whoa, what's this?  It's our first two RPC exported methods of course!  You may be asking yourself, "What does that mean?", it means that the UI portions of our plugins will be able to call these methods over RPC.  This is the primary method for your plugin portions to communicate. 
     140 
     141You'll notice that we use a decorator function (@export) to mark methods as being exportable, this makes it very easy to export functions. 
     142 
     143To get back to what we're looking at, you'll see that `set_config()` takes an argument `config` and in this case it is a dictionary object.  The UI portion will be ''sending'' this dictionary to the Core portion to update it's Config object.  This is important because many config options you'll want to have available for the Core to use -- you don't want to be saving config options on the UI side that the Core portion needs because they may not be on the same computer and cannot access the same config file. 
     144 
     145The `get_config()` method will simply return a dict object representing all the key/value pairs in our Config object back to the requestor. 
     146 
     147A example of how calling these methods would look like from the UI perspective: 
     148{{{ 
     149#!python 
     150 
     151def on_get_config(result): 
     152    result["test"] = "i want to change this value" 
     153    client.myplugin.set_config(result) 
     154 
     155client.myplugin.get_config().addCallback(on_get_config) 
     156 
     157}}} 
     158 
     159Don't worry if you don't quite understand this example, we'll get to that when we start working on our UI portions of the plugin. 
     160