Changes between Version 14 and Version 15 of TracObjectModelProposal
- Timestamp:
- Apr 8, 2016, 9:43:45 PM (8 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
TracObjectModelProposal
v14 v15 1 = Trac Object Model Proposal =1 = Trac Object Model Proposal 2 2 3 ''This proposal is about unifying the capabilities of the various Trac objects, 4 by making them inherit from a common `TracObject` class. 5 The goal is to expand the feature set of Trac while simplifying its implementation.'' 3 ''This proposal is about unifying the capabilities of the various Trac objects, by making them inherit from a common `TracObject` class. The goal is to expand the feature set of Trac while simplifying its implementation.'' 6 4 7 == Introduction ==5 == Introduction 8 6 9 7 === What is Trac? === 10 8 11 Trac is a ''a minimalistic approach to web-based software project management''. 12 To that end, it features ''an enhanced wiki and issue tracking system''. 9 Trac is a ''a minimalistic approach to web-based software project management''. It features ''an enhanced wiki and issue tracking system''. 13 10 14 The tight and coherent integration of its features is achieved by several means, 15 but most notably by the consistent use of a unified ''language'' to talk about 16 objects in the system (the TracLinks). 11 The tight and coherent integration of its features is achieved by several means, but most notably by the consistent use of a unified ''language'' to talk about objects in the system (the TracLinks). 17 12 18 This unique approach enables a powerful structuring of the information 19 in the system, yet this can be achieved in a very flexible and informal way. 13 This approach enables a powerful structuring of the information in the system, yet this can be achieved in a very flexible and informal way. 20 14 21 In this light, Trac is a semi-structured Wiki, where one can create and modify 22 ''objects'' and talk about them 15 In this light, Trac is a semi-structured Wiki, where one can create and modify ''objects'' and talk about them. 23 16 17 === Trac Object Model 24 18 25 === Trac Object Model === 19 In the following, I'll try to show that Trac is a manager for typed pieces of informations: the Trac ''objects''. 26 20 27 In the following, I'll try to show that Trac is a manager for typed pieces 28 of informations: the Trac ''objects''. 29 30 There are many advantages to gain by refactoring the internals of Trac 31 to acknowledge this reality: 21 There are many advantages to gain by refactoring the internals of Trac to acknowledge this reality: 32 22 * more consistency, less redundancy, code simplication 33 23 * spreading the features available for one object to the other objects 34 24 35 This updated revision is made in light of the experience gathered 36 while working on the TracCrossReferences feature: 37 for implementing generalized back links, I had to have a 38 common interface to all the Trac objects, this was a practical 39 reason to introduce the `TracObject` 40 (see source:sandbox/trac-xref/trac/object.py). 25 This updated revision is made through the experience gathered while working on the TracCrossReferences feature: for implementing generalized back links, I had to have a common interface to all the Trac objects, this was a practical 26 reason to introduce the `TracObject` (see source:sandbox/trac-xref/trac/object.py). 41 27 42 43 == Trac Objects == 28 == Trac Objects 44 29 45 30 What can be considered a Trac object (`TracObject`) are: … … 51 36 * sources (''Source'') 52 37 38 === Current State in `trunk` 53 39 40 Today, the various Trac objects are quite distinct objects. There is no code sharing between what defines objects and also not so much in the related modules that manipulate objects. 54 41 55 === Current State in `trunk` === 42 Indeed, those objects have distinct features. But some degree of unification would actually make sense, both in term of increased functionality and in term of decreased code complexity. 56 43 57 Today, the various Trac objects are quite distinct objects. 58 There is no code sharing between what defines objects 59 and also not so much in the related modules that manipulates 60 objects. 44 Last discussed examples were the ability to add comments on various objects, (this [http://thread.gmane.org/gmane.comp.version-control.subversion.trac.general/5609 thread], ticket #2035), the ability to query over other objects than just the tickets (#2465), and several other examples (query:keywords~=object). 61 45 62 Indeed, those objects have distinct features. 63 But some degree of unification would actually make sense, 64 both in term of increased functionality and in term of 65 decreased code complexity. 66 67 Last discussed examples were the ability to add comments 68 on various objects, 69 (this [http://thread.gmane.org/gmane.comp.version-control.subversion.trac.general/5609 thread], ticket #2035), the ability to query over other 70 objects than just the tickets (#2465), and several other examples 71 (query:keywords~=object). 72 73 74 === Toward an Unification === 46 === Towards an Unification 75 47 76 48 What would be a generic Trac object? … … 103 75 (like the ''Change History'' for a Ticket) 104 76 105 Let's compare these generic features with those of current Trac objects 106 and see what additional functionality and usages it would provide. 77 Let's compare these generic features with those of current Trac objects and see what additional functionality and usage it would provide. 107 78 108 ==== Wiki Page ====79 ==== Wiki Page 109 80 110 81 The Wiki Page object would gain the ability to have custom fields. 111 82 112 113 ==== Changeset ==== 83 ==== Changeset 114 84 115 85 The changeset message can be considered to be a ''facet'' for that object. 116 Editing the message would be handled very similarly to editing the wiki 117 page content (see #781). It will be versioned, like the content for wiki 118 pages are. 86 Editing the message would be handled very similar to editing the wiki page content (see #781). It will be versioned, like the content for wiki pages are. 119 87 120 If the underlying VersioningSystemBackend supports it, the change 121 could be reflected in the repository itself (not all versioning 122 systems support that: e.g. SVN does, Mercurial does not). 123 A `resync` operation would simply add a new revision for the 124 message, if something changed. 88 If the underlying VersionControlSystem supports it, the change could be reflected in the repository itself. Not all versioning systems support that: e.g. SVN does, but Mercurial does not. A `resync` operation would simply add a new revision for the message, if something changed. 125 89 126 Custom properties could be used for many things, as a way to annotate 127 the revision. Some ideas are: 128 * a boolean ''compilable'' flag (true by default, could be set to 129 false to indicate that this revision can't be built) 90 Custom properties could be used for many things, as a way to annotate the revision. Some ideas are: 91 * a boolean ''compilable'' flag (true by default, could be set to false to indicate that this revision can't be built) 130 92 * a field indicating the % of successful test cases 131 93 * a QA status 132 94 133 95 Attachments for a changeset also make sense: 134 * in case of a build failure, the corresponding errors from the compiler 135 could be attached. 136 * patches that applies to that revision 96 * in case of a build failure, the corresponding errors from the compiler could be attached. 97 * patches that applies to that revision. 137 98 138 The contributed comments could be used for code reviews 99 The contributed comments could be used for code reviews. 139 100 140 101 It would also be nice to be able to query changesets (see #2465). 141 102 142 143 ==== Ticket ==== 103 ==== Ticket 144 104 145 There's currently no way to have an history of the description facet. 146 Otherwise, the Ticket has pretty much all of the generic functionality. 105 There's currently no way to have an history of the description facet. Otherwise, the Ticket has pretty much all of the generic functionality. 147 106 148 107 There's also the question of having greater flexibility for ticket fields: 149 108 * different sets of fields for different types of tickets (see #2464) 150 * less difference between custom ticket fields and ''normal'' ticket fields 151 (some kind of unification would be great here) 109 * less difference between custom ticket fields and ''normal'' ticket fields (some kind of unification would be great here) 152 110 * possibility to have multiple values for a field (see #221, #918 and #1730) 153 111 154 There's also the question of bringing together Milestone 155 and Ticket objects for implementing SubTickets. 112 There's also the question of bringing together Milestone and Ticket objects for implementing SubTickets. 156 113 114 ==== Source 157 115 158 ==== Source ==== 159 160 Currently, there's no facet attached to a source. 161 One could imagine having a summary or description facet. 162 This could give a repository browsing experience close 163 to what Sun did for 164 [http://cvs.opensolaris.org/source/xref/on/usr/src/ OpenSolaris]. 116 Currently, there's no facet attached to a source. One could imagine having a summary or description facet. 117 This could give a repository browsing experience close to what Sun did for [http://cvs.opensolaris.org/source/xref/on/usr/src/ OpenSolaris]. 165 118 166 119 ''--ChristianBoos'' 167 120 168 ==== Enterprise Objects ====121 ==== Enterprise Objects 169 122 170 123 > SOAP/REST support, permissions and security, in TRAC Objects could allow interface to … … 174 127 I'm not completely sure about what Jim meant in the above, but there's certainly a connection between this proposal and the security aspects, as can be seen in Alec's [TracDev/SecurityBranch permission policy] proposal. 175 128 176 === Related Proposals ===129 === Related Proposals 177 130 178 - TracDev/Proposals/DataModel - common data structures for all the Trac resources 179 - TracDev/Proposals/Journaling - focusing on the data structures, APIs and interfaces dealing with changes happening in Trac objects 180 - TracCrossReferences - generalized back-references and relationships between Trac objects 131 - TracDev/Proposals/DataModel - common data structures for all the Trac resources. 132 - TracDev/Proposals/Journaling - focusing on the data structures, APIs and interfaces dealing with changes happening in Trac objects. 133 - TracCrossReferences - generalized back-references and relationships between Trac objects.
