Zope3 use FTP as an example to introduce the mapping of object to file system

The Zope default provides an FTP service, a file-based protocol. This immediately triggers a way to represent the object to the file system and reverse the mapping. In order to complete the mapping in a flexible and replaceable way, a series of interfaces can be implemented as adapters to provide a representation that the FTP Publisher understands. This chapter shows how to implement some interfaces for a custom file system representation.

One thing you might be confused about: "Why do we have to write our own filesystem support?" Does Zope not provide some implementations by default? "Well, the answer to the latter question is: neither can nor." There is an adapter that registers IContainer with Ireaddirectory and iwritedirectory. However, they are not very useful because our message book and message objects are not only containers but also contain content that cannot be displayed anywhere. Just start Zope 3 and test yourself. Creating an expression so that you can handle both the inclusion and the content at the same time is the goal of this chapter.

Since the core already has a lot of code that provides icontainer as a directory implementation, we should reuse this part of the framework. The contents of the object can be represented simply by the contents of the virtual file invocation, which contains all the relevant data in plain text. Also note that we do not need a mapping between the finished object and the file system representation, for example we do not need to make annotation visible. I suggest that the contents of the message thin object simply contain the data describing the attribute, and I propose that the message be expressed in the following format:

1&http://www.aliyun.com/zixun/aggregation/37954.html ">NBSP; Title: <message title>
2
3 <message body>

In this way we can easily analyze the title when new content is submitted, because we want to implement the read-write interface that the file system represents. One of the main goals is to keep the generality of the Virtualcontentsfile class as much as possible so that we can use it in the message book and the message. To do this, the virtual file must send a request to create a plain text representation to the component in order to understand the individual Content object attributes. For this task, we will use a simple IPlainText adapter to provide a plain text representation of the content of each content component.

Step I: Plain text adapters

As mentioned above, the IPlainText adapter is a plain text representation of the content of the object returned and accepted and ethically do the right thing with the data. They are very simple objects with two methods, one for providing text and the other for handling text.

(a) interface

Interface is simple, it defines a getText () method and a SetText () method

#!python
Class IPlainText (Interface):
"" "This interface allows your to represent an object's content in plain
Text. ""

Def getText ():
"" "Get a pure text representation of the object ' s content." "

def setText (text):
"" "Write the text to the object." "

This interface replaces the module interface of the message board. The "content" of the object that is spoken in doc strings is more appropriate. What I'm talking about is all the data (attribute values) that can be represented in plain text representations.

The SetText () method can be quite complex in theory depending on how many attributes you have to map and how you want to represent them. But in our two examples you can see that it is still quite simple.