RFC: experimental branch for the DataModel and Journaling proposals
Christian Boos
Lately, I was working on the ticket #2945 (ticket with version control).
Like I commented on that ticket a while ago, we already had all the
needed information at hand, so adding this feature was merely adapting
what we already had in place for the Wiki module to the Ticket module.
Of course, the APIs and the datamodel are quite different and therefore
the implementation in the controllers differs a lot too.
But I'm sure you're familiar with this old motto of mine, "things
shouldn't need to be that way, as they're all Trac objects after all".
So while I've been ranting since a long time about the need to make
things a bit more homogeneous on the UI and data model levels (1), I've
recently made some progress about the possible solutions, most notably
by developing the DataModel proposal (2), the Journaling proposal (3)
and suggested a tab-based layout to solve some navigation issues (4).
So now I'd like to take this a step further and implement these ideas.
What makes it a bit difficult is that everything is inter-related, so I
was looking for some guideline. I think that following-up on the #2945
addition is inspiring in several ways:
1. On the presentation level, I could try out the idea of having tabs
for viewing a resource (''View'' and ''History'' tab for any given
resource).
2. On the presentation and API level, I could try to factor common
things between the wiki and ticket modules
3. On the data model side, I'd like to start to implement the DataModel
proposal for the Milestone, so that things like #1673 (History for
milestone description text) can get implemented. That would provide the
basis for a generic implementation that could afterwards be ported to
the Wiki and Ticket modules.
4. Likewise, implementing the Journaling changes on the level of the
Milestone would provide a new way to do the change listener interfaces
and notifications, that could later be retrofitted for the other modules
as well.
5. While working on the above, I hope to be able to further refine the
way one could have a minimal generic API for all the Trac resources, so
that I can revive my xref branch and turn it into a plugin. I'll
hopefully soon follow-up on that by writing a ResourceDescriptor proposal.
So that may seem to be a lot of things, but like I said, I'll probably
start small by doing the changes for the milestone only,in a way that
shouldn't require an "upgrade".
I don't know exactly what would be the best approach regarding branches:
- create small branches for each topic (e.g. tabs, history-refact,
datamodel, journaling, resource)
- let things evolve together in an experimental sandbox (e.g.
milestone-refactoring), as the different topics are inter-related; then,
when the approach stabilize, prepare new branches for retrofitting the
new data model to each existing module, one branch per module.
My favored approach would be a 'tabs' branch for point 1. do 2. on trunk
directly, and work on 3,4,5 on a 'milestone-refact' branch.
-- Christian
(1) - http://trac.edgewall.org/wiki/TracObjectModelProposal
(2) - http://trac.edgewall.org/wiki/TracDev/Proposals/DataModel
(3) - http://trac.edgewall.org/wiki/TracDev/Proposals/Journaling
(4) - http://trac.edgewall.org/wiki/TracProject/UiGuidelines
Ilias Lazaridis
> Hello again,
>
> Lately, I was working on the ticket #2945 (ticket with version control).
> Like I commented on that ticket a while ago, we already had all the
Very complex thing!
I can assist you in this in a unusual way:
by providing several small change-requests (possibly with some patch),
which will step by step require more and more abstraction of the
underlying ticket-system implementation.
This way you can clarify your thoughts, whilst using a 2nd independent
refactoring view.
My changes will mostly affect trunk and will be implemented as plugins
or dyna-patches agains 0.11dev.
Hope this makes sense.
.
Christian Boos
> I can assist you in this in a unusual way:
>
> by providing several small change-requests (possibly with some patch),
> which will step by step require more and more abstraction of the
> underlying ticket-system implementation.
>
Thanks for the offer, but I'd rather decline it for now, as additional
tickets _won't_ help right now in this phase. Once things have
progressed a bit, why not, but please no additional requirements by the
way of tickets, for now. I'd vastly prefer that you (or anyone else)
constructively criticizes the work in progress that will happen in the
branch(es). This kind of testing and review would be quite beneficial,
but as for the design, I think I know where I am going ;)
Plus, if you're interested in the topic, there's already a lot of design
discussion on those topics that you can dig in the Trac wiki and
tickets, reachable from the starting points I've given in the previous
mail. This material should help to build a common understanding.
-- Christian
Ilias Lazaridis
Sorry, I've not expressed myself clearly.
I've would like to follow the work and criticize it, but at least at
this point I cannot do it, as I focus on the development-plans on my
project.
http://dev.lazaridis.com/base/wiki/WorkingPlans
During this, I will file some tickets which subject generalization,
targeting the 0.11dev code-base. Unsolved tickets (wontifix, worksforme
etc.) will go as dynapatches into my project.
Those tickets _could_ help you - or possibly not, but I file them
anyway as the part of my work.
-
In this context (your work on DataModel/Jounaling etc., my further
work), I like to point to one thread which should be important for
_anyone_ who likes to do serious work on the trac sources, but which
remained unanswered till now:
PROJECT - Decoupling Core (Framework) from Trac (Application)
http://groups.google.com/group/trac-dev/browse_frm/thread/094c62b02b2c4b33/#
The seperation of the trac _core_ framework should start immediately
within 0.11dev.
.
Christian Boos
> Christian Boos wrote:
>
>> ... as additional tickets _won't_ help right now in this phase.
>> <snip>
>
> Sorry, I've not expressed myself clearly.
>
>
> During this, I will file some tickets which subject generalization,
> targeting the 0.11dev code-base. Unsolved tickets (wontifix, worksforme
> etc.) will go as dynapatches into my project.
>
> Those tickets _could_ help you - or possibly not, but I file them
> anyway as the part of my work.
>
Right, this is clearer. Please do so, then.
> In this context (your work on DataModel/Jounaling etc., my further
> work), I like to point to one thread which should be important for
> _anyone_ who likes to do serious work on the trac sources, but which
> remained unanswered till now:
>
Well, I think you got no response to that mail because going in the
direction of decoupling the core from the subsystems (and eventually
insulating those subsystems) was always the plan, I think, but this is
something that will eventually happen "naturally", after the setuptools
branch is completed. Nobody else feels the need to hurry in that
direction, that's why the discussion stalled (or never started).
Lack of response is also a response, sometimes ...
... which brings me back to the topic of this thread: guys, I *really*
want to start to work on the topics addressed by the initial mail, so
just to be clear, I'll interpret lack of response as "I don't care,
please do" ;)
-- Christian
Emmanuel Blot
> please do" ;)
This is not that I don't care - I do - but I really lack time to go
through this proposal (so, yes: please do). I'd also like to test the
Pygments patch...
Cheers,
Manu
Ilias Lazaridis
> Hello again,
> I've
> recently made some progress about the possible solutions, most notably
> by developing the DataModel proposal (2),
I've overflown this:
http://trac.edgewall.org/wiki/TracDev/Proposals/DataModel#TheGenericModel
this would be implement very simple by using a Inheritance Capable
Persistency mechanism, e.g. an ORM with a decent OO layer.
The whole planning looks to me like a current-state
(spaghetti-code/SQL) to OO refactoring.
.
Ilias Lazaridis
> Ilias Lazaridis wrote:
> > In this context (your work on DataModel/Jounaling etc., my further
> > work), I like to point to one thread which should be important for
> > _anyone_ who likes to do serious work on the trac sources, but which
> > remained unanswered till now:
> >
>
> Well, I think you got no response to that mail because going in the
> direction of decoupling the core from the subsystems (and eventually
> insulating those subsystems) was always the plan, I think, but this is
> something that will eventually happen "naturally", after the setuptools
> branch is completed. Nobody else feels the need to hurry in that
> direction, that's why the discussion stalled (or never started).
...
Many things are natural, but in order to manage the complexity, the
team should start to _discuss_ and _document_ and especially _plan_ the
tasks, e.g. whilst using a project management tool (which one should
the team use?).
"Decoupling Core" relates to the task described in this thread, to the
sqlalchemy migration, and especially to the workflow branch (which
itself relates to the task described in this thread again).
short: the planned tasks are interrelated, and should be documented to
gain some clarity.
PROJECT - Decoupling Core (Framework) from Trac (Application)
http://groups.google.com/group/trac-dev/browse_thread/thread/094c62b02b2c4b33/#
.