Changes between Version 23 and Version 24 of Contribute/Code


Ignore:
Timestamp:
11/01/12 04:31:57 (9 years ago)
Author:
Michael Howden
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Contribute/Code

    v23 v24  
    11[[TOC]]
    2 == Basic Coding Projects ==
    3 ''Projects for beginning coders, or if new to Python or web services''
     2= Contribute: Code  =
     3These tasks are suitable for coders of various levels. Sahana Eden using Python, !JavaScript and HTML.
     4== Easy ==
     5''Tasks for beginning coders, or if new to Python or web services''
    46
    5 === Easy Tickets ===
    6 ''GCI''
    7  * Pick from these [/report/18 easy bugs for new Eden developers].
     7=== Fix an Easy Ticket ===
     8http://eden.sahanafoundation.org/report/18
     9Pick a bug report from http://eden.sahanafoundation.org/report/18, try to reproduce the issue in a local instance, fix the problem and submit a patch to the ticket on Trac, then notify the Sahana-Eden mailing list about your patch for verification.
    810
    9 === Feature Enhancements ===
    10  * Fix UI issues, add features, provide user-requested enhancements.
    11   * You can pick from these [/report/21 feature requests].
    12 
    13  * The landing page for each module is different -- some have descriptive text, others have statistics (a "dashboard"). Each has a different layout of menus.
    14   * Are any of these landing pages useful? What would be better for a typical workflow?
    15   * Make appropriate changes.
    16   * Is there a common sort of menu that would be useful?
     11==== Add Social Media Share Buttons to Pages ====
     12Medium[[br]]
     13Add code which displays buttons to Share to Social Media (at least facebook & twitter) on every page.
     14* This should be controllable from a deployment_setting
     15* Please push the code to a branch on launchpad for review and submit a link to this branch
     16http://devgrow.com/loading-social-media-buttons-after-everything-else/
    1717
    1818=== Common Operational Datasets ===
     
    2222  * Display on the Map
    2323  * Have Reports which compare the baseline & situational assessments
    24  
    25 === Translations Admin Panel ===
    26 ==== Use Cases ====
    27  * Admin wants to update /languages on their running instance with current version from Pootle
    28  * Admin wants to be able to do offline translation of main language file(s) (either using native web2py UI or using a PO-based tool like Virtaal)
    29  * Admin wants to be able to translate additional custom strings in this instance (either using native web2py UI or using a PO-based tool like Virtaal)
    30 
    31 ==== Tasks ====
    32  * Add a page to {{{controllers/admin.py}}} to handle Translations.
    33  * Update the InstallationGuidelines with any new optional requirements (such as translate toolkit).
    34  * Gracefully give nice error messages if the translate toolkit isn't installed.
    35  * Update UserGuidelinesLocalisation
    36 
    37 ==== Export PO file ====
    38  * Dropdown to select which language
    39  * Button to call [http://translate.sourceforge.net/wiki/toolkit/py2web2po web2py2po] to convert the .py file to a standard PO file for the user to download
    40 
    41 ==== Import PO file ====
    42  * Upload Widget which calls [http://translate.sourceforge.net/wiki/toolkit/py2web2po po2web2py] onaccept to convert a .po file to a Web2Py .py file stored in the languages folder
    43   * Use the same filename prefix or prompt?
    44   * Do a merge
    4524
    4625==== Update Pootle ====
     
    6746 * Color coded maps according to Geo-data (threats, needs, etc)
    6847 * Placing variable sized markers on the map in proportion to data (number of people in camp, number of families needing food)
    69 ==== OSM Importer UI ====
    70  * There is an import stylesheet for .osm files: static/xslt/import/osm.xsl
    71  * This currently has hard-coded mappings between OSM admin levels & Sahana admin levels
    72   *  * http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative#10_admin_level_values_for_specific_countries
    73  * A custom controller should be written
    74   * provide a UI to the user to select their country from the dropdown which pre-populates the mapping fields for manual verification/adjustment
    75   * process the results of this to pass new variables back to the stylesheet:
    76    * http://pub.nursix.org/eden/s3xrc/vita.modules.s3xrc.s3rest.S3Resource-class.html#import_xml
    77 {{{
    78 resource = s3xrc.resource("gis", "location")
    79 template = os.path.join(request.folder, resource.XSLT_PATH, "osm", "import.xsl")
    80 resource.import_xml("uploaded_filename.osm", template=template, mynewvar="xxx")
    81 }}}
    82  * The Stylesheet needs updating to act on these vars when found
    83 
    84 A nice further refinement would be to provide a UI to select a BBOX & optional filter to pull down the .osm file via [http://wiki.openstreetmap.org/wiki/XAPI XAPI]
    85  * Initially this could be manual text box entry of BBOX/filter
    86  * Then add a Map-based BBOX selection & dropdowns for the filter (which prepopulate the real dropdowns for manual verification/amendment)
    87 
    88 === Recurring Requests ===
    89 e.g. Shelter needs 100 liters of water/week
    90 
    91 Want to be able to add Scheduling functionality to Requests.
    92 
    93 There is a wrapper for Web2Py's Scheduler class in {{{modules/s3/s3task.py}}}
    94 
    95 Can use UI ideas/code from Sync
    9648
    9749=== !Lat/Lon converter ===
     
    12678 * Original suggestion from: http://groups.google.com/group/sahana-eden/browse_thread/thread/bbda1e98b73e1437
    12779
     80=== Map elements between EDXL-SITREP and EDXL-RM ===
     81Proposed by: [http://lirneasia.net/profiles/nuwan-waidyanatha | Nuwan][[BR]]
     82'''Specific    : ''' There are several elements within the [http://tinyurl.com/bn9nxty | EDXL-SITREP] data standard that are identical to that of [http://docs.oasis-open.org/emergency/edxl-rm/v1.0/EDXL-RM-SPEC-V1.0.pdf | EDXL-RM]. The objective is to create a descriptive table of those elements that a programmer can use to develop a set of procedures to strip the RM data from SITREP to manage records in the relational database [[BR]]
     83'''Measurable  : ''' Requires diligently investigating each and every data element then comparing them with the two data standards SITREP and RM. Requires knowledge of data types and XML. If not, this exercise will help the student learn about XML and data standards [[BR]]
     84'''Attainable  : ''' [[BR]]
     85Step 1 :: Go through EDXL-RM and EDXL-SITREP documentations [[BR]]
     86Step 2 :: create example files to get an understanding of the data and structure [[BR]]
     87Step 3 :: develop the table with RM and SITREP elements with a description [[BR]]
     88Step 4 :: develop a simple XSL file to strip the RM data from SITREP [[BR]]
     89'''Relevant    : ''' Applies to Sahana interoperability policy. Given that Eden does support resource and incident management, it is important to derive the response resources and resource requirements from situational reports. This function would help automate some of those data extraction functions. That requires integrating the SITREP and RM components with underlying Eden schema [[BR]]
     90'''Time-bound  : ''' The exercise of understanding the data standards and mapping the elements should not take more than one week. developing a XSL to test the mapping may take another week, depending on the level of expertise with XML. (NB this is far too large a task for GCI. -- Pat)[[BR]]
     91'''Evaluate    : ''' The mapping table is the determining output. However, the example RM and SITREP files are also required. [[BR]]
     92'''Reevaluate  : ''' If the XSL transformation is developed, then the mapping can be tested with the sample RM and SITREP files [[BR]]
     93
     94=== Review code for quality of localized strings ===
     95'''''Migrated'''''[[br]]
     96All strings which appear in the user interface, such as in menus and forms and help info, should be "internationalized" -- marked to make them available to be translated into different languages. This is done by putting the strings inside of {{{T( )}}}, e.g. {{{T("This string will be written into language files to be translated")}}}. The strings in {{{T( )}}} are keys that are used to look up translated strings. By convention, the key strings are in US English.
     97
     98For GCI, you will need to review all the internationalized strings in the model and controller files for a single module, eg:
     99* {{{controllers\gis.py}}}, {{{models\gis.py}}}, and {{{views/gis/*.html}}}
     100* {{{controllers\hrm.py}}}, {{{models\hrm.py}}}, and {{{views/hrm/*.html}}}
     101* {{{controllers\default.py}}} and {{{views/default/*.html}}}
     102
     103Check for:
     104* Incomplete or cut-off sentences in the translation strings
     105* Avoid concatenation of localized strings with variables - use %s or %(key)s instead.  That is, instead of:[[br]]
     106  {{{T("My name is ") + name}}}[[br]]
     107  use this:[[br]]
     108  {{{T("My name is %s") % name}}}[[br]]
     109  And instead of:[[br]]
     110  {{{T("The item ") + item + T(" is not available in ") + location.name}}}[[br]]
     111  use this:[[br]]
     112  {{{T("The item %(item)s is not available in %(place)s.") % {"item": item, "place": location.name}}}}[[br]]
     113  This is better because the word order is not the same in all languages -- in the second form, the translator can move where the variables are inserted.
     114* Look for fields without a label - e.g. Field("fieldname") as these cannot be localised.
     115* Look at strings that have not been wrapped in {{{T( )}}} to see if they ought to be. But be cautious: Not all strings need to be localized, and some definitely should not be:
     116 * Strings that are used as keys in dicts, e.g. `{"this_is_a_key": 5}`, should not be localized.
     117 * A string that is intended to be in one specific language should not be localized (e.g. the language names in the language menu in {{{deployment-templates/models/000_config.py}}}).
     118* Consider improving consistency of wording / terminology - don't use different strings that mean the same thing, e.g. if there is {{{T("My name is")}}} in one place, avoid using {{{T("I am called")}}} somewhere else.
     119
     120You will need to download a working branch of Sahana Eden code for this task and push the changes you make to your own branch on Git.
     121
     122Please focus on modules which are [https://github.com/flavour/eden/blob/master/deployment-templates/models/000_config.py#L427 enabled by default].
     123
     124== Intermediate ==
     125
     126=== Feature Enhancements ===
     127 * Fix UI issues, add features, provide user-requested enhancements.
     128  * You can pick from these [/report/21 feature requests].
     129
     130==== OSM Importer UI ====
     131 * There is an import stylesheet for .osm files: static/xslt/import/osm.xsl
     132 * This currently has hard-coded mappings between OSM admin levels & Sahana admin levels
     133  *  * http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative#10_admin_level_values_for_specific_countries
     134 * A custom controller should be written
     135  * provide a UI to the user to select their country from the dropdown which pre-populates the mapping fields for manual verification/adjustment
     136  * process the results of this to pass new variables back to the stylesheet:
     137   * http://pub.nursix.org/eden/s3xrc/vita.modules.s3xrc.s3rest.S3Resource-class.html#import_xml
     138{{{
     139resource = s3xrc.resource("gis", "location")
     140template = os.path.join(request.folder, resource.XSLT_PATH, "osm", "import.xsl")
     141resource.import_xml("uploaded_filename.osm", template=template, mynewvar="xxx")
     142}}}
     143 * The Stylesheet needs updating to act on these vars when found
     144
     145A nice further refinement would be to provide a UI to select a BBOX & optional filter to pull down the .osm file via [http://wiki.openstreetmap.org/wiki/XAPI XAPI]
     146 * Initially this could be manual text box entry of BBOX/filter
     147 * Then add a Map-based BBOX selection & dropdowns for the filter (which prepopulate the real dropdowns for manual verification/amendment)
     148
     149=== Recurring Requests ===
     150e.g. Shelter needs 100 liters of water/week
     151
     152Want to be able to add Scheduling functionality to Requests.
     153
     154There is a wrapper for Web2Py's Scheduler class in {{{modules/s3/s3task.py}}}
     155
     156Can use UI ideas/code from Sync
     157
     158==== Fix an Hard Ticket ====
     159http://eden.sahanafoundation.org/report/1
     160Pick a bug report from http://eden.sahanafoundation.org/report/1, try to reproduce the issue in a local instance, fix the problem and submit a patch to the ticket on Trac, then notify the Sahana-Eden mailing list about your patch for verification.
     161
     162=== Build library(ies) to integrate Emergency Data Exchange Language Distribution Element ===
     163Difficulty : '''HARD''' proposed by: [http://lirneasia.net/profiles/nuwan-waidyanatha | Nuwan] [[BR]]
     164'''Specific  : '''[http://docs.oasis-open.org/emergency/edxl-de/v1.0/EDXL-DE_Spec_v1.0.pdf | EDXL-DE] is the final wrapper (envelope) of all [http://en.wikipedia.org/wiki/EDXL | EDXL] data package. We may be delivering a EDXL Resource Management (RM) information and Situational Reporting (SITREP) information to the managers of several emergency organizations. The DE will contain who, when, and where those RM and SITREP data parcels would be delivered. Every EDXL message (data package) must carry this information. Otherwise, it cannot use available distribution methods and would need to rely on its own protocol; that's not very user friendly. [[BR]]
     165'''Measurable: ''' It is purely a coding task that involves playing with XML and developing a class, possibly within or using the '''??? 3R**** ???''' framework It is basically a set of procedures for packing and unpacking EDXL-DE wrapped data. [[BR]]
     166'''Attainable: ''' run through the steps [[BR]]
     167Step 1 :: select one of the existing EDXL-based applications in Eden, I recommend the EDXL-RM [[BR]]
     168Step 2 :: discuss each of the attributes/elements; then determine how EDXL-DE would be added to EDXL-RM as a pop-up GUI. [[BR]]
     169Step 3 :: create some example XML files to get a feel for the inputs and outputs [[BR]]
     170Step 4 :: write code to add to take the inputs EDXL-RM and EDXL-DE to package the data for delivery [[BR]]
     171Step 5 :: test the code, fix bugs, and generalize the functions [[BR]]
     172Step 6 :: Apply to EDXL-HAVE and EDXL-SITREP to generalize the library [[BR]]
     173'''Relevant  : ''' Applies to Sahana Interoperability policy. Present developments to investigate are: HAVE, RM, and SITREP http://www.oasis-open.org/standards#edxl [[BR]]
     174'''Time-bound: ''' If steps 1 - 4 are completed that can be a full accomplishment; additional work is a bonus [[BR]]
     175'''Evaluate  : ''' Produce XML files with the EDXL-DE element appended to the EDXL-RM, SITREP, or HAVE[[BR]]
     176'''Reevaluate: ''' Use an API to add and strip the EDXL-DE to any EDXL data standard. Use the same set of XML files to run through this process [[BR]]
     177
     178== Advanced ==
     179Have a look at a BluePrint to see what advanced code contributions are needed.
     180
    128181----
    129 [wiki:Projects]
     182[wiki:Contribute]