Note: You are currently viewing documentation for Moodle 3.3. Up-to-date documentation for the latest stable version of Moodle is probably available here: Text formats.

Development talk:Text formats: Difference between revisions

From MoodleDocs
mNo edit summary
 
(13 intermediate revisions by 2 users not shown)
Line 1: Line 1:
Some points:
== Some concerns and ideas ==


A- Fix places without "format"
On G:
:<strike>a) inline format info (like trusttest -> Sam)</strike>
* "use special editor if available" should be yes/by demand/no, with "by demand" mode storing in user preferences where to use editor and where not - the cause is performance problems for some pages (I actually have one Moodle 2.0 page loaded (initialised actually) for 10 minutes cause of many editor instances on it, while I was really need to have 2 of these 30 instaces active), and this was a page for editing real question taked from production site;
:b) add formatxxx fields in all missing places. Naming schema "xxxformat" (exam. "descriptionformat").
* "USED formats have precedence over USER settings, so editing existing texts won't change the format at all" - it would be too bad to have lock down on format after first editing - especially if you have a users with different OS/prefereed browsers creating and maintaining one course; I guess any format could define a range of another formats it could import data from and functions to do so, so some conversions would be possible (maybe after direct approval of the user). Or maybe make import functions pluginable so the people who need them could easily write and contribute them.
:: - db new fields.
--[[User:Oleg Sychev|Oleg Sychev]] 11:23, 11 December 2009 (UTC)
:: - upgrade
:: - forms modification (combined element)
:: - backup & restore
:: - Need conversion to HTML format (always enabled plugin) from all formats
:: - convert all the old format fields to use the new naming schema.
::: - backup and restore
::: - forms modification
 
B- Make them modular (pluggable. OOP) (lib/format and lib/formatlib.php, get_format()->do_stuff())
 
<strike>C- Enable at site/course levels?</strike>
 
D- Upgrade to detect formats should be clever (and will be heavy!)
 
E- Editors "attached" to formats.
 
F- Can have "special" editors for other formats.
 
G- 1 user preference (format & editor) plus 1 preference to "disable editor"
 
H- Wiki format (mediawiki). Coming from nwiki hopefully.
 
I - Conflicts between formats and some filters sharing same syntax:
:a) make filters to use prefixes and allow them to be automatically informed to the formats. Complex.
:b) Use some alternate syntax (a safe one)
 
J- Filters: Any relation with formats? Enable/disable them by format?
 
K - Offtopic: Posibility to enable/disable filters by context.
 
--[[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 03:29, 15 October 2008 (CDT)

Latest revision as of 11:23, 11 December 2009

Some concerns and ideas

On G:

  • "use special editor if available" should be yes/by demand/no, with "by demand" mode storing in user preferences where to use editor and where not - the cause is performance problems for some pages (I actually have one Moodle 2.0 page loaded (initialised actually) for 10 minutes cause of many editor instances on it, while I was really need to have 2 of these 30 instaces active), and this was a page for editing real question taked from production site;
  • "USED formats have precedence over USER settings, so editing existing texts won't change the format at all" - it would be too bad to have lock down on format after first editing - especially if you have a users with different OS/prefereed browsers creating and maintaining one course; I guess any format could define a range of another formats it could import data from and functions to do so, so some conversions would be possible (maybe after direct approval of the user). Or maybe make import functions pluginable so the people who need them could easily write and contribute them.

--Oleg Sychev 11:23, 11 December 2009 (UTC)