Presentation is loading. Please wait.

Presentation is loading. Please wait.

TransWarp and the Future of ZPatterns IPC 9 Zope Track.

Similar presentations

Presentation on theme: "TransWarp and the Future of ZPatterns IPC 9 Zope Track."— Presentation transcript:

1 TransWarp and the Future of ZPatterns IPC 9 Zope Track

2 Ambiguous Praise For ZPatterns 4 "... if I could understand what it does I'd probably use it." - Brad Clements 4 "... everytime I've come across a technology I had trouble understanding, it turned out to be a worthless technology or a good one where the authors had trouble explaining their stuff. For the time being, I've placed ZPatterns in the latter category" - Cees de Groot

3 Praise For ZPatterns at IPC 9: 4 Its certainly made my life more… interesting. –Steve Spicklemire 4 We had been taught the value of commenting code in our computer classes, but this experience [with ZPatterns] really made us see why it is important to do so. –Lex Berezhny & Jason Straw

4 Issues with ZPatterns 4 Difficult to teach/grasp 4 Tedious development: same names retyped –As ZClass properties –As SQL fields in queries and DDL –As form text and field names –In SkinScript –etc. 4 Inherently a hack, promoting further hacks ad infinitum

5 Our Quest for Automation 4 Write once, use many 4 Metadata was the key 4 UML is standard for metadata, XMI for interchange of UML 4 But no UML or XMI tools for Python 4 Code generation from XSLT was ridiculous 4 Had to create our own system

6 Introduction Components: The Future (And Present) Of Programming

7 Where did ZPatterns come from? 4 Ty and PJE needed a component model for Zopelications 4 Zope component capabilities were poor or non-existent for: –Distributing components without upgrade breakage –Configuring components to work with components outside their own product –Separating data storage from logic and UI code

8 Concepts/Assumptions 4 Objects are domain objects, representing real-world things 4 Real-world things have data stored about them in many databases 4 For a given piece of data, there may be many conceptual objects 4 Thus, a useful framework must allow many- to-many mappings between physically stored data and conceptual objects

9 Therefore… 4 An objects attributes should be able to be stored in any database, without forced one- to-one mappings 4 There should be a way to create or access instances of objects, knowing only their interface, not their implementation class or storage mechanisms

10 The RIPP Model 4 Not tool-specific or implementation specific, but a generally reusable architecture pattern 4 A way of structuring Zope or ZPublisher applications as: –Reusable, configurable components, with –Separation of application logic from storage and user interface code, and –Separation of implementation class choices (variable) from application roles (fixed)

11 RIPP Overview

12 Component Architectures 4 Design Patterns/Idioms are key to an effective component architecture: –What components should exist? –How is the work divided among them? –How are they put together to form larger structures? 4 The RIPP patterns are a first step in this direction - TransWarp is the next

13 TransWarp: Its Not Just Components Any More (Its component architectures, which means patterns, which means repetition, which means automation!)

14 The Why of TransWarp 4 Easy as –Draw applications with UML –Add application-domain logic –Mix with implementation frameworks +=

15 The What of TransWarp

16 What is AOP? 4 Separately Specified Areas of Concern –e.g. Persistence, User interface, domain logic 4 Ability to weave these areas into a single program 4 Modular replacement of implementation for each area in a given application

17 Generative Programming (GP) The Automation Assumption: If you can compose components manually, you can also automate this process. –Czarnecki and Eisenecker, Components and Generative Programming

18 Plan + Parts = Products

19 Structural Aspect 4 The aspect of a component that describes its class hierarchy and structural features 4 Structural feature = Attribute, Association 4 Can be derived directly from UML model 4 Reusable with different implementations of domain logic, storage, user interface

20 Structural Models 4 Structural model provides implementation for a structural aspect 4 Defines classes to be used for attribute, associationEnd, etc. 4 Standardized storage interface for model updates and queries, including predicates 4 Based on the Services, Elements, and Features pattern

21 Services, Elements, And Features

22 Cool Tools CASE, UML, XMI, SQL… Its 100% Buzzword Compliant!

23 TransWarp CASE 4 UML Model Library –Built using a StructuralAspect representing the UML MetaModel –Full StructuralModel features available: use predicate queries create new interfaces for UML model manipulation your choice of storage mechanisms 4 XMI Library

24 Objects + SQL = Warp CORE 4 CORE = Customizable Object-Relational Environment 4 Pattern language for storing business objects in a relational database 4 Conceptually well-suited to RIPP model 4 Handles aggregation, composition, temporal relationships, inheritance, polymorphism 4 Highly efficient design using few tables and well-chosen indexes

25 CORE = A Design Pattern 4 Pattern language for database design, not persistence mechanism for arbitrary objects –(although you could implement one using CORE as a base) 4 Not suitable for retrofitting existing databases - it is for designing new ones 4 Does not require any special tools - weve designed and built databases by hand with it

26 The CORE Tables

27 Using CORE with TransWarp 4 Generate databases from UML –Stereotypes and/or tagged values used to identify event classes, other pragmas 4 Weave CORE storage aspect with structural model to create an app - no SQL or coding required for standard retrieves and updates 4 Put domain-specific queries (e.g. getTasksForParty) together in one aspect for easy reference/maintenance

28 So Whats Going To Happen To ZPatterns? (Im so glad you asked me that… Thats an excellent question…)

29 Zope Directions 4 Component-driven architecture 4 Interface-oriented 4 More Python-centric 4 Things are more explicit 4 Content management framework to be seperated from pure application server 4 Less need for weird hacks

30 DataSkins: Stupid Zope Tricks 4 Implementing storage separation in a through-the-web configurable way turned out to be very hard in Zope 4 Zope 2 makes lots of internal assumptions: –ZODB-based persistence –Object-based (not action-based) transactions –Local roles stored as dictionary of lists –Standardized web-based management GUI

31 Whither goest ZPatterns? 4 Now on maintenance-only track 4 Many former ZPatterns functions will probably disappear into Zope core: –PlugIns may be replaced by a more interface- savvy management UI –Factory mechanisms may allow straightforward creation of objects without reference to a Specialist, allowing fewer Specialists to be used in many applications

32 Even if there is a Z3Patterns… 4 Will only implement RIPP model 4 SkinScript, Providers may go away 4 Primary development focus will be on TransWarp, which will be much more useful and powerful for future Zopes

33 So When Can We Use TransWarp? (I had a feeling that you were going to ask me that…)

34 TransWarp Project Status 4 AOP tools available today 4 GP, UML, and XMI tools being ported from pre-AOP library 4 WarpCORE patterns have been used for production systems, but automation not developed. –Solid automation requires the GP, UML, and XMI tools to exist first

35 Licensing & Contributions 4 License: BSD-style, minus any advertising or credit requirements. No warranty. 4 Contributions Wanted: Horizontal aspect libraries (UI, DB/persistence, logging, testing, documentation generation, code generation, etc.)

36 TransWarp Links TransWarp Documentation Wiki TransWarp Software Releases

37 ZPatterns: RIPP Tools for Zope 4 LoginManager - the first RIPP-based Zope product; co-designed with Mike Pelletier 4 ZPatterns pieces gradually refactored out of LoginManager and into ZPatterns –Implementors became Specialists

38 ZPatterns Spin-offs (non-RIPP) 4 PlugIns system - better management screens and drop-in configuration 4 DataSkins system - separating data storage from logic/UI, primitive AOP

39 GP: Automating Construction

40 GP, Applied in TransWarp

41 Putting It All Together

Download ppt "TransWarp and the Future of ZPatterns IPC 9 Zope Track."

Similar presentations

Ads by Google