[Ztm-devel] ZTM Improval Proposals

[Arnar L. <arn...@bo...>]

Hi,

this email is the first ZTM change proposal. Change proposals will be =
part of
our ongoing work to open up the development process and improve the =
quality of
our methods. It is inspired by zope.org's fishbowl process, and will =
hopefully
improve the quality of the ZTM codebase by forcing us to consider =
changes more
thoroughly.

The process may be somewhat heavy, but the scope of the intended =
proposals
should be of a size that they should be carefully considered.

This means that we still need a method for suggesting/contributing minor
improvements to templates and code.


There are several things we are hoping to achieve with this process:

  1. Feedback, discussions, opinions and improvements of proposals.
 =20
  2. Documenting and describing larger changes and developments.
 =20
     Hopefully these proposals will become well-documented a history
     of the architectural discussions and decisions of ZTM.

  3. Generate interest in the future of the ZTM project.

     We need to formulate and communicate our visions of what ZTM is and =
can
     become.

  4. Assist development of a ZTM roadmap.

  5. Display that ZTM is under development and maintainence.

  6. Attract sponsorship of feature development.

  7. Make it possible for new people to contribute
 =20
 =20
Other parties are invited to write or request proposals for issues they =
have=20
with ZTM.


We will probably set up a WikiWikiWeb somewhere to serve as an incubator =
for
ideas like this one.


  -- Arnar

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D

Proposal 1:=20

  A specialized TypeInformation for topic types.

Technical description:

  A TypeInformation (TI) is the kind of object that is created under the
  portal_types component and represent the various content types in the
  portal.

  If you visit the portal_types component in the Zope Management =
Interface
  (ZMI), you will see that there are two standard TIs; Factory Type
  Information and Scriptable Type Information. These objects describe =
how to
  create content objects, what templates they use, metadata etc..=20

  You can see what they offer by studying existing TIs in your browser.

Problem description:

  To introduce a new portal type, one currently creates a new topic and
  manually sets it as a instance of the topic 'topictype'. Next one =
navigate
  to the portal_topicmaps tool and run the script that creates new TI =
entries
  under portal_types based on topictypes from the topic map.
 =20
  This process is fairly simple, and has improved the usability of ZTM
  enormously. It has also made us see ZTM as RAD tool, and having tasted =
that
  we want more of it.
 =20
  The problem is that portal types and TIs are disconnected from topic =
types.
  When something changes in the topic maps system ontology, the TIs are =
not
  updated. Since TIs partially represent the same concepts (subjects) as =
the
  topic types, we should have one place to go to for changes.
 =20
  This is especially noticable during development when one want often =
want to
  change a type, rename a method, use different templates etc...
 =20
  Secondly, portal_types contains configuration that is stored outside =
of the
  topic map. This means that although Zope has builtin marshalling, it =
cannot
  be exported and imported easily by an automatic setup. The format =
(pickle)
  is propietary and not easy to keep under revision control.
 =20
  Another issue is internationalization (i18n). The standard TI's have =
some
  issues here. Topic Maps already contain a brilliant structure for =
supporting
  different languages, and we want to use that.

Suggested solution:

  We introduce a new TI called TopicTypeInformation (TTI). The =
portal_topicmap
  tool is extended to monitor introduction, changes and deletion of =
topic
  types, and manage the TTIs.
 =20
  A TTI will have a direct reference to the topic type it represents, =
and
  subscribe to relevant events.

  Title, Description, portal_type, constructor, templates and other
  configurables will be retrieved directly from the topic type. This way =
we
  can support i18n by using scope.
 =20
  The TTI will clean up any changes in the topictype in relation to the
  Content Management Framework (CMF), especially the portal_catalog.
 =20
 =20
  The advantage of automatically building portal_types will allow us to
  remove crufty setup code, and move us closer to the goal of supporting =

  throw-away-databases in our development process. The advantage being
  that configuration is moved into the topicmap which can and should be=20
  put under revision management.  =20

  We have been annoyed by the need to configure and depend on objects =
being
  available in the ZODB instance. We believe supporting "throw-away
  development" can improve the quality of our products and promote =
reuse.
 =20
 =20
  Historically ZTM development has followed the OO approach. We were
  subclassing ZTopic for all kinds of content and introduced the
  "Innholdstype" concept on forbrukerportalen.no to avoid duplicating =
code.
 =20
  About 16 months ago Tom Bech and I discussed this annoyance, and we =
realized
  that this limitation could be removed by properly using the =
portal_types
  component.
 =20
  This suggestion is an extension of that thinking and the fact that we =
have
  seen it work so well for ITU and later projects.
 =20
 =20
  A smaller advantage is that Topics now always has the meta_type =
'Topic', and
  a portal_type that matches the topictype. This makes a lot of code =
easier to
  write.
 =20
 =20
  Topics can now change types, or even have multiple types. (Not sure =
how
  useful that is, roles might be a more correct way of modelling. Use =
Cases
  wanted.)=20
  =20
Risks:

  Why do we want to make it easy to create new content_types? Will this =
not
  make it to easy to create imprecise content types that are not easy to
  correct?

    First of all it makes ZTM a RAD tool. Ideally a usability expert can =
sit
    down with at web designer and build a website totally Through The =
Web
    (TTW).

    There is a danger that content type overload can happen, but I think =
that
    it is a good thing to have this opportunity.

    But more likely is that users will feel empowered by this and start =
using
    a wider range of topic map features.

    We now also have the posibillity to let contributor suggest new =
content
    types, new association types, new roletypes, new occurrencetypes =
etc..

    We think that will let implementors create better ontologies that =
can more
    easily be adapt to changes by non-developers.

  By not subclassing ZTopic, we need to put code elsewhere. This means =
that
  certain components need to be more complex and need more =
infrastructure.

    This is a job we have already started and it is mainly a refactoring =
job.
    I think it also avoids a lot of code redundancy.

  These changes mean that we will have to rethink the way we handle =
templates,
  but that will be a proposal of its own.

  Certain operations in large topicmaps may need to change large =
portions of
  the database. This may surprise users, and can lead to usability =
issues.

    One doesn't change the system ontology that often in production, and =
this
    will usually be done by users that know the system.
 =20
    The main issue here is catalog-updates and that can be mitigated. It
    requires us to hook into the internal ZCatalog datastructures which
    is not exactly a maintainable thing to do.

    We don't want to go beneath the ZCatalog API, but if there is no =
other
    way... (We already do a bit of this.)



Thoughts, comments?


   -- Arnar