Mailing List Archive: Trac: Tickets

[The Trac Project] #3655: 天津LE D显示屏☎13911588988| 天津LED电子显示屏☎13911588988销售部王经理| 北京海潮天津 LED显示屏公司是一家全国最具规模的LED制造商,本公司的LED系列产品: 全彩天津LED显 �

Index | Next | Previous | View Threaded

noreply at edgewall

Aug 31, 2006, 10:59 PM

Post #1 of 18 (4536 views)
Permalink

[The Trac Project] #3655: 天津LE D显示屏☎13911588988\| 天津LED电子显示屏☎13911588988销售部王经理\| 北京海潮天津 LED显示屏公司是一家全国最具规模的LED制造商,本公司的LED系列产品: 全彩天津LED显 �

#3655: 天津LED显示屏☎13911588988|天津LED电子显示屏☎13911588988销售部王经理|北京海潮天津LED显示屏公司是一家全国最具规模的LED制造商,本公司的LED系列产品:全彩天津LED显示屏,双基色天津LED显示屏,室外天津LED显示屏,室内天津LED显示屏,银行利率屏,银行汇率屏,利率汇率显示屏,舞台字幕屏(条型屏),电子看板(生产看板),数码管显示屏,电子时钟,倒计时系统,温度显示屏,湿度显示屏,温湿度显示屏,倒计时天津LED显示屏,篮球比赛天津LED显示屏,银行排队LED显示系统,世界时显示屏,酒店天津LED显示屏,宾馆天津LED显示屏
天津LED显示屏,天津LED电子显示屏,☎13911588988,☎13911588988销售部王经理,LED电子显示屏,LED电子显示屏,☎13911588988,☎13911588988销售部王经理,LED电子显示屏,深圳LED显示屏,LED显示屏价格,南京LED显示屏,苏州LED显示屏,
上海LED显示屏,北京LED显示屏,LED显示屏报价,杭州LED显示屏,广州LED显示屏,LED显示屏生产厂家,西安LED显示屏,东莞LED显示屏,LED显示屏租赁,LED电子显示屏报价,广东LED显示屏,LED点阵显示屏,LED显示屏招标,南京LED电子显示屏,苏州LED电子显示屏,LED显示屏控制系统,天津LED显示屏,上海LED电子显示屏,济南LED显示屏,LED显示屏论坛,LED显示屏设计,LED显示屏厂家,广州LED电子显示屏,广东LED电子显示屏,LED显示屏模组,LED电子显示屏方案,沈阳LED显示屏,东莞LED电子显示屏,求购LED显示屏,陕西LED电子显示屏,LED显示屏控制卡,LED显示屏通用规范,LED显示屏方案,LED全彩显示屏,深圳LED电子显示屏,LED显示屏故障,LED显示屏技术参数,无锡LED电子显示屏,长沙LED电子显示屏,湖南LED电子显示屏,LED显示屏技术,LED显示屏销售,无线LED显示屏,LED显示屏维修,LED电子显示屏公司,天津LED显示屏,LED显示屏动态显示,LED电子显示屏技术,LED显示屏招聘,河南LED显示屏,LED液晶显示屏,无锡LED显示屏,郑州LED显示屏,LED电子显示屏维修,福建LED显示屏,安徽LED显示屏,中山LED显示屏,泉州LED显示屏,LED广告显示屏,南昌LED显示屏,镇江LED显示屏,昆明LED电子显示屏,深圳四通LED显示屏,镇江LED电子显示屏,淮安LED显示屏,LED点阵汉字显示屏,淮安LED电子显示屏,中国LED显示屏网,什么是LED显示屏,LED显示屏网站,LED显示屏公司,中国LED显示屏,LED显示屏图片,LED显示屏规格,LED显示屏控制软件,LED显示屏安装,LED显示屏参数,LED显示屏的特点,LED显示屏结构,武汉LED显示屏,成都LED显示屏,LED户外显示屏,LED显示屏最新材料,青岛LED显示屏,四川LED显示屏,山东LED显示屏,北京LED电子显示屏,LED室外显示屏,LED显示屏的作用,LED电子显示屏☎13911588988,☎13911588988销售部王经理
-----------------------+----------------------------------------------------
Reporter: anonymous | Owner: jonas
Type: defect | Status: new
Priority: normal | Milestone:
Component: general | Version: 0.9.6
Severity: normal | Keywords:
-----------------------+----------------------------------------------------

--
Ticket URL: <http://trac.edgewall.org/ticket/3655>
The Trac Project <http://trac.edgewall.org/>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Tickets" group.
To post to this group, send email to trac-tickets[at]googlegroups.com
To unsubscribe from this group, send email to trac-tickets-unsubscribe[at]googlegroups.com
For more options, visit this group at http://groups.google.se/group/trac-tickets
-~----------~----~----~----~------~----~------~--~---

noreply at edgewall

Sep 5, 2006, 4:51 AM

Post #2 of 18 (4392 views)
Permalink

Re: [The Trac Project] #3655: IRequestFilter pre-processor - either implementation or documentation is wrong [In reply to]

#3655: IRequestFilter pre-processor - either implementation or documentation is
wrong
-------------------------------------+--------------------------------------
Reporter: simon-code[at]bvnetwork.no | Owner: jonas
Type: defect | Status: new
Priority: normal | Milestone:
Component: general | Version: devel
Severity: normal | Resolution:
Keywords: |
-------------------------------------+--------------------------------------
Comment (by simon-code[at]bvnetwork.no):

The attached patch solves the issue by adding another method to the
IRequestFilter interface.

I tried numerous variations on getting something useful to work, and
finding a balance in the code on when to call the filter and what status
the request should have then. Conclusion: There is no practical way of
combining handler choice with request HDF modifications, and 2 methods are
required.

The attached patch keeps the current logic (and naming) as-is, and should
not break any Trac code or plugins - but plugins that implement the
interface (if they exist yet) need to add the method and just return the
{{{req}}} object. A simple solution to this would be to make the API
include the default return statement(s) - not done in the attached patch
for 3689.

Including default return statements in the API definition also makes it
easier to add to the API (interfaces) without breaking any existing code -
at least when there is such an obvious default return for the method. I
highly recommended it, but I'll leave it to core developers to decide on
that.

Any chance of including the patch for 0.10? Please?

--
Ticket URL: <http://trac.edgewall.org/ticket/3655#comment:1>
The Trac Project <http://trac.edgewall.org/>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Tickets" group.
To post to this group, send email to trac-tickets[at]googlegroups.com
To unsubscribe from this group, send email to trac-tickets-unsubscribe[at]googlegroups.com
For more options, visit this group at http://groups.google.se/group/trac-tickets
-~----------~----~----~----~------~----~------~--~---

noreply at edgewall

Sep 5, 2006, 5:11 AM

Post #3 of 18 (4392 views)
Permalink

Re: [The Trac Project] #3655: IRequestFilter pre-processor - either implementation or documentation is wrong [In reply to]

noreply at edgewall

Sep 5, 2006, 5:34 AM

Post #4 of 18 (4390 views)
Permalink

Re: [The Trac Project] #3655: IRequestFilter pre-processor - either implementation or documentation is wrong [In reply to]

noreply at edgewall

Sep 5, 2006, 6:09 AM

Post #5 of 18 (4389 views)
Permalink

Re: [The Trac Project] #3655: IRequestFilter pre-processor - either implementation or documentation is wrong [In reply to]

noreply at edgewall

Sep 5, 2006, 6:29 AM

Post #6 of 18 (4389 views)
Permalink

Re: [The Trac Project] #3655: IRequestFilter pre-processor - either implementation or documentation is wrong [In reply to]

#3655: IRequestFilter pre-processor - either implementation or documentation is
wrong
-------------------------------------+--------------------------------------
Reporter: simon-code[at]bvnetwork.no | Owner: cboos
Type: defect | Status: new
Priority: normal | Milestone:
Component: general | Version: devel
Severity: normal | Resolution:
Keywords: |
-------------------------------------+--------------------------------------
Comment (by cboos):

Replying to [comment:3 simon-code[at]bvnetwork.no]:
> About 'default return statements', I mean simply add to the interface
definition - so that every method does not need to be implemented in a
plugin.

Ah right, I should have understood, as I often wanted that myself.
I experimented a bit, coming up with this:
{{{
Index: trac/core.py
===================================================================
--- trac/core.py (revision 3686)
+++ trac/core.py (working copy)
@@ -127,6 +127,10 @@
'implements() can only be used once in a class definition'

locals['_implements'] = interfaces
+ for intf in interfaces:
+ for meth in dir(intf):
+ if not meth.startswith('_'):
+ locals[meth] = lambda self,*args: getattr(intf(),
meth)(*args)

class Component(object):
}}}

With the above patch, the Interface methods would need to be proper
methods, i.e. have a `self` argument.

That works fine for simple test cases on the command line, though Trac
won't behave properly with the above patch, probably because some
Interface methods previously undefined are now being called and they don't
have the `self` argument.

... back to the topic: ok, for the use case you described, version 1 of
the patch is better.
Now the question remains as whether to schedule the patch for 0.10 or not.
Opinion of other developers welcomed!

--
Ticket URL: <http://trac.edgewall.org/ticket/3655#comment:5>
The Trac Project <http://trac.edgewall.org/>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Tickets" group.
To post to this group, send email to trac-tickets[at]googlegroups.com
To unsubscribe from this group, send email to trac-tickets-unsubscribe[at]googlegroups.com
For more options, visit this group at http://groups.google.se/group/trac-tickets
-~----------~----~----~----~------~----~------~--~---

noreply at edgewall

Sep 5, 2006, 7:53 AM

Post #7 of 18 (4394 views)
Permalink

Re: [The Trac Project] #3655: IRequestFilter pre-processor - either implementation or documentation is wrong [In reply to]

#3655: IRequestFilter pre-processor - either implementation or documentation is
wrong
-------------------------------------+--------------------------------------
Reporter: simon-code[at]bvnetwork.no | Owner: cboos
Type: defect | Status: new
Priority: normal | Milestone:
Component: general | Version: devel
Severity: normal | Resolution:
Keywords: |
-------------------------------------+--------------------------------------
Comment (by simon-code[at]bvnetwork.no):

Tried your interface patch, but that does not work as I figured. If I
remove a method from an interface implementation (only implement 2 of the
3 IRequestFilter methods), a traceback is gently produced...

{{{
...
locals[meth] = lambda self,*args: getattr(intf(), meth)(*args)
TypeError: prepare_request() takes exactly 2 arguments (3 given)
}}}

Strange thing is that it is {{{pre_process_request()}}} that I removed...
Adding it backs means all works fine.

Looking at you code (glancing actually, as any lambda means my
understanding approaches zero), I wonder if the logic would be to add the
method from the base Interface class to the instance if it doesn't exit in
the instance? For all I know that is what your code tries to do... :-)

However, I was merely thinking 'inheritance' when I mentioned it - and
forgot to consider how the component archtecture is actually
implemented... I suppose such a discussion is above and beyond this
ticket.

About where to call prepare_request(): As an error page effectively is
handling a request, then hopefully you will use my location (last chance
before any processing and template rendering is about to start).

A case for 0.10 inclusion: The IRequestHandler was added in trunk, and has
never been part of a release. And, if anyone had tried using
pre_process_request() for the purposes it states, there likely would have
been a ticket sooner. The change is low (no) impact, and makes the
interface usable as it was intended. Please include :-)

--
Ticket URL: <http://trac.edgewall.org/ticket/3655#comment:6>
The Trac Project <http://trac.edgewall.org/>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Tickets" group.
To post to this group, send email to trac-tickets[at]googlegroups.com
To unsubscribe from this group, send email to trac-tickets-unsubscribe[at]googlegroups.com
For more options, visit this group at http://groups.google.se/group/trac-tickets
-~----------~----~----~----~------~----~------~--~---

noreply at edgewall

Sep 5, 2006, 10:43 AM

Post #8 of 18 (4391 views)
Permalink

Re: [The Trac Project] #3655: IRequestFilter pre-processor - either implementation or documentation is wrong [In reply to]

noreply at edgewall

Sep 5, 2006, 10:46 AM

Post #9 of 18 (4393 views)
Permalink

Re: [The Trac Project] #3655: IRequestFilter pre-processor - either implementation or documentation is wrong [In reply to]

noreply at edgewall

Sep 5, 2006, 1:52 PM

Post #10 of 18 (4397 views)
Permalink

Re: [The Trac Project] #3655: IRequestFilter pre-processor - either implementation or documentation is wrong [In reply to]

#3655: IRequestFilter pre-processor - either implementation or documentation is
wrong
-------------------------------------+--------------------------------------
Reporter: simon-code[at]bvnetwork.no | Owner: cboos
Type: defect | Status: new
Priority: normal | Milestone:
Component: general | Version: devel
Severity: normal | Resolution:
Keywords: |
-------------------------------------+--------------------------------------
Comment (by simon-code[at]bvnetwork.no):

Replying to [comment:7 cmlenz]:
> I think that for 0.10 we should just fix the docstring. We'll be
migrating from ClearSilver to [http://markup.edgewall.org/ Markup] after
0.10 anyway, and will provide an extension point that is explicitly
designed for adding data to the template context (not implemented on the
[source:/sandbox/markup/ branch] yet). `IRequestFilter` should IMHO retain
its current ''purity'' of having symmetrical pre-/post-processing hooks.

Oki... Seems like I have to revert to using
{{{INavigationProvider.get_navigation_items()}}} without yielding items as
my opportunity to modify {{{req.hdf}}} and add my styles and
javascripts... It works just like suggested {{{prepare_request}}}, but
feels like a hack :-)

Clearly I am in no position to evaluate long-term plans or purity of
interface implementations. I just feel that the interface that will be
introduced with 0.10 is incomplete. My 3 step filter is better, but maybe
not ideal either for the common needs of adding stuff to {{{hdf}}}, and
adding styles and scripts that are to be available for all 'visuals'
regardless of handler.

For a styles (themes) plugin especially, it is kind of a catch-22:

1. I tried using the post-processor, but as the error handler does not
pipe through the post-processor on its way to rendering, I had to move
forward in the call chain.
1. Moving to a pre-processor (like {{{prepare_request()}}}) means that my
stylesheet is added first, and instead of me overriding styles in
handlers, the handlers would revert (part of) my themes. I find that I
need to add styles twice (pre AND post) to make sure they also override
anything introduced in handlers. As there is no method to remove items
from a HDF dataset..

Maybe a more sensible approach is to make sure the error handling call the
post-processor as well? For anything visual, the post-processor is the
most correct place - if we can guarantee that all template-based
information actually call it, including 'normal' error messages.

--
Ticket URL: <http://trac.edgewall.org/ticket/3655#comment:9>
The Trac Project <http://trac.edgewall.org/>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Tickets" group.
To post to this group, send email to trac-tickets[at]googlegroups.com
To unsubscribe from this group, send email to trac-tickets-unsubscribe[at]googlegroups.com
For more options, visit this group at http://groups.google.se/group/trac-tickets
-~----------~----~----~----~------~----~------~--~---

noreply at edgewall

Sep 6, 2006, 1:58 AM

Post #11 of 18 (4382 views)
Permalink

Re: [The Trac Project] #3655: IRequestFilter pre-processor - either implementation or documentation is wrong [In reply to]

noreply at edgewall

Sep 6, 2006, 3:29 AM

Post #12 of 18 (4369 views)
Permalink

Re: [The Trac Project] #3655: IRequestFilter pre-processor - either implementation or documentation is wrong [In reply to]

noreply at edgewall

Sep 7, 2006, 3:49 PM

Post #13 of 18 (4373 views)
Permalink

Re: [The Trac Project] #3655: IRequestFilter pre-processor - either implementation or documentation is wrong [In reply to]

noreply at edgewall

Sep 11, 2006, 1:26 AM

Post #14 of 18 (4337 views)
Permalink

Re: [The Trac Project] #3655: IRequestFilter pre-processor - either implementation or documentation is wrong [In reply to]

noreply at edgewall

Sep 11, 2006, 3:27 AM

Post #15 of 18 (4354 views)
Permalink

Re: [The Trac Project] #3655: IRequestFilter pre-processor - either implementation or documentation is wrong [In reply to]

noreply at edgewall

Sep 12, 2006, 11:36 AM

Post #16 of 18 (4318 views)
Permalink

Re: [The Trac Project] #3655: IRequestFilter pre-processor - either implementation or documentation is wrong [In reply to]

noreply at edgewall

Sep 19, 2006, 12:42 AM

Post #17 of 18 (4277 views)
Permalink

Re: [The Trac Project] #3655: IRequestFilter pre-processor - either implementation or documentation is wrong [In reply to]

noreply at edgewall

Sep 20, 2006, 1:35 PM

Post #18 of 18 (4256 views)
Permalink

Re: [The Trac Project] #3655: IRequestFilter pre-processor - either implementation or documentation is wrong [In reply to]

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com

[The Trac Project] #3655: 天津LE D显示屏☎13911588988| 天津LED电子显 示屏☎13911588988销 售部王经理| 北京海潮天津 LED显示屏公司 是一家全国最 具规模的LED制 造商,本公司 的LED系列产品: 全彩天津LED显 �

[The Trac Project] #3655: 天津LE D显示屏☎13911588988| 天津LED电子显示屏☎13911588988销售部王经理| 北京海潮天津 LED显示屏公司是一家全国最具规模的LED制造商,本公司的LED系列产品: 全彩天津LED显 �