上下文

源码粗略分析 ''' globals: _request_ctx_stack = LocalStack() _app_ctx_stack = LocalStack() current_app = LocalProxy(_find_app) request = LocalProxy(partial(_lookup_req_object, "request")) session = LocalProxy(partial(_lookup_req_object, "session")) g = LocalProxy(partial(_lookup_app_object, "g")) 1 run_simple(host, port, self, **options),self是app,执行self()，Flask里面的__call__ 2 在__call__里面执行的return self.wsgi_app(environ, start_response)，把执行结果返回， environ请求相关的, start_response响应相关的 3 self.wsgi_app(environ, start_response)的源码： def wsgi_app(self, environ, start_response): #得到一个RequestContext的对象

以下内容，翻译自官方文档，并结合了学习过程的demo。 Spring Boot提供了许多实用程序和注解，帮助测试应用程序。测试支持由两个模块提供： spring-boot-test 包含核心项， spring-boot-test-autoconfigure 支持测试的自动配置。 大多数开发人员使用 spring-boot-starter-test ，它同时导入 SpringBoot 测试模块以及JUnit Jupiter、AssertJ、Hamcrest和许多其他有用的库。 此文使用当前最新稳定版本： SpringBoot 2.2.2.RELEASE 此 starter 还带来了 vintage 引擎，因此可以同时运行JUnit 4和JUnit 5测试。如果已经将测试迁移到JUnit5，那么应该排除JUnit4支持，如下例所示： <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <exclusions> <exclusion> <!-- 此模块兼容junit4 和 junit 5，此示例直接使用 junit5 --> <groupId>org.junit.vintage</groupId> <artifactId

1.错误描述： 　　点击运行时,InitializeComponent();报错. 　　随后此错误又消失.消失后运行仍然失败,并且不再显示错误. 　　尝试清理解决方案+重新生成解决方案,点击运行仍然重复上述内容. 　　尝试方法一 >工具>导入导出设置>重置所有设置>否>选择对应语言后 出现38个bug 提示 无法识别或访问成员 xxx. 　　排查并未发现该提示处的问题所在. 2.问题原因： 　　原因在于某xaml文件是从本项目的其它文件夹中复制粘贴得到,导致其命名空间未改变 　　 <Page x:Class="类库名. 错误文件夹名 .xaml文件名" ...> 　　并且其对应的.xaml.cs文件中的命名空间也有问题 　　 namespace 类库. 错误文件夹名 3.解决方法： 　　将上述两处改为对应的文件夹名即可 　　 来源： https://www.cnblogs.com/xm1998/p/12148275.html

1.错误描述： 　　点击运行时,InitializeComponent();报错. 　　随后此错误又消失.消失后运行仍然失败,并且不再显示错误. 　　尝试清理解决方案+重新生成解决方案,点击运行仍然重复上述内容. 　　尝试方法一 >工具>导入导出设置>重置所有设置>否>选择对应语言后 出现38个bug 提示 无法识别或访问成员 xxx. 　　排查并未发现该提示处的问题所在. 2.问题原因： 　　原因在于某xaml文件是从本项目的其它文件夹中复制粘贴得到,导致其命名空间未改变 　　 <Page x:Class="类库名. 错误文件夹名 .xaml文件名" ...> 　　并且其对应的.xaml.cs文件中的命名空间也有问题 　　 namespace 类库. 错误文件夹名 3.解决方法： 　　将上述两处改为对应的文件夹名即可 　　 来源： https://www.cnblogs.com/xm1998/p/12148275.html

1. 四种程序集加载到上下文及优缺点： 1) 默认加载上下文 加载上下文包含通过探测全局程序集缓存、主机程序集存储区（如果承载运行时）以及应用程序域的 ApplicationBase 和 PrivateBinPath 所找到的程序集。比如 Load() 使用程序集标识的重载。（探测规则请参见： 《(5)CLR 运行时探测程序集引用的步骤》 ） 使用默认加载上下文具有以下缺点： a) 加载到其他上下文中的依赖项不可用。 b) 不能将探测路径外部的位置的程序集加载到默认加载上下文中。 2) 加载位置上下文 可以从未位于应用程序路径下（并因此未包含在探测中）的某个路径加载程序集。加载位置上下文允许从该路径查找和加载依赖项，因为路径信息由上下文维护。 此上下文中的程序集可以使用加载到默认加载上下文中的依赖项。 通过使用 Assembly.LoadFrom 方法或按路径加载的其他方法之一来加载程序集具有以下缺点： a) 如果已加载一个具有相同标识的程序集，则即使指定了不同的路径， LoadFrom 仍返回已加载的程序集。 b) 如果用 LoadFrom 加载一个程序集，随后默认加载上下文中的一个程序集尝试按显示名称加载同一程序集，则加载尝试将失败。对程序集进行反序列化时，可能发生这种情况。 c) 如果用 LoadFrom 加载一个程序集，并且探测路径包括一个具有相同标识但位置不同的程序集

// 注: 以下内容大量借阅自<<Webkit技术内幕>>--朱永盛(14年出版的) , 很多内容可能早已更新 。部分摘录内容有删减 , 目录为了编辑方便作了些改动。读者可自行下载原文档阅读。 1. Webkit 的网页渲染过程 1.1.1 加载和渲染: 　　浏览器的主要作用就是将用户输入的 URL 转变成可视化的图像。按照某些文档的分析, 这其中包含两个过程。其一是网页加载过程，就是从"URL"到构建DOM树, 其二是网页渲染过程，从DOM树到生成可视化图像。这两个过程也会交叉。 　　网页渲染还有一个特性, 那就是网页通常比我们的屏幕可视面积要大(在移动设备上尤其明显), 而当前可见的区域, 我们称为视图(viewport)。 　　因为网页比可视区域大, 所以浏览器在渲染网页的时候, 一般会加入滚动条以帮助翻滚网页。 1.1.2 Webkit 的渲染过程 　　数据和模块 　　数据包括网页内容 , DOM, 内部表示和图像 　　模块包括 HTML解释器, CSS解释器, JavaScript引擎以及布局和绘图模块。 　　 　　根据数据的流向, 可以将渲染过程分成三个阶段, 第一个阶段是从网页的URL到构建完 DOM树, 第二个阶段是从 DOM树到构建完 Webkit的绘图上下文, 第三个阶段是从绘图上下文到生成最终的图像。 　　第一个阶段 　　从网页 URL 到构建完

转自https://blog.tonyseek.com/post/the-context-mechanism-of-flask/ Flask 的 Context 机制 2014 年 07 月 21 日 用过 Flask 做 Web 开发的同学应该不会不记得 App Context 和 Request Context 这两个名字——这两个 Context 算是 Flask 中比较特色的设计。 [1] 从一个 Flask App 读入配置并启动开始，就进入了 App Context，在其中我们可以访问配置文件、打开资源文件、通过路由规则反向构造 URL。 [2] 当一个请求进入开始被处理时，就进入了 Request Context，在其中我们可以访问请求携带的信息，比如 HTTP Method、表单域等。 [3] 所以，这两个 Context 也成了 Flask 框架复杂度比较集中的地方，对此有评价认为 Flask 的这种设计比 Django、Tornado 等框架的设计更为晦涩。 [4] 我不认同这种评价。对于一个 Web 应用来说，“应用” 和 “请求” 的两级上下文在理念上是现实存在的，如果理解了它们，那么使用 Flask 并不会晦涩；即使是使用 Django、Tornado，理解了它们的 Context 也非常有利于做比官网例子更多的事情（例如编写 Middleware）。

块级格式化上下文（Block Fromatting Context）是按照块级盒子布局的。 BFC是一个独立的布局环境，其中的元素布局是不受外界的影响，并且在一个BFC中，块盒与行盒（行盒由一行中所有的内联元素所组成）都会垂直的沿着其父元素的边框排列。 W3C对BFC的定义如下： 浮动元素和绝对定位元素，非块级盒子的块级容器（例如 inline-blocks, table-cells, 和 table-captions），以及overflow值不为“visiable”的块级盒子，都会为他们的内容创建新的BFC（块级格式上下文）。 即满足以下其中任一或多个条件： 1、float的值不是none。 2、position的值不是static或者relative。 3、display的值是inline-block、table-cell、flex、table-caption或者inline-flex 4、overflow的值不是visible 作用： 内部的Box会在垂直方向上一个接一个的放置 垂直方向上的距离由margin决定。（完整的说法是：属于同一个BFC的两个相邻Box的margin会发生重叠，与方向无关。） 每个元素的左外边距与包含块的左边界相接触（从左向右），即使浮动元素也是如此。（这说明BFC中子元素不会超出他的包含块

重点：在相同的层叠环境及优先级下，inline/inline-block元素的层叠顺序高于block元素。 详解链接： https://www.codercto.com/a/23706.html 本文转载自：https://juejin.im/post/5b876f86518825431079ddd6，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有。 最近，在项目中遇到一个关于CSS中元素 z-index 属性的问题，具体问题不太好描述，总结起来就是当给元素和父元素色设置 position 属性和 z-index 相关属性后，页面上渲染的元素层级结果和我预想的不一样。根据自己之前的理解，也没找到一个合理的解释。我知道，肯定是我对相关属性的细节理解存在问题，所以结合官方文档和在网上各种搜集整理，明白了其中的原因。写下这篇文章，和大家分享有关CSS中 层叠上下文 、 层叠等级 、 层叠顺序 以及 z-index 相关的一整套技术细节。 如果存在什么错误或重要遗漏或者有什么疑问，欢迎留言指正、讨论！感谢！ 本文已同步至我的个人主页。更多内容，欢迎访问我的GitHub主页，谢谢关注和支持！ 一个“片面”的理解 以往，由于自己使用 z-index 的频率不大，所以对这个CSS属性存在比较片面的认识。一直认为 z-index 就是用来描述定义一个元素在屏幕 Y轴 上的堆叠顺序。

Django中间件（Middleware） 是一个轻量级、底层的“插件”系统，可以介入Django的请求和响应处理过程，修改Django的输入或输出. django 中的中间件（middleware），在django中，中间件其实就是一个类，在请求到来和结束后，django会根据自己的规则在合适的时机执行中间件中相应的方法。 在django项目的settings模块中，有一个 MIDDLEWARE_CLASSES 变量，其中每一个元素就是一个中间件. 中间件的结构: 中间件中可以定义5个方法，分别是： 旧版，目前新式写法第１种和第５种已不用． process_request(self,request) : 执行视图之前被调用，在每个请求上调用，返回None或HttpResponse对象 process_view(self, request, callback, callback_args, callback_kwargs): 调用视图之前被调用，在每个请求上调用，返回None或HttpResponse对象 process_template_response(self,request,response): 在视图刚好执行完毕之后被调用，在每个请求上调用，返回实现了render方法的响应对象 process_exception(self, request, exception)