Edgewall Software

Changes between Version 14 and Version 15 of TracObjectModelProposal


Ignore:
Timestamp:
Apr 8, 2016, 9:43:45 PM (3 years ago)
Author:
figaro
Comment:

Cosmetic changes

Legend:

Unmodified
Added
Removed
Modified
  • TracObjectModelProposal

    v14 v15  
    1 = Trac Object Model Proposal =
     1= Trac Object Model Proposal
    22
    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.''
    64
    7 == Introduction ==
     5== Introduction
    86
    97=== What is Trac? ===
    108
    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''.
     9Trac is a ''a minimalistic approach to web-based software project management''. It features ''an enhanced wiki and issue tracking system''.
    1310
    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).
     11The 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).
    1712   
    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.
     13This approach enables a powerful structuring of the information in the system, yet this can be achieved in a very flexible and informal way.
    2014
    21 In this light, Trac is a semi-structured Wiki, where one can create and modify
    22 ''objects'' and talk about them
     15In this light, Trac is a semi-structured Wiki, where one can create and modify ''objects'' and talk about them.
    2316
     17=== Trac Object Model
    2418
    25 === Trac Object Model ===
     19In the following, I'll try to show that Trac is a manager for typed pieces of informations: the Trac ''objects''.
    2620
    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:
     21There are many advantages to gain by refactoring the internals of Trac to acknowledge this reality:
    3222 * more consistency, less redundancy, code simplication
    3323 * spreading the features available for one object to the other objects
    3424
    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).
     25This 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
     26reason to introduce the `TracObject` (see source:sandbox/trac-xref/trac/object.py).
    4127
    42 
    43 == Trac Objects ==
     28== Trac Objects
    4429
    4530What can be considered a Trac object (`TracObject`) are:
     
    5136 * sources (''Source'')
    5237
     38=== Current State in `trunk`
    5339
     40Today, 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.
    5441
    55 === Current State in `trunk` ===
     42Indeed, 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.
    5643
    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.
     44Last 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).
    6145
    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
    7547
    7648What would be a generic Trac object?
     
    10375      (like the ''Change History'' for a Ticket)
    10476
    105 Let's compare these generic features with those of current Trac objects
    106 and see what additional functionality and usages it would provide.
     77Let's compare these generic features with those of current Trac objects and see what additional functionality and usage it would provide.
    10778
    108 ==== Wiki Page ====
     79==== Wiki Page
    10980
    11081The Wiki Page object would gain the ability to have custom fields.
    11182
    112 
    113 ==== Changeset ====
     83==== Changeset
    11484
    11585The 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.
     86Editing 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.
    11987
    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.
     88If 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.
    12589
    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)
     90Custom 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)
    13092 * a field indicating the % of successful test cases
    13193 * a QA status
    13294
    13395Attachments 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.
    13798
    138 The contributed comments could be used for code reviews
     99The contributed comments could be used for code reviews.
    139100
    140101It would also be nice to be able to query changesets (see #2465).
    141102
    142  
    143 ==== Ticket ====
     103==== Ticket
    144104
    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.
     105There's currently no way to have an history of the description facet. Otherwise, the Ticket has pretty much all of the generic functionality.
    147106
    148107There's also the question of having greater flexibility for ticket fields:
    149108 * 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)
    152110 * possibility to have multiple values for a field (see #221, #918 and #1730)
    153111
    154 There's also the question of bringing together Milestone
    155 and Ticket objects for implementing SubTickets.
     112There's also the question of bringing together Milestone and Ticket objects for implementing SubTickets.
    156113
     114==== Source
    157115
    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].
     116Currently, there's no facet attached to a source. One could imagine having a summary or description facet.
     117This could give a repository browsing experience close to what Sun did for [http://cvs.opensolaris.org/source/xref/on/usr/src/ OpenSolaris].
    165118
    166119''--ChristianBoos''
    167120
    168 ==== Enterprise Objects ====
     121==== Enterprise Objects
    169122
    170123> SOAP/REST support, permissions and security, in TRAC Objects could allow interface to
     
    174127I'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.
    175128
    176 === Related Proposals ===
     129=== Related Proposals
    177130
    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.