[ZDP] PTK, not XML is the answer... more on role-based modeling

[Jim Salmons]

Far out Martijn,

	Thank you for taking the time to read and think about my post. I won't take
the time to item-wise respond to your thoughtful reply. It will take more
time to do that... and that, unfortunately, is what none of us have enough
of these days.

	But here's a slice more which answers your question about domain objects in
an executable model...

	Yes, there are very definitely domain objects in an executable model. They
tend to be thin objects. That is, they model the instance-describing
attributes as you would expect. They also have a public interface for being
self-descriptive so model objects can manipulate them and so presentation
framework objects, role-specific view objects for example, can dynamically
generate views onto any object throughout the object's lifecycle. They have
a private interface for mapping to whatever back-end store supporting
persistence you need, etc.

	What they DON'T have are methods which empower them with illogical
capabilities. I can readily accept a 'UPS_package' object which knows how to
'print' a representation of itself, but a fat 'UPS_package' object which
knows how to 'deliver' itself is down-right stupid. Don't laugh. There are
plenty of alleged object gurus who push this "you don't know objects until
you can make cool, fat, smart domain objects" bunk.

	When you hide your model of what is really going on in fat domain objects,
you repeat the biggest problems of application-centric programming.... reuse
plummets, maintenance is difficult and extension is crippled.

	The whole notion of 'application' is an unfortunate artifact of compiler
design. Applications are the work product of a compiler. It's the WRONG
chunking mechanism for ANY reasonable design.

	The power of objects is that you break that flawed coupling. But breaking
the physical coupling is far easier than breaking the mental one.
Application-centric thinking (as opposed to executable model thinking) is
what pushes object technology users toward fat domain objects and makes them
blind to the real model.

	In an executable model, the domain objects course through the executing
model much like a piece of paper would pop in and out of baskets on a
worker's desk. Wrapper objects give role-specific state as needed. Sometimes
a role actor's action changes the 'real' state of the domain object, other
actions cause task-specific states to change which are maintained in a
domain object's task-specific wrapper object.

	This brings us back to my intentionally provocative statements about XML.
XML is a most important technology. But it is an enabling technology, not an
'anchor' technology. Objects are an 'anchor', XML is a supplement. The
danger of designing around an XML implementation is that it sucks you into
application-centric, document-centric, 'objects as things' thinking which
blinds you to the real problem space.

	We'll get to XML considerations, but in time. The 'X', after all, is
extensible. We'll know what these extensions are when we have the underlying
model right.

	End part 2... Role-based executable business models and ZOPE2/PTK are made
for each other...

	More later,
	--Jim--

Jim Salmons and Timlynn Babitsky
___________________________________________
   JFS Consulting, a North Carolina nanocorp
   http://jfsconsulting.com/home/nanocorp_welcome.html
   Our web businesses
		http://sohodojo.com
		http://squirrelfeeders.com
		http://popculturestore.com
		http://sailabaco.com