[ZDP] ZDP-Tools: Discussion about Book, Part and Chapter continued.

[Annika]

Hi Tom !

Tom Deprez schrieb:
> 
> mmm, why do we have to follow XML structure if we can do it in Zope > easier?

You can do it both ways. The XML way is the way I would have designed
it even if I would not have had XML in mind. It is just consequent
to design the Book like we designed all the other ZClasses.

The question is just what changes and additions may happen in the
future, and which model would cater for this kind of change.
Right now we are adding many objects, and taking back design decisions
is easy now, but if we try to do the same once we have the
implementation, changing things will cost manyfold.

Right now the changes are restricted to just ZBook, and changing later
will not be that hard if we see a need for doing this. So, I think
you should go with the solution you have found.

Greetings,

Maik Röder
 
> ----- Original Message -----
> From: Maik.Röder <roeder@berg.net>
> To: <zdp@zope.org>
> Sent: Saturday, January 22, 2000 6:41 PM
> Subject: [ZDP] ZDP-Tools: Discussion about Book, Part and Chapter continued.
> 
> > Hi !
> >
> > > > You have trapped me here. As I said earlier the solution is making
> > > sections.
> > > > Sections can be placed in Books, Parts, Chapters, SubChapter and
> > > SubSubchapters.
> > > > This way each of these structure objects are responsible for
> displaying
> > > > the Sections differently.
> > >
> > > Well, there is my confusion... Since Parts, Chapters, SubChapters ....
> are
> > > in fact the same, why then should they display their Sections
> differently?
> >
> > Indeed, they display their Sections all the same, but they do display
> themselves
> > and their children differently ! It was wron to call the content
> "Section", because
> > a Section can seen as the same kind of thing as a Part and Chapter only a
> little
> > bit smaller. I would say we just need to reuse DocumentFolders to contain
> the
> > domain objects, and forget about Sections.
> >
> > > As I was working on the ZBook classes I found the following :
> > >
> > > Chapter I content stays as default
> > >    Chapter I.1 content stays as default
> > >        Chapter I.1.1 in content we place the text
> > >        Chapter I.1.2 in content we place the text
> > >    Chapter I.2 in content we plaxe the text
> > >    Chapter I.3 content stays as default
> > >       Chapter...
> >
> > As you can see Chapter I has a number "I", and none of the
> > children under Chapter I know this !
> >
> > If you would make Chapter I a Part and Chapter I.1 a Chapter,
> > then Chapter would only store the 1 ! Because in the breadcrumbs
> > you already have I > 1 so you know where you are.
> >
> > When you move a Chapter around, maybe to another Part, then
> > you just cut and paste, and adjust the chapter number which
> > is maybe "1" to "2". But you should not store the "I" of "I.1"
> > in a Chapter, because the information about the "I" is wrong
> > when you put the Chapter into another Part.
> >
> > > Browsing to Chapter I shows nicely the different chapters inside it.
> > > Browsing to Chapter I.1 also
> > > Browsing to Chapter I.1.1 shows the text
> > >
> > > ....
> > >
> > > About Chapter as I and chapter as 1.
> > >
> > > I think a solution to this when using above system is making another
> ZClass
> > > (or just a file) which allows to define that when level =1 used text is
> I,
> > > level 2 = 1, default = 1.
> >
> > In my opinion designing for change is the best solution here. We have
> defined
> > a nice XML file with Part->Chapter->Subchapter, and we need to mirror this
> using
> > ZClasses. The only point that was somewhat open is where the content
> should
> > go.
> > I would say that the content should be the smallest manageable piece of
> information.
> > We don't need to make the smallest manageable piece a paragraph, because
> this
> > would mean some explosion of objects, but I think if we define the
> smallest piece
> > of manageable information a DocumentFolder, then it is left open what size
> it can
> > have. In a Part it may be small, in a Chapter long, and in a Subchapter a
> medium,
> > but this is up to the author anyway.
> > DocumentFolders can be placed inside Books, Parts, Chapters and
> Subchapters. So, inside
> > all these ZClasses, we collect all contained DocumentFolders and display
> them. This way,
> > for example a Chapter can be split into two DocumentFolders, which are
> from two authors,
> > and maybe it will be necessary to put them into a Subchapter for
> themselves at one
> > time in the future, so everything is open to change.
> >
> > So, Books, Part, Chapters and Subchapters are only Controllers who control
> > the contained domain objects DocumentFolder.
> >
> > As I said earlier, what we have now is sufficient:
> >
> > Book
> > Part
> > Chapter
> >
> > We don't need to make extra Subchapters now, because it may be sufficient
> that it
> > is possible to place multiple DocumentFolders into the Chapters to emulate
> Subchapters
> > for the time being. Once we decide we need Subchapter, we just rename the
> Chapter to
> > Subchapter and create a new ZClass Chapter.
> >
> > So, everything stays as it is, and we don't need to worry about numbering
> > and depth. We just put DocumentFolders into the existing ZClasses and
> collect
> > them in the existing Books, Parts and Chapters.
> >
> > Greetings,
> >
> > Maik Röder
> >
> > _______________________________________________
> > ZDP maillist  -  ZDP@zope.org
> > http://lists.zope.org/mailman/listinfo/zdp
> >
> >