[RFC] timeline-refactoring branch created
Christian Boos
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
> 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
> 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
>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
> -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
> 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
> 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
- 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
> 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
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
>
>
> >