Jean-Vincent Drean wrote:

Hi,

I'd like to move Tags related pages to their own app: xwiki-application-tag. I'd also like to commit a small plugin that allows to manipulate tags easily. It also avoid the need of programming rights on pages Tags and TagsRss. The application and the plugin would have the same release cycle and would be included in xwiki enterprise (like skinx or watchlist plugins/apps). This also mean that we'll have a tag application in JIRA.

Tag pages :

- Main.TagCloud - Main.Tags - Main.TagsRss - XWiki.TagClass

Tag plugin API :

public List<String> getTags(boolean distinct); public List<String> getPagesWithTag(String tag); public boolean renameTag(String tag, String newTag);

Will come handy :)

public boolean deleteTag(String tag);

Here's my +1.

+1 Jerome

JV. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Jean-Vincent Drean wrote:

Hi,

I'd like to move Tags related pages to their own app: xwiki-application-tag. I'd also like to commit a small plugin that allows to manipulate tags easily. It also avoid the need of programming rights on pages Tags and TagsRss. The application and the plugin would have the same release cycle and would be included in xwiki enterprise (like skinx or watchlist plugins/apps). This also mean that we'll have a tag application in JIRA.

+1, with the remarks below:

Tag pages :

- Main.TagCloud - Main.Tags - Main.TagsRss - XWiki.TagClass

Tag plugin API :

public List<String> getTags(boolean distinct);

Is this global? I mean, does it get all tags found in the wiki, or just the tags for the current document? I'd like to also have a method to get tags for a document (+ for translations), since the getTags method does not belong to the Document class (although it is part of the current API, I'd like to see it removed in the new model). Maybe we should deprecate it after we add this plugin/application. What does "distinct" do? I'd rather have a caseSensitive parameter, or different methods for this.

public List<String> getPagesWithTag(String tag);

Pages? This is not our terminology.

public boolean renameTag(String tag, String newTag); public boolean deleteTag(String tag);

What happens when the user does not have the right to alter all the documents, only some of them? Will the changes appear in whatsnew? Will they create new versions? Will they change the author? We'd also need a method to get all tags with their occurrence count (for the tag cloud). So, how about this API: - List<String> getAllTags() -> all wiki tags, case insensitive (CI) - List<String> getAllTags(boolean caseInsensitive) -> all tags - HashMap<String, Integer> getTagCount() -> all wiki tags with occurrence, CI - HashMap<String, Integer> getTagCount(boolean caseInsensitive) -> all wiki tags with occurrence - List<String> getTagsForDocument(Document doc) -> document tags --> Debate: XWikiDocument, Document or String? Or all? - boolean addTagToDocument(String tag, Document doc) -> returns true if the tag was successfully added, false if the tag was already associated. Throws exceptions in other cases (not enough rights, db issues, etc). - boolean removeTagFromDocument(String tag, Document doc) -> returns true if the tag was successfully removed, false if the tag was not associated. Throws exceptions in other cases (not enough rights, db issues, etc). - public List<String> getDocumentsWithTag(String tag) - public boolean renameTag(String tag, String newTag) - public boolean deleteTag(String tag) Debate: how to identify a document If we use a string, then we'll have problems identifying the language; or, we extend the document name syntax to also support the language, like: wiki:Space.Document[lang] or wiki:Space.Document@lang. +: if we keep the same syntax for the new model, we'll be able to reuse the same API for both the old and new model. -: Usually this applies to the context document ($tdoc), which means that we'll have an extra clone, more memory, more cpu. If we use (only) XWikiDocument, we'll also need an API for it. +: easy to use from Java/groovy -: hard to use from Velocity -: migration to the new model If we use (only) Document, we'll be able to easily use this from velocity. +: easy to use from Velocity 0: a bit harder to use from Java -: migration to the new model. If we use all of these methods, then it will be easy to use the plugin both from Java and Velocity, but we'll have a large API. +: easy to use -: large API 0: migration to the new model, both easier because we simply add a new method, and harder because we must deprecate and support 2 signatures for each method. For the moment my preference goes to either using just a String, or to use all 3 methods. -- Sergiu Dumitriu http://purl.org/net/sergiu/