Changes between Version 10 and Version 11 of Event/2012/GCI/Code

11/13/12 07:16:09 (11 years ago)
Michael Howden



  • Event/2012/GCI/Code

    v10 v11  
    55== Sahana Eden Tasks ==
    6 using Python, !JavaScript and HTML.
    8 === Add Social Media Share Buttons to Pages ===
    9 See: [wiki:Contribute/Code#AddSocialMediaShareButtonstoPages Add Social Media Share Buttons]
    11 === Common Operational Datasets ===
    12 See: [wiki:Contribute/Code#CommonOperationalDatasets Common Operational Datasets]
    14 === Update Pootle ===
    15 Provide a set of admin scripts (bzr post-commit hook?) to update Pootle with any changed strings as a Merge.
    17 === GIS/Mapping ===
    19 These are a various GIS/Mapping Tasks:
    20  * Add a delay to the onHover tooltip (highlightControl)
    21   * Something like [ hoverIntent]
    22  * Continue Integration of [ Potlatch]
    23   * for editing the main OSM database
    24   * for editing a local OSM database
    25  * Make the display_feature() & display_features() popup a Window instead of opening in a DIV
    26   * This was working in FF before:
    27  * Replace the Measure Length/Area tools with [ GeoExt.ux]
    28  * Option to go Full screen & back
    29   * Full screen view (No Ext window) will be required for use on a small-screen, such as a Mobile device
    30  * [ Layer Tree]
    31  * Get a pr/person/presence record upon login if HTML5 !GeoLocation available & not changed since last time
    32   * login_next
    33  * Map Preview when Lat/Lon set in pr/person/presence (auto or not)
    35 [wiki:DeveloperGuidelinesGIS Use the Mapping API to:]
    36  * Color coded maps according to Geo-data (threats, needs, etc)
    37  * Placing variable sized markers on the map in proportion to data (number of people in camp, number of families needing food)
    39 === !Lat/Lon converter ===
    41 Portuguese Volunteer Firefighters ([Deployments/Bombeiros Bombeiros]) use Eden.
    43 They get given !Lat/Lon coordinates in Degrees/Minutes/Seconds, but Eden stores internally as Decimal degrees.
    45 Tasks:
    46 * Create a represent function to output the data as D/M/S
    47 * Create a validator (& possibly widget) to allow entry of this format & have it converted to decimal dagrees for storage
    49 === Scale Uploaded Images ===
    50 When images are uploaded we can limit the size, however larger pictures should be scaled instead.
    52 This should be implemented as a Validator {{{modules/s3/}}}).  The size limitation should be configurable in the model for that specific field, with a sensible default.
    54 Bonus points: UI to crop image (this would be a Widget: {{{modules/s3/}}})
    56 Ideally the image would be resized client-side to make it faster to upload...this might be hard with pure JS, so would need to be Flash?
    57  * Maybe: (e.g. from )
    59 Example: Personal Profile Picture
    61 === Suggestion Box ===
    62  Here are some potential features for a "suggestion box", roughly in order of priority:
    63  * Text data entry form -- just use standard Eden database fields like "timestamp", "authorstamp", and "comments", maybe with a subject field.
    64  * Allow defining topics or keywords. Let user choose a topic for their suggestion. Add all module names as an initial list of topics.
    65  * Simple search in the body of posts -- match words.
    66  * Regexp search.
    67  * Allow commenting on (replying to) suggestions -- show comment thread with original post.
    68  * Some form of importance rating (e.g. voting up or down).
    69  * Original suggestion from:
    71 === Map elements between EDXL-SITREP and EDXL-RM ===
    72 Proposed by: [ | Nuwan][[BR]]
    73 '''Specific    : ''' There are several elements within the [ | EDXL-SITREP] data standard that are identical to that of [ | 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]]
    74 '''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]]
    75 '''Attainable  : ''' [[BR]]
    76 Step 1 :: Go through EDXL-RM and EDXL-SITREP documentations [[BR]]
    77 Step 2 :: create example files to get an understanding of the data and structure [[BR]]
    78 Step 3 :: develop the table with RM and SITREP elements with a description [[BR]]
    79 Step 4 :: develop a simple XSL file to strip the RM data from SITREP [[BR]]
    80 '''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]]
    81 '''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]]
    82 '''Evaluate    : ''' The mapping table is the determining output. However, the example RM and SITREP files are also required. [[BR]]
    83 '''Reevaluate  : ''' If the XSL transformation is developed, then the mapping can be tested with the sample RM and SITREP files [[BR]]
    85 === Review code for quality of localized strings ===
    86 '''''Migrated'''''[[br]]
    87 All 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.
    89 For GCI, you will need to review all the internationalized strings in the model and controller files for a single module, eg:
    90 * {{{controllers\}}}, {{{models\}}}, and {{{views/gis/*.html}}}
    91 * {{{controllers\}}}, {{{models\}}}, and {{{views/hrm/*.html}}}
    92 * {{{controllers\}}} and {{{views/default/*.html}}}
    94 Check for:
    95 * Incomplete or cut-off sentences in the translation strings
    96 * Avoid concatenation of localized strings with variables - use %s or %(key)s instead.  That is, instead of:[[br]]
    97   {{{T("My name is ") + name}}}[[br]]
    98   use this:[[br]]
    99   {{{T("My name is %s") % name}}}[[br]]
    100   And instead of:[[br]]
    101   {{{T("The item ") + item + T(" is not available in ") +}}}[[br]]
    102   use this:[[br]]
    103   {{{T("The item %(item)s is not available in %(place)s.") % {"item": item, "place":}}}}[[br]]
    104   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.
    105 * Look for fields without a label - e.g. Field("fieldname") as these cannot be localised.
    106 * 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:
    107  * Strings that are used as keys in dicts, e.g. `{"this_is_a_key": 5}`, should not be localized.
    108  * 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/}}}).
    109 * 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.
    111 You 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.
    113 Please focus on modules which are [ enabled by default].
    115 === OSM Importer UI ===
    116  * There is an import stylesheet for .osm files: static/xslt/import/osm.xsl
    117  * This currently has hard-coded mappings between OSM admin levels & Sahana admin levels
    118   *  *
    119  * A custom controller should be written
    120   * provide a UI to the user to select their country from the dropdown which pre-populates the mapping fields for manual verification/adjustment
    121   * process the results of this to pass new variables back to the stylesheet:
    122    *
    123 {{{
    124 resource = s3xrc.resource("gis", "location")
    125 template = os.path.join(request.folder, resource.XSLT_PATH, "osm", "import.xsl")
    126 resource.import_xml("uploaded_filename.osm", template=template, mynewvar="xxx")
    127 }}}
    128  * The Stylesheet needs updating to act on these vars when found
    130 A nice further refinement would be to provide a UI to select a BBOX & optional filter to pull down the .osm file via [ XAPI]
    131  * Initially this could be manual text box entry of BBOX/filter
    132  * Then add a Map-based BBOX selection & dropdowns for the filter (which prepopulate the real dropdowns for manual verification/amendment)
    134 === Recurring Requests ===
    135 e.g. Shelter needs 100 liters of water/week
    137 Want to be able to add Scheduling functionality to Requests.
    139 There is a wrapper for Web2Py's Scheduler class in {{{modules/s3/}}}
    141 Can use UI ideas/code from Sync
    143 === Build library(ies) to integrate Emergency Data Exchange Language Distribution Element ===
    144 Proposed by: [ | Nuwan] [[BR]]
    145 '''Specific  : '''[ | EDXL-DE] is the final wrapper (envelope) of all [ | 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]]
    146 '''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]]
    147 '''Attainable: ''' run through the steps [[BR]]
    148 Step 1 :: select one of the existing EDXL-based applications in Eden, I recommend the EDXL-RM [[BR]]
    149 Step 2 :: discuss each of the attributes/elements; then determine how EDXL-DE would be added to EDXL-RM as a pop-up GUI. [[BR]]
    150 Step 3 :: create some example XML files to get a feel for the inputs and outputs [[BR]]
    151 Step 4 :: write code to add to take the inputs EDXL-RM and EDXL-DE to package the data for delivery [[BR]]
    152 Step 5 :: test the code, fix bugs, and generalize the functions [[BR]]
    153 Step 6 :: Apply to EDXL-HAVE and EDXL-SITREP to generalize the library [[BR]]
    154 '''Relevant  : ''' Applies to Sahana Interoperability policy. Present developments to investigate are: HAVE, RM, and SITREP [[BR]]
    155 '''Time-bound: ''' If steps 1 - 4 are completed that can be a full accomplishment; additional work is a bonus [[BR]]
    156 '''Evaluate  : ''' Produce XML files with the EDXL-DE element appended to the EDXL-RM, SITREP, or HAVE[[BR]]
    157 '''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]]
     6Using Python, !JavaScript and HTML. See: Contribute/Code
    1598== Sahana Vesuvius Tasks ==