原创作者: macrochen
阅读:2566次
评论:0条
更新时间:2011-06-01
GEF以前学习过, 而且还按照Dudu的教程做了一遍, 在网上也找了不少资料, 不错的文章也转载了不少,只不过当时对插件开发还只是一知半解, 对图形开发更是没有什么概念,导致的直接后果就是:现在基本上全部忘记光了,于是不得不从头开始,不过这次不仅要知其然, 而且还要知其所以然, 不过理解起来还是比较快的, 不知是拖以前学习的底子的福, 还是因为这么长时间做Eclipse开发来的基础
在理想的情况下，命令应当只知道模型。因此应当尽量避免对EditPart和图形的引用。
图形(Figure)不应该去访问EditPart和Model, 即使Figure要引用EditPart, EditPart也只是作为一个Listner来被应用,而不是直接去引用一个EditPart
一个Model实例会对应一个EditPart, 因为EditPart会随着Model的存在而存在, 而model随时可能被删除, 所以在EditPart中应尽量少包含一些长效信息,而且应该避免Command去引用EditPart
EditPart的refreshVisuals()方法只会在其初始化的时候被自动调用,如果model发生变化,需要更新图形界面时,必须手动调用refreshVisuals()方法.
连接(connection)是通过source和target连接点来获取的, 而且connection的EditPart只会创建一次, connection也是一种图形,它必须通过ConnectionAnchor挂在另外两个图形上面,因此必须告诉connection它所需要的两个anchor在哪里, 默认情况GEF会通过给连接图形的EditPart实现NodeEditPart接口来提供所需要的anchor, 这样做一个是因为anchor是与连接图形关联的,而连接在开始的时候是不知道anchor在哪里的, 另一个原因是, 当用户创建一个connnection的时候, Connection EditPart还没有被创建
EditPart通过监听器来获得模型的修改,并提供方法去刷新视图, 比如子节点被删除,将调用refreshChildren()方法去删除子节点对应的图形和EditPart, 如果只是属性发生变化,那么将调用refreshVisuals()方法, 因为该方法会频繁调用,因此在调用前应该做一些判断来避免不必要的刷新
一般在active()方法中添加listener, deactive()中删掉这些添加的listener,
在EditPart中, 由图形修改导致模型修改是通过command来实现, 而模型修改导致图形修改则是通过listener来实现
EditPart是GEF的核心, 对于一个可编辑的模型元素都必须有一个对应的EditPart类对应, 在EditPart中有两个容易混淆的方法:getModelChildren()返回包含在当前模型中的子模型, getChildren()返回子模型对应的EditPart
如果父图形不是子图形的直接父亲, 那么需要实现AbstractGraphicalEditPart.getContentPane()方法, 得到的对象将用来存放所有的子图形
当用户在图形编辑器中执行操作的时候, GEF在内部会创建相应的Request, 比如新建一个对象将生成CreateRequest, 它包含了新建对象的模型实例, 用来存放该Request的EditPart
对于我们的EditPolicy实现来说, 我们要做的大部分工作就是根据request创建一个Comamnd对象, Command子类一般要实现execute和undo方法,execute方法就是用来将图形的改变更新到模型上, Command更多的是对模型的依赖, 而跟GEF其他的组件没有什么关系, 比如绝对不会去引用EditPart和EditPolicy实例
在理想的情况下，命令应当只知道模型。因此应当尽量避免对EditPart和图形的引用。
图形(Figure)不应该去访问EditPart和Model, 即使Figure要引用EditPart, EditPart也只是作为一个Listner来被应用,而不是直接去引用一个EditPart
一个Model实例会对应一个EditPart, 因为EditPart会随着Model的存在而存在, 而model随时可能被删除, 所以在EditPart中应尽量少包含一些长效信息,而且应该避免Command去引用EditPart
EditPart的refreshVisuals()方法只会在其初始化的时候被自动调用,如果model发生变化,需要更新图形界面时,必须手动调用refreshVisuals()方法.
连接(connection)是通过source和target连接点来获取的, 而且connection的EditPart只会创建一次, connection也是一种图形,它必须通过ConnectionAnchor挂在另外两个图形上面,因此必须告诉connection它所需要的两个anchor在哪里, 默认情况GEF会通过给连接图形的EditPart实现NodeEditPart接口来提供所需要的anchor, 这样做一个是因为anchor是与连接图形关联的,而连接在开始的时候是不知道anchor在哪里的, 另一个原因是, 当用户创建一个connnection的时候, Connection EditPart还没有被创建
EditPart通过监听器来获得模型的修改,并提供方法去刷新视图, 比如子节点被删除,将调用refreshChildren()方法去删除子节点对应的图形和EditPart, 如果只是属性发生变化,那么将调用refreshVisuals()方法, 因为该方法会频繁调用,因此在调用前应该做一些判断来避免不必要的刷新
一般在active()方法中添加listener, deactive()中删掉这些添加的listener,
在EditPart中, 由图形修改导致模型修改是通过command来实现, 而模型修改导致图形修改则是通过listener来实现
EditPart是GEF的核心, 对于一个可编辑的模型元素都必须有一个对应的EditPart类对应, 在EditPart中有两个容易混淆的方法:getModelChildren()返回包含在当前模型中的子模型, getChildren()返回子模型对应的EditPart
如果父图形不是子图形的直接父亲, 那么需要实现AbstractGraphicalEditPart.getContentPane()方法, 得到的对象将用来存放所有的子图形
当用户在图形编辑器中执行操作的时候, GEF在内部会创建相应的Request, 比如新建一个对象将生成CreateRequest, 它包含了新建对象的模型实例, 用来存放该Request的EditPart
对于我们的EditPolicy实现来说, 我们要做的大部分工作就是根据request创建一个Comamnd对象, Command子类一般要实现execute和undo方法,execute方法就是用来将图形的改变更新到模型上, Command更多的是对模型的依赖, 而跟GEF其他的组件没有什么关系, 比如绝对不会去引用EditPart和EditPolicy实例
评论 共 0 条 请登录后发表评论
您还没有登录,请您登录后再发表评论