From Porcupine wiki

Administrators: How to migrate your applications from version 0.1.1 to 0.5

Follow the following steps:

  1. First you need to create the appropriate web methods for your content classes. For this reason create a new "webmethods" Python package inside your application's directory. Inside this package I recommend creating one file per content class. Therefore, if you need to add web methods to two content classes this package will contain two python files. It is also advised to edit the "__init__.py" file of the aforementioned package and then add the "__all__" special attribute containing a list of all of its contained modules. This is because in the next steps we will use something like "from com.mycompany.myapp.webmethods import *". The typical imports required for each one of these modules are:
    
    from porcupine import HttpContext
    from porcupine import webmethods
    from porcupine import filters
    from porcupine import db
    
    from com.mycompany.myapp.schema import MyContainerClass
    
    
  2. Inspect the "store.xml.bak" file (this is actually a backup kept temporarily and can be safely deleted after the migration process is finshed). Typically, for each registration serving UIs inside your application's package node you need to create a new web method. A registration of the this type:
    
    <reg action="com.mycompany.myapp.ui.MyForm"
    	cc="com.mycompany.myapp.schema.MyContainerClass"
    	qs="com.mycompany.myapp.schema.MyItemClass"
    	client="(MSIE [6-7])|(Mozilla/5.0.+rv:1.[7-9])"
    	lang=".*"
    	method="GET"
    	param="new">
                <filter type="porcupine.filters.postProcessing.multilingual.Multilingual"
    		    using="org.innoscript.desktop.strings.resources"/>
    </reg>
    
    

    becomes something like this (this code should be entered in the content class's file inside the "webmethods" package):
    
    @filters.i18n('org.innoscript.desktop.strings.resources')
    @webmethods.quixui(of_type=MyContainerClass,
                       qs='com.mycompany.myapp.schema.MyItemClass',
                       template='relative/path/to/quix/template',
                       isPage=False)
    def new(self):
        [PASTE THE CODE OF THE execute METHOD OF THE com.mycompany.myapp.ui.MyForm SERVLET HERE]
    
    

    Whereas, an XML-RPC registration of this type, typically requires more than one web method; one for each XML-RPC method defined inside the XML-RPC servlet:
    
    <reg action="com.mycompany.myapp.XMLRPC.MyContainerClass"
    	cc="com.mycompany.myapp.schema.MyContainerClass"
    	client="vcXMLRPC"
    	lang=".*"
    	method="POST"
    	param=""/>
    
    

    One remote method is defined as:
    
    @webmethods.remotemethod(of_type="MyContainerClass")
    def method_name(self):
        [PASTE THE CODE OF THE method_name METHOD OF THE com.mycompany.myapp.XMLRPC.MyContainerClass SERVLET HERE]
    
    

    It is worth mentioning that registrations such as the one below DO NOT need to be migrated since these kind of methods are bound to the base content classes and they are already there for all sub-classes:
    
    <reg action="org.innoscript.desktop.ui.Frm_AutoNew"
    	cc="com.mycompany.myapp.schema.MyContainerClass"
    	client="(MSIE [6-7])|(Mozilla/5.0.+rv:1.[7-9])"
    	lang=".*"
    	method="GET"
    	param="new">
                <filter type="porcupine.filters.postProcessing.multilingual.Multilingual"
    		    using="org.innoscript.desktop.strings.resources"/>
    </reg>
    
    
  3. The code pasted inside the web methods needs some amendments. The first obvious replacement is:
    
    self.item -> self
    
    

    since the web method is bound to the content class itself. Then replace all the database handle references:
    
    self.server.store -> db
    
    

    Next, you can now get the HTTP context inside the web method by using:
    
    http_context = HttpContext.current()
    
    

    and then apply the following replacements:
    
    self.response -> context.response
    self.request -> context.request
    self.session -> context.session
    self.server -> context.server
    
    

    Specifically for the web methods that have a template since there is no "self.params" dict, the web method must return this Python dict. Therefore, I recommend:
    
    self.params -> params
    
    

    for making params a local variable and then:
    
    return params
    
    
  4. If you have used the HTTPServlet class then the corresponding web method is:
    
    @webmethods.webmethod(of_type=MyContainerClass, http_method='GET', client='', lang='', qs='',
                          max_age=0, content_type='text/html', encoding='utf-8',
                          template='relative/path/to/the/template/file')
    def my_method(self):
        ...
    
    

    The required parameters of this web method are the "of_type" and the "template". The others' default values are shown above. This method is called by issuing an HTTP GET on "http://SERVER/porcupine.py/OBJECT_ID?cmd=my_method". Use the special name "__blank__" if no cmd parameter is required. The later also applies for QuiX web methods.

  5. Binding PSP pages to objects is no longer supported. Thus, if any of your "store.xml" registrations' action attribute points to a PSP page then you have to transfer the logic of this server page inside a web method.

  6. Update your PSP pages' code. All system objects passed in a PSP page now begin with a capital letter. Required replacements are:
    
    response -> Response
    request -> Request
    session -> Session
    server -> Server
    
    

  7. Activate your web methods. In order for the web methods to added to your content classes you must import them. Most of the times placing this import in you application's main package "__init__.py" is sufficient:
    
    from com.mycompany.myapp.webmethods import *
    
    

  8. On the UI side, if you application is using splitters then you have to make some final adjustments. The new Splitter widget derives from Box. The first change that you have to make is to invert the splitters' orientation; that is vertical become horizontal and horizontal become vertical. Next remove all the "pane" tags and transfer the positioning and sizing attributes to the inner widget. If a pane contains has more than one child widget then transform in place into a rectangle. On-off panes are no longer an option. All panes are collapsing when double clicking on the splitter handles.

That's it. For a more detailed view of changes introduced in this version and not mention in this guide see the Main.ChangeLog

Retrieved from http://wiki.innoscript.org/pmwiki.php/Administrators/UpgradingFrom011to05
Page last modified on May 03, 2008, at 02:03 AM