- ubuntu12.04环境下使用kvm ioctl接口实现最简单的虚拟机
- Ubuntu 通过无线网络安装Ubuntu Server启动系统后连接无线网络的方法
- 在Ubuntu上搭建网桥的方法
- ubuntu 虚拟机上网方式及相关配置详解
CFSDN坚持开源创造价值,我们致力于搭建一个资源共享平台,让每一个IT人在这里找到属于你的精彩世界.
这篇CFSDN的博客文章Python装饰器用法实例总结(新)由作者收集整理,如果你对这篇文章有兴趣,记得点赞哟.
本文实例讲述了Python装饰器用法。分享给大家供大家参考,具体如下:
写装饰器 。
装饰器只不过是一种函数,接收被装饰的可调用对象作为它的唯一参数,然后返回一个可调用对象(就像前面的简单例子) 注意重要的一点,当装饰器被应用到被装饰函数上时,装饰器代码本身就会运行,而不是当被装饰函数被调用时.理解这个很关键,接下来的几个例子的讲解过程也会变得很清楚 。
第一个例子: 函数注册 。
看下面简单的函数注册:
1
2
3
4
|
registry
=
[]
def
register(decorated):
registry.append(decorated)
return
decorated
|
注册器方法是一个简单的装饰器。它追加位置参数,也就是被装饰函数到registry变量中,然后不做改变地返回被装饰方法。任何接受register装饰器的方法会把它自己追加到registry变量上.
1
2
3
4
5
6
|
@register
def
foo():
return
3
@register
def
bar():
return
5
|
如果你访问了registry,可以很容易地在上面迭代并执行里面的函数.
1
2
3
|
answers
=
[]
for
func
in
registry:
answers.append(func())
|
answers 列表现在回包含 [3, 5]. 这是因为函数已按次序执行,并且它们的返回值被追加到 answers中. 。
对于现有的函数注册,有几类简单的应用,例如添加“钩子(hooks)”到代码中,这样的话自定义的功能在条件事件之前或之后运行。 下面的Registry类能够处理这种情况:
1
2
3
4
5
6
7
8
9
10
11
|
class
Registry(
object
):
def
__init__(
self
):
self
._functions
=
[]
def
register(
self
, decorated):
self
._functions.append(decorated)
return
decorated
def
run_all(
self
,
*
args,
*
*
kwargs):
return_values
=
[]
for
func
in
self
._functions:
return_values.append(func(
*
args,
*
*
kwargs))
return
return_values
|
这个类里的register方法让然像之前一样按同样方法工作。用一个绑定(bound)的方法作为装饰器完全没问题。它接收self作为第一参数(像任何绑定方法一样),并且需要一个额外的位置参数,那就是被装饰函数,通过创建几个不同的 registry实例,你可以拥有一些完全分开的注册器。使用相同函数并且,用超过一个注册器注册它也是可行的,像下面展示的一样
1
2
3
4
5
6
7
8
9
10
11
12
|
a
=
Registry()
b
=
Registry()
@a
.register
def
foo(x
=
3
):
return
x
@b
.register
def
bar(x
=
5
):
return
x
@a
.register
@b
.register
def
baz(x
=
7
):
return
x
|
运行两个注册器的run_alll方法,得到如下结果:
1
2
|
a.run_all()
# [3, 7]
b.run_all()
# [5, 7]
|
注意,run_all 方法能够使用参数,当它们运行时会把参数传给内部函数 。
1
|
a.run_all(x
=
4
)
# [4, 4]
|
运行时包装代码 。
以上这些装饰器都很简单,因为被装饰方法被传递后未经更改。然而,有些时候当被装饰方法执行时,你想要运行额外的功能。你通过返回一个添加了相关功能并且在它执行过程中调用被装饰方法的不同的可调用对象来实现.
简单的类型检查 。
这有一个简单的装饰器,确保函数接收到的每一个参数都是整数,否则进行报告:
1
2
3
4
5
6
7
8
9
10
11
12
13
|
def
requires_ints(decorated):
def
inner(
*
args,
*
*
kwargs):
#获取任何可能被发送的关键值参数
kwarg_values
=
[i
for
i
in
kwargs.values()]
#在发送给被装饰方法的每个值上面进行迭代,确保每一个都是整数;
#如果不是抛 TypeError
for
arg
in
list
(args)
+
kwarg_values:
if
not
isinstance
(arg,
int
):
raise
TypeError('
%
s only accepts integers as
arguments.'
%
decorated.__name__)
#运行被装饰方法,返回结果
return
decorated(
*
args,
*
*
kwargs)
return
inner
|
发生了什么?
装饰器是 requires_ints. 它接受一个参数,即被装饰的可调用对象。这个装饰器做的唯一事情是返回一个新的可调用对象,一个内部的本地函数。这个函数替代了被装饰的可调用对象。你可以看到它如何发挥作用,声明一个函数并且用requires_ints来装饰 。
1
2
3
4
|
@requires_ints
def
foo(x, y):
"""Return the sum of x and y."""
return
x
+
y
|
注意如果你运行 help(foo)获取的
1
2
3
|
Help
on function inner
in
module __main__:
inner(
*
args,
*
*
kwargs)
(END)
|
inner 函数已被指派了名字foo,而不是初始的,已定义了的函数。如果你运行 foo(3, 5), inner 函数会用这些参数来运行,inner函数进行类型检查,然后运行被装饰函数,因为inner函数调用它,使用decorated(*args, **kwargs),返回8.没有这个调用,被装饰方法会被忽略.
保留helpPreserving the help 。
一般不想让装饰器破坏你的函数的docstring或者操纵help输出.
因为装饰器是用来添加通用的和可重用功能的工具,他们有必要更泛化些.
并且,通常来说如果有人使用一个函数试图在上面运行help,他想要的是关于函数内脏(guts)的信息,而不是外壳(shell)的信息。解决这个问题的方法实际上应用到了 … 仍然是装饰器. Python 实现了一个叫做 @functools.wraps 的装饰器,它复制一个函数的内部元素到另一个函数。它把一个函数的重要的内省元素(introspection elements)复制给另一个函数.
这是同一个@requires_ints 装饰器, 但添加了@functools.wraps的使用:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
import
functools
def
requires_ints(decorated):
@functools
.wraps(decorated)
def
inner(
*
args,
*
*
kwargs):
#获取可能已作为键值参数发送的任何值
kwarg_values
=
[i
for
i
in
kwargs.values()]
#迭代发送给被装饰函数的每个值, 并
#确保每个参数都是整数,否则抛TypeError
for
arg
in
args
+
kwarg_values:
if
not
isinstance
(i,
int
):
raise
TypeError('
%
s only accepts integers as
arguments.'
%
decorated.__name__)
#运行被装饰函数然后返回结果
return
decorated(
*
args,
*
*
kwargs)
return
inner
|
装饰器本身几乎没有改变,除了第二行给inner函数使用了@functools.wraps装饰器。你现在必须导入functools(在标准库中)。你也会注意到些额外语法。这个装饰器实际上使用了一个参数(稍后会有更多).
现在你可以应用这个装饰器给相同的函数,像下面这样:
1
2
3
4
|
@requires_ints
def
foo(x, y):
"""Return the sum of x and y."""
return
x
+
y
|
现在当你运行help(foo)的结果:
1
2
3
4
|
Help
on function foo
in
module __main__:
foo(x, y)
Return the
sum
of x
and
y.
(END)
|
你看到了 foo的docstring ,同时还有它的方法签名,然而在盖头(hood)下面,@requires_ints装饰器仍然被应用,并且 inner函数仍然正常运行 。取决于你使用的python版本,运行结果可能稍有不同,尤其当忽略函数签名时。前面的输出源自Python 3.4。然而在python 2,提供的函数签名仍然有点隐秘(因此,是*args和**kwargs而不是x和y) 。
用户认证 。
这个模式(即在运行被装饰方法前进行过滤验证)的通常使用场景是用户认证。考虑一个需要user作为它的第一个参数的方法,user应该是User和AnonymousUser类的实例
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
class
User(
object
):
"""A representation of a user in our application."""
def
__init__(
self
, username, email):
self
.username
=
username
self
.email
=
email
class
AnonymousUser(User):
"""An anonymous user; a stand-in for an actual user that nonetheless
is not an actual user.
"""
def
__init__(
self
):
self
.username
=
None
self
.email
=
None
def
__nonzero__(
self
):
return
False
|
装饰器在此成为隔离用户验证的样板代码的有力工具。@requires_user装饰器可以很轻松地认证你获得了一个User对象并且不是匿名user 。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
import
functools
def
requires_user(func):
@functools
.wraps(func)
def
inner(user,
*
args,
*
*
kwargs):
"""Verify that the user is truthy; if so, run the
decorated method,
and if not, raise ValueError.
"""
# Ensure that user is truthy, and of the correct type.
# The "truthy"check will fail on anonymous users, since the
# AnonymousUser subclass has a ‘__nonzero__‘ method that
# returns False.
if
user
and
isinstance
(user, User):
return
func(user,
*
args,
*
*
kwargs)
else
:
raise
ValueError('A valid user
is
required to run
this.')
return
inner
|
这个装饰器应用了一个通用的,需要样板化的验证—-用户是否登录进系统的验证。当你把它作为装饰器导入,它可重用且易于管理,它应用至函数上也清晰明了。注意这个装饰器只会正确地包装一个函数或者静态方法,如果包装一个类的绑定方法就会失败,这是因为装饰器忽视了发送self作为第一个参数到绑定方法的需要.
格式化输出 。
除了过滤一个函数的输入,装饰器的另一个用处是过滤一个函数的输出。当你用Python工作时,只要可能就希望使用Python本地对象。然而通常想要一个序列化的输出格式(例如,JSON) 在每个相关函数的结尾手动转换成JSON会显得很笨(也不是个好主意)。 理想的你应该使用Python数据结构直到需要序列化,但在序列化前仍然可能有其他重复代码。 装饰器为这个问题提供了一个出色的,轻便的解决方案。考虑下面的装饰器,它采用python输出,并序列化结果为JSON 。
1
2
3
4
5
6
7
8
9
10
11
12
|
import
functools
import
json
def
json_output(decorated):
"""Run the decorated function, serialize the result of
that function
to JSON, and return the JSON string.
"""
@functools
.wraps(decorated)
def
inner(
*
args,
*
*
kwargs):
result
=
decorated(
*
args,
*
*
kwargs)
return
json.dumps(result)
return
inner
|
给一个 简单函数应用@json_output 装饰器
1
2
3
|
@json_output
def
do_nothing():
return
{
'status'
:
'done'
}
|
在Python shell中运行这个函数
1
2
|
>>> do_nothing()
'{"status": "done"}'
|
结果是一个包含JSON的字符串,而不是一个字典.
这个装饰器的优美在于它的简洁。把这个装饰器应用到一个函数,本来返回python字典,列表或者其它对象的函数现在会返回它的JSON序列化的版本。你可能会问这有什么价值?毕竟你加了一行装饰器,实质上只移除了一行调用json.dumps的代码.
然而,由于应用的需求会扩展,还是考虑一下拥有此装饰器的价值.
例如,某种异常需要被捕获,并以特定的格式化的json输出,而不是让异常上浮产生堆栈跟踪,该怎么做?因为有装饰器,这个功能很容易添加.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
|
import
functools
import
json
class
JSONOutputError(Exception):
def
__init__(
self
, message):
self
._message
=
message
def
__str__(
self
):
return
self
._message
def
json_output(decorated):
"""Run the decorated function, serialize the result of
that function
to JSON, and return the JSON string.
"""
@functools
.wraps(decorated)
def
inner(
*
args,
*
*
kwargs):
try
:
result
=
decorated(
*
args,
*
*
kwargs)
except
JSONOutputError as ex:
result
=
{
'status'
:
'error'
,
'message'
:
str
(ex),
}
return
json.dumps(result)
return
inner
|
通过使用错误处理增强@json_output装饰器,你已经把该功能添加给了应用了这个装饰器的任何函数.
这是让装饰器如此有价值的部分原因。对于代码轻便化,可重用化而言,它们是非常有用的工具.
现在,如果一个用@json_output装饰的函数抛出了JSONOutputError异常,就会有特别的错误处理:
1
2
3
|
@json_output
def
error():
raise
JSONOutputError(
'This function is erratic.'
)
|
运行error 函数:
1
2
|
>>> error()
'{"status": "error", "message": "This function is erratic."}'
|
注意,只有JSONOutputError异常类(或它的子类)会获得这种特别的错误处理。任何其它异常会正常通过,并产生堆栈跟踪.
实质上,装饰器是避免重复你自己的工具,并且它们的部分价值在于给未来的维护提供钩子(hooks)。这些不用装饰器也可以实现,考虑要求用户登录进系统的例子,写一个函数并把它放在需要这项功能的函数的入口处就行了。装饰器首先是一种语法糖(syntactic sugar)。然而是一种很有价值的语法糖。毕竟,相较于写,代码更多时候用来读,而且你可以一眼定位到装饰器的位置.
日志记录Logging 。
执行时包装代码的最后一个例子是一个通用的日志记录函数。 考虑下面引起函数调用的装饰器, 运行时间, 结果会被记录
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
|
import
functools
import
logging
import
time
def
logged(method):
"""Cause the decorated method to be run and its results
logged, along
with some other diagnostic information.
"""
@functools
.wraps(method)
def
inner(
*
args,
*
*
kwargs):
#Record our start time.
start
=
time.time()
#Run the decorated method.
return_value
=
method(
*
args,
*
*
kwargs)
#Record our completion time, and calculate the delta.
end
=
time.time()
delta
=
end
-
start
#Log the method call and the result.
logger
=
logging.getLogger(
'decorator.logged'
)
logger.warn('Called method
%
s at
%
.
02f
; execution time
%
.
02f
seconds; result
%
r.'
%
(method.__name__, start, delta, return_value))
#Return the methods original return value.
return
return_value
return
inner
|
当应用到一个函数上后,这个装饰器正常地运行那个函数,但函数调用结束后会使用Python logging模块记录信息.
1
2
3
4
5
6
7
8
9
|
>>>
import
time
>>> @logged…
def
sleep_and_return(return_value):
... time.sleep(
2
)
...
return
return_value…
>>>
>>> sleep_and_return(
42
)
Called method sleep_and_return at
1424462194.70
;
execution time
2.00
seconds; result
42.
42
|
不像先前的例子,这个装饰器不显式地更改函数调用. 不存在你应用这个装饰器后获得的结果与没有被装饰的函数的结果不一样的情况。这个装饰器做了些幕后工作,但并不改变实际结果。 值得注意的是, @json_output 和 @logged 装饰器都提供 inner 函数 ,这个函数简单地以最小的侦测采用和传递可变参数和关键字参数.
这是一种重要的模式。一种它尤其重要的方式是,许多装饰器可能被用来装饰纯粹的函数和类的方法。记住,在Python中,类中声明的方法会获得一个额外位置参数,即广为人知的self。当装饰器在使用时,它不会改变 (这就是为什么先前的requires_user装饰器在类的绑定方法上不起作用) 。
例如@json_result被用来装饰一个类的方法,inner函数被调用,它接收一个类的实例作为第一个参数。实际上这没有问题。在这种情况下,这个参数就是args[0],它被传送给被装饰方法.
装饰器参数 。
到目前为止列出的所有装饰器都没有任何参数。作为讨论过的内容,有一个暗含的参数–被装饰的方法。然而,有时让装饰器自身使用一些它需要的信息去装饰相关方法会有用处.
一个参数传给一个装饰器和一个参数传给一个正在调用的方法之间的不同是,当一个函数被声明并被装饰,传给装饰器的参数会被立刻处理。相反,传给函数的参数在函数调用时被处理。通过@functools.wraps的多次使用,你已经看到了一个参数传给装饰器的例子。它使用一个参数—-被包装的方法,方法的help和docstring等类似的东西应该被保留。然而,装饰器有内含的调用签名。他们使用一个位置参数–被装饰的方法。所以,这是怎么工作的?答案说来就复杂了.
回想运行时包装代码的基本装饰器 ,他们在局部范围声明了一个 inner 方法 然后返回它. 这就是由装饰器返回的可调用对象. 它被指派了被调用函数的名字. 使用参数的装饰器多添加一个包装层,这是因为,使用参数的装饰器不再是一个实际的装饰器。它是一个返回装饰器的函数,是一个使用一个参数(被装饰的方法)的函数。然后装饰函数并返回一个可调用对象。听起来混乱,考虑下面的例子,在这里,装饰器@json_output的功能被增强了,要求缩进和排序:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
|
import
json
class
JSONOutputError(Exception):
def
__init__(
self
, message):
self
._message
=
message
def
__str__(
self
):
return
self
._message
def
json_output(indent
=
None
, sort_keys
=
False
):
"""Run the decorated function, serialize the result of
that function
to JSON, and return the JSON string.
"""
def
actual_decorator(decorated):
@functools
.wraps(decorated)
def
inner(
*
args,
*
*
kwargs):
try
:
result
=
decorated(
*
args,
*
*
kwargs)
except
JSONOutputError as ex:
result
=
{
'status'
:
'error'
,
'message'
:
str
(ex),
}
return
json.dumps(result, indent
=
indent,
sort_keys
=
sort_keys)
return
inner
return
actual_decorator
|
那么,发生了什么,为什么这回起作用?这是一个函数,json_output,接收两个参数(indent 和 sort_keys). 它返回另一个函数, 叫 actual_decorator, 这是 (如同名字表名的) 要作为装饰器使用的. 这是一个典型的装饰器—一个接收可调用对象(被装饰的)做参数的可调用对象,并且返回一个可调用对象(inner). 。
注意函数已经有所改变来容纳indent和sort_keys参数.
inner 函数是最终使用 indent 和 sort_keys 参数的. 这没有问题,因为Python的块作用域规则允许这样。使用不同的indent和sort_keys来调用也不成问题,因为inner是本地函数(每次装饰器被使用都会返回一个不同的副本)应用 json_output 函数
1
2
3
|
@json_output
(indent
=
4
)
def
do_nothing():
return
{
'status'
:
'done'
}
|
现在运行do_nothing , 会产生一个带缩进的JSON
1
2
|
>>> do_nothing()
'{\n "status": "done"\n}'
|
这是怎么起作用的?
但是,等一等. 如果json_output 不是一个装饰器, 而是一个返回装饰器的函数,为什么它使用起来看着像是一个装饰器?在这里,Python解释器做了什么来让它工作的?更多的解释已经就绪。在这的关键是操作顺序.
特别地,函数调用(json_output(indent=4)) 先于装饰器应用语法(@)被处理 。因此,函数调用的结果会应用给装饰器.
发生的第一件事情是解释器寻找 json_output 函数调用,然后解析这个调用:
1
2
3
|
@json_output
(indent
=
4
)
def
do_nothing():
return
{
'status'
:
'done'
}
|
json_output 函数所要做的一切就是定义另一个函数, actual_decorator, 然后返回它. 这个函数的结果会提供给@,像下面这样
1
2
3
|
@actual_decorator
def
do_nothing():
return
{
'status'
:
'done'
}
|
现在, actual_decorator 在运行. 它声明另一个本地函数, inner, 并返回它. 像先前讨论过的,这个函数会被指派名字 do_nothing, 被装饰方法的名字. 当do_nothing被调用, inner 函数就会被调用, 运行被装饰方法, JSON使用合适缩进 调用dumps 处理结果 。
调用签名很重要 。
当你引进了你的新的,更改过后的json_output函数,你实际引进了一个反向不兼容(backward-incompatible )的改变,意识到这点很重要.
为什么?因为现在期待一个额外的函数调用。如果你想要旧的json_output的行为,不需要任何可用的参数的值,你仍然必须调用这个方法 换句话说,你必须像下面这样做:
1
2
3
|
@json_output
()
def
do_nothing():
return
{
'status'
:
'done'
}
|
注意圆括号. 它们有影响,因为它们指出了函数正在被调用(即便没有参数),然后结果应用给@. 前面的代码不等价于下面:
1
2
3
|
@json_output
def
do_nothing():
return
{
'status'
:
'done'
}
|
这呈现出两个问题。有点让人迷惑,如果你习惯于看到不带签名的装饰器的应用,提供一个空签名的需要就违背直觉.
第二,如果旧的装饰器在你的应用中已经存在,你必须返回并编辑所有它们的现有的调用。如果可能的话,你应该避免反向不减容(backward-incompatible)改变。 完美的情况下,下面三种不同的使用方式,装饰器都会工作 。
1
2
3
|
@json_output
@json_output
()
@json_output
(indent
=
4
)
|
让装饰器基于接收到的参数来改变它的行为是可能的。记住,装饰器只是一个函数,拥有任何其它函数所拥有的所有灵活性,包括对它获取到的输入做出需要做出的响应.
考虑这个对 json_output的更加灵活的迭代
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
|
import
functools
import
json
class
JSONOutputError(Exception):
def
__init__(
self
, message):
self
._message
=
message
def
__str__(
self
):
return
self
._message
def
json_output(decorated_
=
None
, indent
=
None
, sort_keys
=
False
):
"""Run the decorated function, serialize the result of that function
to JSON, and return the JSON string.
"""
# Did we get both a decorated method and keyword arguments?
# That should not happen.
if
decorated_
and
(indent
or
sort_keys):
raise
RuntimeError(
'Unexpected arguments.'
)
# Define the actual decorator function.
def
actual_decorator(func):
@functools
.wraps(func)
def
inner(
*
args,
*
*
kwargs):
try
:
result
=
func(
*
args,
*
*
kwargs)
except
JSONOutputError as ex:
result
=
{
'status'
:
'error'
,
'message'
:
str
(ex),
}
return
json.dumps(result, indent
=
indent,
sort_keys
=
sort_keys)
return
inner
#Return either the actual decorator, or the result of applying
#the actual decorator, depending on what arguments we got.
if
decorated_:
return
actual_decorator(decorated_)
else
:
return
actual_decorator
|
在目前是不是正作为装饰器使用这一方面,这个函数正努力变得智能.
首先,它确保它不会以出乎意料的方式被调用 。
你永远不要期待接收被装饰方法同时关键值参数,因为装饰器被调用时总是以被装饰方法作为唯一参数.
第二,它定义了actual_decorator函数,这是要被返回和应用的实际装饰器。它定义了inner 函数,它时从装饰器中返回的最终函数.
最终, 它返回合适结果,这基于它被如何调用:
如果 设置了decorated_ , 它会被作为纯粹的装饰器调用, 没有方法签名,然后它的响应应用给最终装饰器并返回inner函数 . 再次注意使用参数的装饰器如何实际地运作。首先, actual_decorator(decorated_)被调用,解析。然后它的结果(必须是一个可调用对象,因为这是一个装饰器)被调用,inner被提供作为唯一的参数.
如果decorated_没被设置,就会使用关键字参数调用,这个函数必须返回一个实际的装饰器,它接收被装饰方法,并返回inner。因此,这个函数返回actual_decorator 然后这会被python解释器作为实际装饰器(最终返回inner) 。
为何这个技术有价值?它让你能够先先前使用过的一样管理你的装饰器的功能。意味着你不用去更新已经应用了装饰器的每个地方,但仍然获得了在你需要时添加参数的灵活性.
希望本文所述对大家Python程序设计有所帮助.
原文链接:https://blog.csdn.net/zhangfh1990/article/details/73442447 。
最后此篇关于Python装饰器用法实例总结(新)的文章就讲到这里了,如果你想了解更多关于Python装饰器用法实例总结(新)的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。
我有这些 ViewModel:RecordViewModel、ComponentViewModel,其中 RecordViewModel 本质上是几个 ComponentViewModel 的容器。
我正在尝试为我的 Controller 设置一个装饰器。我的目的是在我的应用程序中的所有 Controller 中引入一些常见的行为。 我已将其配置为在 Angular 1.2.x 中工作,但从 1.
我想用角上的时间戳装饰我生成的所有 JFreeCharts。 JFreeChart 框架中是否有一种方法可以在生成图表后在图像上绘制? 编辑:请注意,这些图表是在后台线程中生成并通过 servlet
在grails应用程序中,我想用自定义数据装饰每个日志。当前的需要只是在日志消息前添加当前用户名 我对如何解决此问题有一些想法: -Adding custom field to log4j patte
我有一个form-el,它只是一个容器,必须将所有子元素包装在具有特定类的div 中。我希望允许 from-el 来包装它们,而不是在每个表单元素中重复这个 div 。我可以循环所有元素并将它们包装在
我遵循以下约定来装饰 Python 类中的某些方法。我想知道是否有一些更好的方法可以做到同样的事情。我的方法看起来当然不太好;对原始成员函数的调用看起来一点也不直观。 from threading i
我的 DTO 看起来像这样 public class SomeDTO { public string last_name{ get; set; } public string ac
这可能是一个远景,但 .NET 的灵 active 一直让我惊叹不已,所以开始吧。 我正在开发一个 MVC 应用程序,它需要在一组程序集中搜索派生自公共(public)基类的类类型。 即我有几个程序集
在我正在进行的项目中,我正在按照项目负责人的要求实现开发人员通知系统。它的工作方式是,如果发生前端错误,开发团队会收到一封错误电子邮件。 但是,在我当前的实现中,我似乎有以下循环依赖: $rootSc
我需要一些关于如何取消装饰和装饰 JInternalFrame 的帮助。我的框架类是这样的: package com; import java.awt.BorderLayout; import jav
假设我们有可能需要长时间运行的任务: public class LongRunningTask { public ReturnType doSomething() { ...
我正在尝试创建一个装饰器方法,它将一些默认的生命周期方法添加到 react 组件中。我的目标是向组件中添加一些默认功能,例如,所有组件都应该能够在 componentWillMount 上执行特定操作
我正在尝试将 DBUS 的异步方法调用与 Twisted 的 Deferred 相结合,但我在调整常用的 DBUS 服务方法装饰器来执行此操作时遇到了麻烦。 要使用 DBUS 异步回调方法,您需要:
是否可以设置表格中一行的背景颜色?当条件适用时,我需要突出显示一行。效果为 ...我可以在其中指定“字体”属性。 (我需要突出显示整行)。 最佳答案 您必须子类化 qooxdoo 默认行渲染器才能做到
我正在开发一个具有不同视角的基于 Java Swing 的应用程序。对于“主菜单”视角,我不希望装饰窗口 (JFrame),而在其他视角中,我确实希望装饰窗口。换句话说,我需要动态更 retrofit
我想做一些类似下面代码所示的事情: class foo { private: std::fstream* m_stream; public: foo(std::fstream* str
我的数据源提供了一个 ObservableList ,但是对于我的 ListView,我需要一个 ObservableList . A Warning基本上只是字符串的装饰器,添加一个 boolean
我一直在纠结于装饰+接口(interface)。假设我有以下“行为”接口(interface): interface IFlyable { void Fly();} interface ISwimma
有没有人为 iOS 6 UICollectionView 实现过装饰 View ?不可能 查找有关在网络上实现装饰 View 的任何教程。基本上在我的应用程序中,我有多个部分,我只想在每个部分后面显示
我有一个简单的 Controller ,例如: function MyController($scope, $http) { ... $http.post(url).success(f
我是一名优秀的程序员,十分优秀!