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 1-2-3 –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 http://www.zope.org/Members/pje/Wikis/TransWarp TransWarp Software Releases http://www.zope.org/Members/pje/TransWarp/

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