mariarahat / bungeni-editor

Automatically exported from code.google.com/p/bungeni-editor
2 stars 0 forks source link

Editor data entry and markup modes #18

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
There are two usage modes for the editor with respect to availability of 
metadata 

a. editor has access to a full backed server which provides metadata

b. editor has no access to a backend server with metadata

In both scenario a. and b. there is a minimal mandatory requirement for 
available metadata.

e.g. for the debates

 - member of parliament names + roles (mp/minister/speaker) +  URIs 
 - ministry names + URIs

In a. the user is provided with blank forms to input metadata - and only the 
primary metadata 
fields are presented for data entry /input.  There is NO metadata selection 
provided other than 
for minimal mandatory metadata. In the case of the tabled doucments - 
individual items in the 
bullet listing need to be marked up.

In b. the user is provided with forms to select metadata from the backend. the 
same form can be 
used to add metadata into the document in case the metadata does not exist on 
the backend. In 
the case of tabled documents - a mechanism to import the tabled document 
listings with 
metdata for that day is provided.

TO DO :

Provide a way to define multiple runtime profiles for the editor. And then the 
editor uses a 
runtime profile (e.g. profiles : "withBackend", "withoutBackend", "withBungeni" 
etc... 
"withoutBackend" makes editor run in 'no-backend' mode).

Original issue reported on code.google.com by ashok.ha...@gmail.com on 3 Jul 2009 at 3:54

GoogleCodeExporter commented 9 years ago
Main container - simply a launchpad for other selectors.

Selectors - described in sub_action_settings. connected to Main container via 
the action_settings parent key

---

The main container currently describes all the selectors available. It does not 
specify any runtime selectors.

Objective is to be able to :

- launch a group of selectors (already there but not via profiles)
- launch a set of filtered selectors (already there but not via profiles)

Option 1
---------

Have multiple main containers (mapped to different action_settings) with 
hardcoded selectors

Map each main container to a profile (the active profile)

Option 2
---------

Map each sub_action_setting to a profile (the active profile).

Build the selectors for the main container based on the active profile.

Original comment by ashok.ha...@gmail.com on 7 Jul 2009 at 7:56

GoogleCodeExporter commented 9 years ago
Also map the toolbar action xml to a profile

Original comment by ashok.ha...@gmail.com on 8 Jul 2009 at 1:37

GoogleCodeExporter commented 9 years ago
This issue is out of date, most of what is described here was implemented

Original comment by ashok.ha...@gmail.com on 15 Mar 2012 at 11:36