Stephan Richter wrote:

On Friday 12 August 2005 04:20, Dominik Huber wrote:
Your question points out the general problematic the implementation
decision between classification and composition. Zope 3 has the power to
reduce an object to its *pure* identity and implement all further
functionality by adapters and annotated objects (see
zope.app.annotation). This possibility allows you to build objects
heavily throu composition. In extreme case the classification aspect is
*only* used to determine the adapter lookups and other registration
aspects.

Therefore it will be usefull to use interfaces to build the above
classification, but - and that's very important - that does not mean
that you transfer this classification directly to your deeper
implementation (classes), but you could use *pure* marker interfaces for
that classification purpose too. Those pure marker interfaces could mark
instances of a generic object implementation [1].

Right, I know you follow this approach with Tiks and it is probably a good approach for CMSs, where everything depends on the behavior in the system,
CMS was never the core target. The indent is to offer easily orthoganl functionality (for example cms-functionality) within specific business models and its content components. (It's not my purpose to force somebody on my approach, but I wanted to sketch an additional possibility/interpretation of the new component architecture.)

but for regular applications its bogus. I really expect my core objects to have a core functionality.

I would never recommend tiks for regular applications** too, but it's not bogus for regular applications doing so, it's just an overhead/overdesign. IMO it's like MVC instead of decoupling views from models, you are going to decouple models (logic) from implementations. Sometimes both is a yagni.

In the past (zope 2) lot of core-functionality (for example cms's) were forced to behave like specific business objects/applications. But all the efforts could never transform the underlying implementation and their core-functionality satisfactorily as soon as a certain business model was not a subset of the underlying functionality. Now we have the great component architecture and it is fairly easy to design cms and other functionalities/applications more orthogonaly. So we can think about business objects that provides a superset of a few, orthogonal (core-)functionalities/applications. It would make sense to find a passable way to handle/monitor all this orthogonal functionalities within a single business-object instance. Such an instance is a compostions of objects that are supporting this orthagonal functionalities/applications. IMO in those cases it is pointless to argue about which functionality of those delegatees will be the most *core* and implement that within its class, it's just arbitrariness.

Regards,
Dominik

**IMO a regular application has a pretty stable business model, but there are a lot of unorthodox, evolving beasts in that respect. Those applications are basing on switching, expanding or growing business models. Those unorthodox applications has to focus most of the time to more general core functionalities such as 'to be cost-effective and handle the logical changes over the application's life cyle for nothing' etc. ;)



_______________________________________________
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

Reply via email to