[BlueBream] Example for ZODB nested content object?
Ilshad Khabibullin
astoon.net at gmail.com
Fri Mar 5 04:27:17 EST 2010
Hi Paul,
Paul Harouff <pharouff at gmail.com> writes:
> The primary reason I want to use BlueBream instead of Microsoft
> Access, is so I can use the object oriented database to store nested
> content. I could kludge up something in Access (perhaps quicker), but
> I would prefer the flexibility and power of an object oriented
> environment.
>
I agree with you, but I think you should feel the advantage of BB not in the
object database but in the component architecture, first.
> The BlueBream tutorial has an example for creating a simple form class
> with two fields, name and description. I'm looking for something much
> more complicated, like a huge python dictionary object.
>
> Does anyone have a simple example of using ZODB to store nested
> content?
I have number of production examples, but no one simple :)) We have
few ways to organize nested content:
1) Make most of the units to be a standard containers (with some adjunct
by your custom schema) and hold (contain) one another.
2) Put all the units into one total container lineary and describe
relations between them in your special field (in schema) which holds:
2.1) object reference
or
2.2) integer ID of another object.
3) Describe relations between objects not in these object itself, but in
3rd objects, i.e. special `relations` objects.
4) Create you own complex content type like zope indexes, with number of
BTree structures (as attributes of this content type). These BTree
structures will hold a content data and forward and backward indexes of
varius relations between them and etc.
Note that in each of (1), (2), (3), may be, you will need to index relations
between the objects, so you are welcome to `zc.relation' package and its
complex docs. ((4) means that you build needed indexes within content type.)
Lets see an advatages for each way.
(1), I think, the best, when you going to use exist UI (z3c.contents,
rotterdam, boston), exist `copy - past - move' conceptions for persistent
objects, and exist traverse the objects to show a forms.
(2) Really, there aren't technical defferences between (1)
and (2.1) approaches. In (2.1) you just use your own fields instead of
__parent__ and etc. But note: (2) means that you are ready to build you own
traversing of objects, and, generally, all in URL's behavior will be your own.
(2.2) just more convenient to use it in zc.relation when you going to
store hundreds of thousands of content objects with big, complex
relations, not only simple nesting one another. and, my be, you whant to
be ready to move data storage in any moment.
I have used (2.1) and (2.2) because I not needed exist UI and travering
behavior in those my projects.
(3) When you need index many complex (and changable) relations, not only
nesting one another.
(4) Only if you sure that object structure / schema will not to be
modified in future and you use it for maximum optimization (i.e. your
content type is big complex `index'). In this case any future
refactoring of data structures will need database generations. In
summary it is just your own relation databse within ZODB :)
I have used each of these ways in different projects. (I have open source
only for (4): http://bazaar.launchpad.net/~astoon/ice.board/devel/annotate/head%3A/src/ice/board/persistent/board.py
but you not need this approach never)
I'm glad to hear about another concepts and principles of organize
nested content.
> I've pasted in a preliminary outline for my object structure
> below to give you an idea of what I'm trying to do. This is still very
> much a work in progress. My goal is to use a common module structure
> very similar to ASD S1000D, but be able to export the XML content
> transformed for ASD S1000D, ADL SCORM, MIL-DTL-24784 (Navy),
> MIL-STD-38784 (AF), or MIL-STD-40051 (Army), depending on each
> customer's requirements.
>
To implement ASD S1000D with export / import XML, you need exact (1)
way.
Map this to MIL-STD-40051 military standard and others looks like
adaptation, if I understand corectly. When you'll need to build
needed indexes (using value index, or zc.relation or etc) - you will add
them. But not think about this right now.
Yet another...
...I like idea of disassembly an engineering standards into entities and
assembly back not into verbalization but into zope interfaces - schemas.
Collect many standards in big library with interfaces and schemas
(not more). And build adapters between them. :)) I have insterests in system
engineering standards (like ISO-15288, ISO-15926 and etc.) But all these
ideas are very abstruse and unclear yet. Need many experiments, of course.
But in summary, we need experiments to map standards into interfaces.
> My primary need is to present a "simple" form for each data module to
> the author to enter his content, without worrying about XML tags.
> Perhaps a tabbed interface to simplify the presentation of the many
> different fields will help.
>
> My second need is, as the data modules are being created, presenting
> the ZODB objects in a browseable tree for selecting the data modules
> editing them or assembling them into documents. Something like:
>
> tmpub (object root for publication module)
> Cover Page (web page 1)
> Table of Contents (web page 2)
> Table of Figures (web page 3)
> Table of Tables (web page 4)
> Acronyms (web page 5)
> Chapter 1 Introduction
> Section 1.1 Scope
> tmdata DMC-xxxx (web page 6)
> Section 1.2 Purpose
> tmdata DMC-xxxx (web page 7)
> Section 1.3 How to Use This Document
> tmdata DMC-xxxx (web page 8 - also called by pressing
> F1 or Help from the menu)
> Chapter 2 Procedures
> Section 2.1 Startup
> Para 2.1.1 Tools
> tmdata DMC-xxxx (web page 9)
> Para 2.1.2 Checklist
> tmdata DMC-xxxx (web page 10)
> Section 2.2 Operation
> Para 2.2.1 Tools
> tmdata DMC-xxxx (web page 11)
> Para 2.2.2 Checklist
> tmdata DMC-xxxx (web page 12)
>
> I see websites with tree navigation in the left frame (like the Zope2
> Manager page), but I don't see a pluggable module or sample code
> anywhere explaining how to do this.
>
> My third need is to be able to export all of the completed content to
> CDROM in XML files suitable for the customer's interactive web
> application (on of the standards listed above).
>
> My fourth need is to create our own custom BlueBream/Zope web
> application (preferably launching from CDROM on a laptop using user's
> temp folder for persistent session info) to test the interactive
> content and possibly provide as a product for customers who do not
> have their own web application, or are happy with delivery in
> "contractor format".
>
I know about this approach using zope2 to buld that applications
launching from CDROM, yes. Have someone any expirience of usage BB for
this? I think it's OK.
> Finally, in the future I want to be able to expand this database
> structure to create an entire object tree where every product
> assembly/part is linked to its drawing objects, logistics data
> objects, tech manual objects, and training course objects. This is
> where I believe using the ZODB object oriented database will assist me
> better than a relational database like Access. So, I want to make sure
> the framework I set up now for the tech manuals doesn't constrain me
> from adding the other content in the future.
If you going to work with much more complex relations, it seems you need
use RDF/OWL for this. Personally I have interests at this point. So we
can consider some collaboration and partnership, may be.
>
> I would appreciate any advice you may have for the best/easiest way to
> approach this.
>
(1) as I said earlier.
+ zc.relation when you will need indexing (mostly, `backward' indexes).
> Thanks,
>
> Paul A. Harouff, P.E.
>
> ==================================
>
> PART 1: Author creates new dmodule object and fills in identAndStatusSection
> attributes. This provides required information to identify and reference the
> new object. This part has very little flexibility.
>
> tmdata (object root for data module)
>
> id (= "DMC-" + dmCode properly formatted with the required dashes
> for this example)
>
> type (= "dmodule" for this example)
>
> identAndStatusSection
> dmIdent
> dmCode
> modelIdentCode (2 - 14 chars)
> systemDiffCode (1 - 4 chars)
> systemCode (2 - 3 chars)
> subSystemCode (1 char)
> subSubSystemCode (1 char)
> assyCode (2 - 4 chars)
> disassyCode (2 chars)
> disassyCodeVariant (1 - 3 chars)
> infoCode (3 chars)
> infoCodeVariant (1 char)
> itemLocationCode (1 char)
> learnCode (3 chars - Optional)
> learnEventCode (1 char - required if learnCode is present)
> dmTitle
> techName (= nomenclature for assyCode/disassyCode)
> infoName (= nomenclature for infoCode)
> learnName (= nomenclature for learnCode)
> issueInfo
> issueNumber
> inWork
> issueDate
> year
> month
> day
> language
> countryIsoCode
> languageIsoCode
> dmStatus
> issueType
> security
> securityClassification
> commercialClassification
> caveat
> dataRestrictions
> restrictionInstructions
> dataDistribution
> exportControl
> exportRegistrationStmt
> dataHandling
> dataDestruction
> dataDisclosure
> restrictionInfo
> copyright
> copyrightPara
> policyStatement
> dataConds
> responsiblePartnerCompany
> enterpriseCode
> enterpriseName
> originator
> enterpriseCode
> enterpriseName
> applicCrossRefTableRef
> dmRef
> xlink:type
> xlink:actuate
> xlink:show
> xlink:href
> dmRefIdent
> dmCode
> modelIdentCode
> systemDiffCode
> systemCode
> subSystemCode
> subSubSystemCode
> assyCode
> disassyCode
> disassyCodeVariant
> infoCode
> infoCodeVariant
> itemLocationCode
> applic
> displayText
> SimplePara
> evaluate
> andOr
> assert
> applicPropertyIdent
> applicPropertyType
> applicPropertyValues
> andOr
> assert
> applicPropertyIdent
> applicPropertyType
> applicPropertyValues
> referencedApplicGroup
> applic
> id
> displayText
> simplePara
> evaluate
> andOr
> assert
> applicPropertyIdent
> applicPropertyType
> applicPropertyValues
> techStandard
> authorityInfoAndTp
> authorityInfo
> techPubBase
> authorityExceptions
> authorityNotes
> brexDmRef
> dmRef
> xlink:type
> xlink:actuate
> xlink:show
> xlink:href
> dmRefIdent
> dmCode
> modelIdentCode
> systemDiffCode
> systemCode
> subSystemCode
> subSubSystemCode
> assyCode
> disassyCode
> disassyCodeVariant
> infoCode
> infoCodeVariant
> itemLocationCode
> issueInfo
> issueNumber
> inWork
> qualityAssurance
> firstVerification
> verificationType
> systemBreakdownCode
> skillLevel
> skillLevelCode
> reasonForUpdate
> simplePara
>
> content
>
> PART 2: Author chooses the appropriate template for the content section.
> This part must be very flexible and dynamic to adapt to the author's needs.
>
>
> EXAMPLE CONTENT TEMPLATE FOR sysCode = x05, infoCode = 043
>
> maintPlanning
> timeLimitInfo
> timeLimitIdent
> applicRefId
> equipGroup
> equip
> name
> identNumber
> manufacturerCode
> partAndSerialNumber
> partNumber
> serialNumber
> reqQuantity
> unitOfMeasure
> timeLimit
> limitType
> limitUnitType
> threshold
> thresholdUnitOfMeasure
> thresholdValue
> tolerance
> toleranceLow
> tolderanceHigh
> timeLimit
> limitType
> limitUnitType
> threshold
> thresholdUnitOfMeasure
> thresholdValue
>
>
> EXAMPLE CONTENT TEMPLATE FOR sysCode = x00, infoCode = 131
>
> crew
> crewRefCard
> title
> crewDrill
> title
> subCrewDrill
> title
> crewDrillStep
> challengeAndResponse
> challenge
> para
> response
> para
> crewDrillStep
> challengeAndResponse
> challenge
> para
> response
> para
> subCrewDrill
> title
> crewDrillStep
> challengeAndResponse
> challenge
> para
> response
> para
> crewDrillStep
> challengeAndResponse
> challenge
> para
> response
> table
> tgroup
> colspec
> column
> colname
> colwidth
> colspec
> column
> colname
> colwidth
> thead
> row
> entry
> colname
> para
> tbody
> row
> entry
> colname
> para
> row
> entry
> colname
> para
> crewDrill
> title
> warning
> warningAndCautionPara
> if
> caseCond
> crewDrillStep
> crewProcedureName
> para
> elseif
> caseCond
> crewDrillStep
> crewProcedureName
> para
> if
> caseCond
> crewDrillStep
> crewProcedureName
> para
> crewDrill
> title
> crewDrillStep
> challengeAndResponse
> challenge
> para
> response
> para
> captionGroup
> cols
> applicRefId
> colspec
> colnum
> colname
> colwidth
> colspec
> colnum
> colname
> colwidth
> captionBody
> captionRow
> captionEntry
> colname
> caption
> color
> captionWidth
> captionLine
> captionEntry
> colname
> caption
> color
> captionWidth
> captionLine
> captionRow
> captionEntry
> colname
> caption
> color
> captionWidth
> captionLine
> captionEntry
> colname
> caption
> color
> captionWidth
> captionLine
> captionGroup
> cols
> applicRefId
> colspec
> colnum
> colname
> colwidth
> colspec
> colnum
> colname
> colwidth
> captionBody
> captionRow
> captionEntry
> colname
> caption
> color
> captionWidth
> captionLine
> captionEntry
> colname
> caption
> color
> captionWidth
> captionLine
> _______________________________________________
> bluebream mailing list
> bluebream at zope.org
> https://mail.zope.org/mailman/listinfo/bluebream
>
--
Ilshad R. Khabibullin
+7 922 600 56 06
More information about the bluebream
mailing list