[RFC] timeline-refactoring branch created

10 views
Skip to first unread message

Christian Boos

unread,
Nov 9, 2007, 1:40:09 PM11/9/07
to Trac Development
Hi again,

This is the last RFC for today ;-)

Now that the context-refactoring branch is in trunk and that most ticket
have a patch ready, this is the last big task remaining before the beta1.

In this refactoring, the TimelineEvent class is gone, and instead the
ITimelineEventProvider.get_timeline_events() method has been changed to
return a tuple that can contain "private" data which the provider will
use in a second step in a ITimelineEventProvider.render_timeline_event()
method. The advantage being that the rendering is done only when
actually needed (some events might be skipped due to the limit
parameter) and a great degree of flexibility about the presentation of
the event is preserved.


Highlight on the interesting ITimelineEventProvider API changes:

def get_timeline_events(req, start, stop, filters):
"""Return a list of events in the time range given by the
`start` and
`stop` parameters.

The `filters` parameters is a list of the enabled filters, each item
being the name of the tuples returned by `get_timeline_filters`.

Since 0.11, the events are `(kind, date, author, data)` tuples,
where `kind` is a string used for categorizing the event, `date`
is a `datetime` object, `author` is a string and `data` is some
private data that the component will reuse when rendering the event.

When the event has been created indirectly by another module,
like this happens when calling
`AttachmentModule.get_timeline_events()`
the tuple can also specify explicitly the provider by returning
tuples
of the following form: `(kind, date, author, data, provider)`.

Before version 0.11, the events returned by this function used to
be tuples of the form `(kind, href, title, date, author, markup)`.
This is still supported but less flexible, as `href`, `title` and
`markup` are not context dependent.
"""

def render_timeline_event(context, field, event):
"""Display the title of the event in the given context.

:param context: the rendering `Context` object that can be used for
rendering
:param field: what specific part information from the event should
be rendered: can be the 'title', the 'description' or
the 'url'
:param event: the event tuple, as returned by `get_timeline_events`
"""


See r6141 for the full changeset.

Comments welcomed.


-- Christian

Christian Boos

unread,
Nov 13, 2007, 11:59:58 AM11/13/07
to trac...@googlegroups.com
Christian Boos wrote:
> Hi again,

>
> Now that the context-refactoring branch is in trunk and that most ticket
> have a patch ready, this is the last big task remaining before the beta1.
>

Please let me know if you see any problem with the merge of the above
branch.

The full set of changes is visible here:
http://trac.edgewall.org/changeset?new=sandbox%2Ftimeline-refactoring%406156&old=trunk%406156

Likewise, most of the remaining 0.11 tickets have now a patch ready, and
I'm going to apply them in the coming days if there's no further comment
on them.

After that, I think we'll be ready for a 0.11beta1 release
If there's no major issue uncovered till then, looks like it would be
doable for the end of this week.

-- Christian

Alec Thomas

unread,
Nov 15, 2007, 12:34:21 AM11/15/07
to trac...@googlegroups.com
On 11/14/07, Christian Boos <cb...@neuf.fr> wrote:
> Please let me know if you see any problem with the merge of the above
> branch.
>
> The full set of changes is visible here:
> http://trac.edgewall.org/changeset?new=sandbox%2Ftimeline-refactoring%406156&old=trunk%406156

This looks very nice Christian. Nice and clean.

+1

> Likewise, most of the remaining 0.11 tickets have now a patch ready, and
> I'm going to apply them in the coming days if there's no further comment
> on them.

I'll try and have a look at those tonight.

--
Evolution: Taking care of those too stupid to take care of themselves.

Jeroen Ruigrok van der Werven

unread,
Nov 15, 2007, 5:34:40 AM11/15/07
to trac...@googlegroups.com
-On [20071113 18:00], Christian Boos (cb...@neuf.fr) wrote:
>Likewise, most of the remaining 0.11 tickets have now a patch ready, and
>I'm going to apply them in the coming days if there's no further comment
>on them.

Can anyone with a pgsql instance see if my reported
http://trac.edgewall.org/ticket/6348 also has the same issue there? I only
have SQLite instances at the moment.

--
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/
Your lunacy fits in neatly with my own, my very own...

Christian Boos

unread,
Nov 15, 2007, 6:17:00 AM11/15/07
to trac...@googlegroups.com
Jeroen Ruigrok van der Werven wrote:
> -On [20071113 18:00], Christian Boos (cb...@neuf.fr) wrote:
>
>> Likewise, most of the remaining 0.11 tickets have now a patch ready, and
>> I'm going to apply them in the coming days if there's no further comment
>> on them.
>>
>
> Can anyone with a pgsql instance see if my reported
> http://trac.edgewall.org/ticket/6348 also has the same issue there? I only
> have SQLite instances at the moment.
>

Yeah, it's a "known" issue and there's probably several duplicate tickets.
Bottom line is that all backends have different ways to report
constraint violations:

pysqlite2.dbapi2.IntegrityError: columns username, action are not unique
_mysql_exceptions.IntegrityError: (1062, "Duplicate entry
'cboos-TICKET_ADMIN' for key 1")
psycopg2.IntegrityError: duplicate key violates unique constraint
"permission_pk"

What we need is to trap that at the level of each backend and raise a
TracIntegrityError instead that we can handle in the upper levels.
That's not a blocker for 0.11, though.

-- Christian

Christian Boos

unread,
Nov 16, 2007, 11:20:09 AM11/16/07
to trac...@googlegroups.com
Alec Thomas wrote:
> On 11/14/07, Christian Boos <cb...@neuf.fr> wrote:
>
>> Likewise, most of the remaining 0.11 tickets have now a patch ready, and
>> I'm going to apply them in the coming days if there's no further comment
>> on them.
>>
>
> I'll try and have a look at those tonight.
>

Extended time for review, as I won't be able to do anything more till
Monday.

... at which point, if there's no big concerns raised, I'm going to
commit like crazy and call that beta one ;-)

-- Christian

Alec Thomas

unread,
Nov 18, 2007, 12:16:37 AM11/18/07
to trac...@googlegroups.com
On 11/17/07, Christian Boos <cb...@neuf.fr> wrote:
> Extended time for review, as I won't be able to do anything more till
> Monday.
>
> ... at which point, if there's no big concerns raised, I'm going to
> commit like crazy and call that beta one ;-)

#153 Email address obfuscation/truncating

+1

My only question is why you accumulate into email_cells rather than just
formatting the cell in the main loop?

#1440 Remove reached milestones from edit ticket list

No real opinion, +0

#2048 Wiki macros for generating `<div>`s and `<span>`s with classes

I like this style much better than the original proposed "}}}.class"
one. Only real question is do we need the ";" separators? It would
seem more in-keeping with normal HTML to simply have:

{{{
#!div class="foo" style="foo bar"

...
}}}


#2259 No notification email when adding an attachment to a ticket

+1

#2914 would be nice to have optional automatic line breaks in ticket
descriptions and comments

+1, LGTM.

#5651 [patch] Use 'inherit' 'file' config setting when creating a new
Environment (not loading defaults)

+1

#6043 Trunk jQuery crashes safari 2.0 and older

I guess we check if there are any major changes in jQuery 1.1.4, do
some testing, and plonk it in.

#5954 Can't use prototype in plugins as $ conflicts with jquery

No opinion, +0.

#6278 remove unnecessary span tag

No opinion, +0.

#6211 IPermissionPolicy unable to grant WIKI_VIEW access

I've updated the ticket with comments, but the
summary is that I think we should do the opposite of what the
requestor suggests :)

Alec Thomas

unread,
Nov 18, 2007, 12:32:07 AM11/18/07
to trac...@googlegroups.com
As an aside, the following Wiki text renders counter-intuitively:

- Some first paragraph in a point.

The second paragraph in a point.

Indentation is consistent, so I would expect the second paragraph
still to be in the <li>.

Christian Boos

unread,
Nov 19, 2007, 6:44:16 AM11/19/07
to trac...@googlegroups.com
Alec Thomas wrote:
> On 11/17/07, Christian Boos <cb...@neuf.fr> wrote:
>
>> Extended time for review, as I won't be able to do anything more till
>> Monday.
>>
>> ... at which point, if there's no big concerns raised, I'm going to
>> commit like crazy and call that beta one ;-)
>>
>
> #153 Email address obfuscation/truncating
>
> +1
>
> My only question is why you accumulate into email_cells rather than just
> formatting the cell in the main loop?
>

We need to know the resource for the formatting
(format_emails(context(resource), cell['value'])), in order to do a
fine-grained permission check for EMAIL_VIEW, and the row['id'] used for
getting the resource is only known after the iteration.

> #1440 Remove reached milestones from edit ticket list
>
> No real opinion, +0
>
> #2048 Wiki macros for generating `<div>`s and `<span>`s with classes
>
> I like this style much better than the original proposed "}}}.class"
> one. Only real question is do we need the ";" separators? It would
> seem more in-keeping with normal HTML to simply have:
>
> {{{
> #!div class="foo" style="foo bar"
>
> ...
> }}}
>

Well, given that #! can be followed by a mime-type, the more general
idea here was to pass arguments to wiki-processors using a syntax
similar to that of a Content-Type header. The use case for <div> came later.
Anyway, looking at the current regexp, it seems that it doesn't matter,
as either would work...

> #2259 No notification email when adding an attachment to a ticket
>
> +1
>
> #2914 would be nice to have optional automatic line breaks in ticket
> descriptions and comments
>
> +1, LGTM.
>
> #5651 [patch] Use 'inherit' 'file' config setting when creating a new
> Environment (not loading defaults)
>
> +1
>
> #6043 Trunk jQuery crashes safari 2.0 and older
>
> I guess we check if there are any major changes in jQuery 1.1.4, do
> some testing, and plonk it in.
>

Plus 1.1.4 is supposedly much faster. Ideally we should go with 1.2.1
though.

> #5954 Can't use prototype in plugins as $ conflicts with jquery
>
> No opinion, +0.
>
> #6278 remove unnecessary span tag
>
> No opinion, +0.
>
> #6211 IPermissionPolicy unable to grant WIKI_VIEW access
>
> I've updated the ticket with comments, but the
> summary is that I think we should do the opposite of what the
> requestor suggests :)
>
>

I didn't see your comment but I'm definitely interested in your opinion
on the matter.

-- Christian

Alec Thomas

unread,
Nov 19, 2007, 8:11:35 AM11/19/07
to trac...@googlegroups.com, trac...@googlegroups.com

Ugh. No idea what happened to it :(

But effectively what you said, plus a mention of how 'WIKI_VIEW' in
req.perm('wiki') is used by the nav code to check whether the wiki nav
item should show up at all.

This also had the implication that plugins doing old-style checks may
not work correctly with policy plugins such as the one he mentioned,
and that we should make a note of that somewhere.

>
>
> -- Christian
>
>
> >

Reply all
Reply to author
Forward
0 new messages