Re: Something better than ZClasses (was: Re: [Zope-dev] Re: Zcatalog bloat problem (berkeleydb is a solution?))
Well, it's quite logical: UML can be used to map out both software and business development (they are, after all, two sides of the same story), the designer can twiddle-n-polish the interface and the programmer can take care of 'exceptional tasks' that can't easily be taken care of via the UML interface without adding too much complexity.
I agree. The facts are: - A simple DTML Zope programmers costs are okay and maybe below programmer average. - A good Zope/Python programmer will cost above average. - A good Zope/Python System-Designer is very expensive. Because of that you try to minimize the Designer's time by providing a nice tool (UML tool, such as ObjectDomain). Then you try to minimize the Python Programmers time by auto-generating the framework and only make him to fill the methods with life. Now, because we have a UML diagram, the DTML programmer can start right away with programming the DTML and HTML around the data/functional model, since the API is clear. This way you optimized several things: - Minimize the time of the expensive people. - Minimize the development time, since many people can work parallel. - Because of the above, you minimize risk and money spent. And voila, you have a well functioning RAD team.* * This assumes that your team works together well. ;-) Regards, Stephan -- Stephan Richter CBU - Physics and Chemistry Student Web2k - Web Design/Development & Technical Project Management
On Tue, 26 Jun 2001, Stephan Richter wrote:
- A simple DTML Zope programmers costs are okay and maybe below programmer average. - A good Zope/Python programmer will cost above average. - A good Zope/Python System-Designer is very expensive.
Because of that you try to minimize the Designer's time by providing a nice tool (UML tool, such as ObjectDomain). Then you try to minimize the Python Programmers time by auto-generating the framework and only make him to fill the methods with life. Now, because we have a UML diagram, the DTML programmer can start right away with programming the DTML and HTML around the data/functional model, since the API is clear. This way you optimized several things:
If DTML programming / interface design is so simple, and cheap, why not automate it? (Strike two for low cost development). I've been trying to save some time (and my fingers!) by building a RAD framework, named the WarpFramework [1], which deals with the low level complexity of properties and how to display / manipulate them in addition to other common programming tasks.. this could perhaps blend in easily.. Say for example that we could provide the odd designer with the possibility of simply pushing widgets and displays (generated automatically of course) around the page, and changing colors and backgrounds (CSS); then we have a tool that designers would love as well.
- Minimize the time of the expensive people.
Minimize the time of people. Period. :-) . o O ( Many small rivers make.. )
- Minimize the development time, since many people can work parallel.
..lessen the complexity and add to robustness.
- Because of the above, you minimize risk and money spent. And voila, you have a well functioning RAD team.*
* This assumes that your team works together well. ;-)
Well, somebody's got to do something, eh? ;-) [1] http://www.sourceforge.net/projects/warp-framework Regards from France, Morten
If DTML programming / interface design is so simple, and cheap, why not automate it? (Strike two for low cost development).
I've been trying to save some time (and my fingers!) by building a RAD framework, named the WarpFramework [1], which deals with the low level complexity of properties and how to display / manipulate them in addition to other common programming tasks.. this could perhaps blend in easily..
What does it do already? (O.k., I know the answer: Read the code ;-))
Say for example that we could provide the odd designer with the possibility of simply pushing widgets and displays (generated automatically of course) around the page, and changing colors and backgrounds (CSS); then we have a tool that designers would love as well.
That's what we at iuveno are doing right now. SmartSections (to be released soon) are simple page elements like headers, HTML text, images, etc. that can be moved around, added, copied and pasted, deleted etc. A ZClass-based proof-of-concept is in the Kontentor 1.x framework. The whole thing will then be embedded into SmartPortals, which are configurable web pages where you can move around boxes etc. Remember I presented the idea in Amsterdam? We are very open to ideas and help!
Minimize the time of people. Period. :-)
Yep!
..lessen the complexity and add to robustness.
Yep! Joachim
participants (3)
-
Joachim Werner -
Morten W. Petersen -
Stephan Richter