openstack之horizon源码分析之二

一、概述:

  django基础入手:

    django新建project:#django-admin startproject mysite

1 生成如下目录:
2 mysite
3 ├── manage.py
4 └── mysite
5 ├── __init__.py
6 ├── settings.py
7 ├── urls.py
8 └── wsgi.py

    创建一个app,名叫demo:#cd mysite; pythone manage.py startapp demo 

1 则生成如下目录:
2 demo/
3 ├── __init__.py
4 ├── admin.py
5 ├── models.py
6 ├── tests.py
7 └── views.py

    把我们新定义的app加到settings.py中的INSTALL_APPS中

    修改 mysite/mysite/settings.py

             ROOT_URLCONF = 'openstack_dashboard.urls'      -- 查看绑定的urls (openstack_dashboard/urls.py)
    INSTALLED_APPS = (
      'django.contrib.admin',
      'django.contrib.auth',
      'django.contrib.contenttypes',
      'django.contrib.sessions',
      'django.contrib.messages',
      'django.contrib.staticfiles',

      'demo', --here
    )
    备注,这一步是干什么呢? 新建的 app 如果不加到 INSTALL_APPS 中的话, django就不能自动找到app中的模板文件(app-name/templates/下的文件)和静态文件(app-name/static/中的文件)

   类比一下:

    my_horizon(应该叫horizon)目录下的openstack_dashboard 相当于第二层的mysite;而horizon/horizon相当于demo
    第二层的horizon被导入到my_horizone/openstack_dashboard/settings.py中,则根据py特性,Python中在导入一个包时,实际上导入了它的__init__.py文件,当我们导入Horizon这个包的时候,__init__.py文件自动运行,在__init__.py 文件中再导入其他的包,或者模块。其中在horizon包的__init__.py文件中,此时应该看my_horizon/horizon/__init__.py的这个文件; 

跳转到horizon.base.py

  horizon/base.py,不足 1000 行,整体架构的核心,从这里出发去探索。一个进程只有一个 Site,一个 Site 有多个 Dashboard,一个 Dashboard 有多个 PanelGroup,一个 PanelGroup 有多个 Panel。 而 PanelGroup 的功能很弱,只是把下面的 Panel 组合了一下,Dashboard 的 _registerable_class 是 Panel。url 是 lazy 加载的方式,只有在第一次访问时才加载;

 

时间: 2024-08-18 07:32:31

openstack之horizon源码分析之二的相关文章

openstack之horizon源码分析

一.基础准备: Horizon是基于django webframework开发的标准的Python wsgi程序,django的设计专注于代码的高度可重用,信奉DRY原则,一切面向对象,而Horizon可以说高度match了django的设计风格.网站程序基本有三部分组成,业务逻辑代码(Python),静态文件(js/css),模板(Python中的 jinja,mako,nodejs中有jade), 用户向webserver发起请求之后,server程序找到当前url对应的模板,填充模板变量(

Hhadoop-2.7.0中HDFS写文件源码分析(二):客户端实现(1)

一.综述       HDFS写文件是整个Hadoop中最为复杂的流程之一,它涉及到HDFS中NameNode.DataNode.DFSClient等众多角色的分工与合作.       首先上一段代码,客户端是如何写文件的: Configuration conf = new Configuration(); FileSystem fs = FileSystem.get(conf); Path file = new Path("demo.txt"); FSDataOutputStream

Hhadoop-2.7.0中HDFS写文件源码分析(二):客户端实现之DFSPacket

一.简介       HDFS在数据传输过程中,针对数据块Block,不是整个block进行传输的,而是将block切分成一个个的数据包进行传输.而DFSPacket就是HDFS数据传输过程中对数据包的抽象. 二.实现       HDFS客户端在往DataNodes节点写数据时,会以数据包packet的形式写入,且每个数据包包含一个包头,n个连续的校验和数据块checksum chunks和n个连续的实际数据块 actual data chunks,每个校验和数据块对应一个实际数据块,被用来做

Spark源码分析之二:Job的调度模型与运行反馈

        在<Spark源码分析之Job提交运行总流程概述>一文中,我们提到了,Job提交与运行的第一阶段Stage划分与提交,可以分为三个阶段:         1.Job的调度模型与运行反馈:         2.Stage划分:         3.Stage提交:对应TaskSet的生成.         今天,我们就结合源码来分析下第一个小阶段:Job的调度模型与运行反馈.         首先由DAGScheduler负责将Job提交到事件队列eventProcessLoop

WebWork2源码分析续二

web 下面我们再来分析另一个拦截器的实现ModelDrivenInterceptor,首先说说他的设计目的,我们知道在Struts中通常有一个ActionFormBean他是用来封装请求数据的,在WebWork2.x中这一功能得到了进一步的发挥,他可以实现两中Action驱动模式,他们都是信息携带者. Property-Driven Model-Driven   最通俗的解释就是, Property-Driven通过属性来贯穿整个MVC,而Model-Driven就是通过Model对象来贯穿整

JUnit源码分析(二)

    在上面我们已经提到了junit.extentions包中的内容TestSetup.来看看整个包的结构吧. 先简要的介绍下包中各个类的功能.ActiveTestSuite对TestSuite进行了改进,使得每个test运行在一个单独的线程里面,并且只到所有的线程都结束了才会结束整个测试.ExceptionTestCase是对TestCase进行的改进,可以方便的判断测试类是否抛出了期望的异常.而剩下的三个类,大概你看的出来是使用了装饰模式来设计的.其中TestDecorator为具体装饰类

Backbone源码分析(二)

在传统MVC框架模式中,Model承担业务逻辑的任务.Backbone作为一个mvc框架,主要的业务逻辑交由Model与Collection来实现.Model代表领域对象,今天主要学一下Model源码中几个重要的函数. 我们先看一下Model的构造函数做了哪些事情: // Create a new model with the specified attributes. A client id (`cid`) // is automatically generated and assigned

QEMU1.3.0源码分析之二:TCG

TCG是Tiny Code Generator的简称,它之前是一个后端编译器,现在是作为一个动态翻译器来使用.在QEMU中,它主要用来将虚拟出来的系统的指令转化成真正硬件支持的指令中的从中间代码到硬件支持的机器代码的过程.前端的将指令翻译成中间代码的过程,是一个反汇编的过程. 反汇编的过程的源码的主要地址:qemu source code/target-XXX.此处的XXX指的是模拟出来的系统的架构. TCG的源码的位置是:qemu source code/tcg.这个目录下有很多文件夹,每个文

Spring AOP源码分析(二)JDK动态代理和CGLIB介绍

本篇是介绍java实现代理对象的两种方法,JDK动态代理和CGLIB.  JDK动态代理:针对你所调用的方法是接口所定义的方法.动态的创建一个类,通过实现目标类的接口来实现代理.  CGLIB:没有限制.通过继承目标类来创建代理类,实现代理.  下面看案例:  案例一,JDK动态代理:  Person和Animals都实现了Say接口sayHello方法.现在就需要对他们的sayHello方法进行拦截.  Say接口如下:  ? 1 2 3 4 public interface Say {