Changes between Version 32 and Version 33 of TracDev/ApiChanges/0.11
- Timestamp:
- Mar 13, 2008, 2:24:53 PM (16 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
TracDev/ApiChanges/0.11
v32 v33 26 26 27 27 Since r3935, Trac uses `datetime` objects internally, instead of timestamps. 28 More precisely, the database layer still uses `int` timestamps, but manipulation of time values is now done on `datetime` objects as soon as possible, see e.g. the [source:t runk/trac/Timeline.py Timeline] module.28 More precisely, the database layer still uses `int` timestamps, but manipulation of time values is now done on `datetime` objects as soon as possible, see e.g. the [source:tags/trac-0.11b2/trac/Timeline.py Timeline] module. 29 29 30 Those `datetime` values are directly added by the controllers to the data model, and it's the responsibility of the ''templates'' to pick up the appropriate time representation, using one of the built-in date formatting utilities: `format_date`, `format_datetime`, `http_date`, `pretty_timedelta` (see [source:t runk/trac/chrome.py chrome.py]), or even the `$dateinfo()` macro.30 Those `datetime` values are directly added by the controllers to the data model, and it's the responsibility of the ''templates'' to pick up the appropriate time representation, using one of the built-in date formatting utilities: `format_date`, `format_datetime`, `http_date`, `pretty_timedelta` (see [source:tags/trac-0.11b2/trac/chrome.py chrome.py]), or even the `$dateinfo()` macro. 31 31 32 32 Those utilities automatically take into account the ''timezone'' information set by the user, so that the dates are presented in a meaningful way to him. … … 36 36 The Trac macros will need to be adapted: 37 37 - the old-style wiki-macros are not supported anymore (due to the drop of ClearSilver and the HDF); they need to be converted to the new-style macros 38 - new-style macros are [#IWikiMacroProvider] plugins. They can be written as full plugins or simple one file drop-in plugins, see source:t runk/sample-plugins for some examples (TODO: source:tags/trac-0.11/sample-plugins/macros)38 - new-style macros are [#IWikiMacroProvider] plugins. They can be written as full plugins or simple one file drop-in plugins, see source:tags/trac-0.11b2/sample-plugins for some examples (TODO: source:tags/trac-0.11/sample-plugins/macros) 39 39 40 40 === Modified Interfaces === 41 ==== `ITimelineEventProvider` ^[source:t runk/trac/timeline/api.py@head#L87 (0.11)] [source:tags/trac-0.10/trac/Timeline.py@head#L32 (0.10)]^ ==== #ITimelineEventProvider41 ==== `ITimelineEventProvider` ^[source:tags/trac-0.11b2/trac/timeline/api.py@#L28 (0.11)] [source:tags/trac-0.10/trac/Timeline.py@#L32 (0.10)]^ ==== #ITimelineEventProvider 42 42 43 43 First thing, the timeline module has now its own package (`trac.timeline`), and the ITimelineEventProvider interface itself should now be imported from `trac.timeline`. However, note that the case has changed here, as you would previously have imported `trac.Timeline`. If you want to support both versions, try something like this: … … 75 75 }}} 76 76 77 ==== `ISearchSource` ^[source:t runk/trac/search/api.py@head#L17 (0.11)] [source:tags/trac-0.10/trac/search.py@head#L30 (0.10)]^ ==== #ISearchSource77 ==== `ISearchSource` ^[source:tags/trac-0.11b2/trac/search/api.py@#L17 (0.11)] [source:tags/trac-0.10/trac/Search.py@#L30 (0.10)]^ ==== #ISearchSource 78 78 79 79 Similar to the timeline package, the search module has also been migrated to a package (`trac.search`), with the same case change. Again, if you want to support both versions, try something like this: … … 87 87 }}} 88 88 89 ==== `IWikiMacroProvider` ^[source:t runk/trac/wiki/api.py@head#L73 (0.11)] [source:tags/trac-0.10/trac/wiki/api.py@head#L70 (0.10)]^ ==== #IWikiMacroProvider89 ==== `IWikiMacroProvider` ^[source:tags/trac-0.11b2/trac/wiki/api.py@#L77 (0.11)] [source:tags/trac-0.10/trac/wiki/api.py@#L70 (0.10)]^ ==== #IWikiMacroProvider 90 90 91 91 - `render_macro(req, name, content)` has been deprecated (see r4621) … … 102 102 `render_macro(req, name, content)` will likely be removed in [milestone:0.12]. 103 103 104 ==== `IHTMLPreviewRenderer` ^[source:t runk/trac/wiki/api.py@head#L213 (0.11)] [source:tags/trac-0.10/trac/wiki/api.py@head#L209 (0.10)]^ ==== #IHTMLPreviewRenderer104 ==== `IHTMLPreviewRenderer` ^[source:tags/trac-0.11b2/trac/mimeview/api.py@#L367 (0.11)] [source:tags/trac-0.10/trac/mimeview/api.py@#L209 (0.10)]^ ==== #IHTMLPreviewRenderer 105 105 106 106 Similar to the above change, `render(req, mimetype ...)` is now `render(context, mimetype ...)`, `context` being a rendering `Context` (see below). 107 107 It doesn't matter that much however, as it looks like that this interface is going to be integrated in `IContentConverter` anyway (see #3332 - 0.12 topic unfortunately). 108 108 109 ==== `IRequestFilter` ^[source:tags/trac-0.11b2/trac/web/api.py@ head#L539 (0.11)] [source:tags/trac-0.10/trac/web/api.py@head#L467 (0.10)]^ ==== #IRequestFilter109 ==== `IRequestFilter` ^[source:tags/trac-0.11b2/trac/web/api.py@#L539 (0.11)] [source:tags/trac-0.10/trac/web/api.py@#L467 (0.10)]^ ==== #IRequestFilter 110 110 111 111 The `post_process_request` method has now the following arguments `(req, template, data, content_type)` instead of `(req, template, content_type)`. `data` is the data dictionary used while generating the template. … … 123 123 124 124 === New Classes === 125 ==== `trac.resource.Resource` ==== #Resource125 ==== `trac.resource.Resource` ^[source:tags/trac-0.11b2/trac/resource.py@#L75 (0.11)]^ ==== #Resource 126 126 127 127 The '''resource identifier''' class `Resource` is used to specify in a convenient way which Trac ''resources'' is being manipulated. … … 132 132 Finally, a resource can be parented in another resource. This relationship usually means that a removal of the parent resource implies a removal of the children resources. 133 133 134 ==== `trac.mimeview.api.Context` ==== #Context134 ==== `trac.mimeview.api.Context` ^[source:tags/trac-0.11b2/trac/mimeview/api.py@#L78 (0.11)]^ ==== #Context 135 135 136 136 The '''rendering context''' class is used to specify ''how'' the content should be rendered. … … 143 143 144 144 === New Interfaces === 145 ==== `trac.resource.IResourceManager` ==== #IResourceManager145 ==== `trac.resource.IResourceManager` ^[source:tags/trac-0.11b2/trac/resource.py@#L28 (0.11)]^ ==== #IResourceManager 146 146 147 147 The `IResourceManager` let components claim ownership of some realms. … … 149 149 Various utility functions exist in the `trac.resource` module in order to manipulate the `Resource` identifier objects in a generic way. 150 150 151 ==== `trac.perm.IPermissionPolicy` ^[source:t runk/trac/perm.py@6242#L107 (0.11)]^ ==== #IPermissionPolicy151 ==== `trac.perm.IPermissionPolicy` ^[source:tags/trac-0.11b2/trac/perm.py@#L107 (0.11)]^ ==== #IPermissionPolicy 152 152 153 153 The `IPermissionPolicy` components can be used to grant or reject any kind of permissions, based on the identity of the user and the targeted resource, subject of the action. The API is conceptually simple, as the permission policies are chained (using the sequence defined in the `[trac] permission_policies` configuration entry), and the first policy in the chain which makes a decision about the given (action, user, resource) triple wins. Making a decision consist in returning `True` for allowing the action, `False` for rejecting the action. `None` can also be returned to let the next policy in the chain decide. If no decision has been made in the end, the action is not allowed. … … 155 155 Look at the API documentation for a few more details (what to return when no resource or a "realm" resource is specified, usage of the permission cache). 156 156 157 ==== `trac.attachment.ILegacyAttachmentDelegate` ^[source:t runk/trac/attachment.py@6242#L82 (0.11)]^ ==== #ILegacyAttachmentDelegate157 ==== `trac.attachment.ILegacyAttachmentDelegate` ^[source:tags/trac-0.11b2/trac/attachment.py@#L82 (0.11)]^ ==== #ILegacyAttachmentDelegate 158 158 This interface is mostly like the above [#IPermissionPolicy IPermissionPolicy] one, except that it enables attachment providers to hook automatically into the default legacy attachment policy, which is already enabled by default. 159 159 160 ==== `trac.ticket.api.ITicketActionController` ==== #ITicketActionController160 ==== `trac.ticket.api.ITicketActionController` ^[source:tags/trac-0.11b2/trac/ticket/api.py@#L33 (0.11)]^ ==== #ITicketActionController 161 161 162 162 TBD. See TracWorkflow. 163 163 164 ==== `trac.ticket.roadmap.ITicketGroupStatsProvider` ==== #ITicketGroupStatsProvider164 ==== `trac.ticket.roadmap.ITicketGroupStatsProvider` ^[source:tags/trac-0.11b2/trac/ticket/roadmap.py@#L45 (0.11)]^ ==== #ITicketGroupStatsProvider 165 165 166 166 TBD. 167 167 168 ==== `trac.web.ITemplateStreamFilter` ==== #ITemplateStreamFilter168 ==== `trac.web.ITemplateStreamFilter` ^[source:tags/trac-0.11b2/trac/web/api.py@#L576 (0.11)]^ ==== #ITemplateStreamFilter 169 169 170 170 In Trac 0.11, while it's still possible to customize the Genshi templates like it was for the Clearsilver ones in previous versions, this is no longer the only way, neither the preferred. What makes the use of the Genshi templating system fairly unique is that you can manipulate the generated output at run-time, in order to filter out some content, modify it or even inject new content. … … 172 172 173 173 Some useful references: 174 - [http://trac.edgewall.org/browser/t runk/sample-plugins/ticket_clone.py sample-plugins/ticket_clone.py], an example of such a plugin, which adds a "Clone" button in the ticket description box:174 - [http://trac.edgewall.org/browser/tags/trac-0.11b2/sample-plugins/ticket_clone.py sample-plugins/ticket_clone.py], an example of such a plugin, which adds a "Clone" button in the ticket description box: 175 175 - [genshi:wiki:ApiDocs/genshi.filters.transform genshi.filters.transform], the API documentation for genshi transform filters which makes such manipulations a breeze 176 176 177 177 178 ==== `trac.prefs.api.IPreferencePanelProvider` ==== #IPreferencePanelProvider178 ==== `trac.prefs.api.IPreferencePanelProvider` ^[source:tags/trac-0.11b2/trac/prefs/api.py (0.11)]^ ==== #IPreferencePanelProvider 179 179 180 180 TBD. 181 181 182 ==== `trac.versioncontrol.web_ui.browser.IPropertyRenderer` ^[source:t runk/trac/versioncontrol/web_ui/browser.py@head#L46 (0.11)]==== #IPropertyRenderer182 ==== `trac.versioncontrol.web_ui.browser.IPropertyRenderer` ^[source:tags/trac-0.11b2/trac/versioncontrol/web_ui/browser.py@#L48 (0.11)]^ ==== #IPropertyRenderer 183 183 184 184 The presentation of version control properties for files and directories can be customized to a great extent. 185 185 The revision properties can be customized in a similar way. 186 186 187 ==== `trac.versioncontrol.web_ui.changeset.IPropertyDiffRenderer` ^[source:t runk/trac/versioncontrol/web_ui/changeset.py@head#L51 (0.11)]==== #IPropertyDiffRenderer187 ==== `trac.versioncontrol.web_ui.changeset.IPropertyDiffRenderer` ^[source:tags/trac-0.11b2/trac/versioncontrol/web_ui/changeset.py@#L52 (0.11)]^ ==== #IPropertyDiffRenderer 188 188 189 189 Likewise, the presentation of changes for version control properties can be customized. 190 190 191 ==== `trac.admin.api.IAdminPanelProvider` ==== #IAdminPanelProvider 191 ==== `trac.admin.api.IAdminPanelProvider` ^[source:tags/trac-0.11b2/trac/admin/api.py (0.11)]^ ==== #IAdminPanelProvider 192 192 193 !WebAdmin is now part of the core. 193 194 The previously external interface `webadmin.web_ui.IAdminPageProvider` is now a core interface: `trac.admin.api.IAdminPanelProvider`.
