History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: MANTRA-14
Type: Sub-task Sub-task
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Preston A. Elder
Reporter: Preston A. Elder
Votes: 0
Watchers: 0
Operations

Clone and Move
If you were logged in you would be able to see more operations.
Mantra
MANTRA-3

Handle output better

Created: 02/Jun/08 02:01 AM   Updated: 06/Sep/08 07:40 PM
Component/s: None
Affects Version/s: 1.0
Fix Version/s: 1.0

Time Tracking:
Not Specified

Reporter Domain: neuromancy.net (Find related issues)
Labels: EDIT
Attachments: 0
Resolution Date: 06/Sep/08 07:40 PM
Last Commented: 30 weeks, 5 days ago
Participants: Preston A. Elder


 Description  « Hide
The way output data is handled is stupid and needs to be fixed.

Right now there is no way to represent tabular data. There should be a way to set headings, and record data in a table that is formatted by the individual admin interface libraries. There should also be a way to set a minimum column width (either absolute or percentage), and relative percentages for each column so that in the case of the data being too large for the screen, the interface lib can truncate data or adjust column widths as appropriate.

Translation also needs to be delayed until the last moment, and performed by the admin libs. This is because some libs (notably HTML) will not be simple stream line-based interfaces, but may have to move data around or represent it in a different manner. In this circumstance, the data has to be easily parsable so that it can pull out the relevant data and format it appropriately before translation mangles it into a different format.

 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
Preston A. Elder - 04/Jun/08 05:24 AM
Re: translation, this is actually NOT possible in retrospect unless everything is passed as a boost::format. By turning boost::format's into strings we lose the ability to translate them because boost::format does the interpolation. This means either everything must be a boost::format, or translation must occur at the time the string is generated. It does leave a problem for HTML-based interfaces, though I guess any HTML interface is likely to only support specific languages, and so it would have to have slightly different parsing code depending on the language selected. Not ideal, but not horrendous either.