|
|
| Participants: |
Mathieu Petit-Clair
|
| Security Level: |
None
|
| Resolved date: |
18/Mar/08
|
| Affected Branches: |
MOODLE_19_STABLE, MOODLE_20_STABLE
|
| Fixed Branches: |
MOODLE_19_STABLE
|
|
The current API for tags isn't optimal. Some operations are done in tag/lib.php, some in blog/lib.php, some in blocks/... This aims to clean up the current API, makit it easier to expend the tags functions in moodle.
I'm sending a first file, containing only documentation and prototypes. I'm trying to come up with something that does the job, but is as minimal as possible.
Missing from this file are:
* tag_selection_box(...): a function to display the "tag selection box", so that all forms display the same interface to the user (which is currently not the case: user interests and blog posts have different ways of getting tags)
* tag_get_links(...): a function to return the tags along with the html links to them
* ...?
|
|
Description
|
The current API for tags isn't optimal. Some operations are done in tag/lib.php, some in blog/lib.php, some in blocks/... This aims to clean up the current API, makit it easier to expend the tags functions in moodle.
I'm sending a first file, containing only documentation and prototypes. I'm trying to come up with something that does the job, but is as minimal as possible.
Missing from this file are:
* tag_selection_box(...): a function to display the "tag selection box", so that all forms display the same interface to the user (which is currently not the case: user interests and blog posts have different ways of getting tags)
* tag_get_links(...): a function to return the tags along with the html links to them
* ...?
|
Show » |
|
Sub-task
Resolved
Major
Though, while on the subject, I was thinking that it might eventually be an option not to normalize it and let users use whatever they want as tag.