This topic describes the inputs for the Portal Document Manager Access builder.
- General inputs
- Document Type Selection
- Search Criteria
- Content Handling
Table 1. General inputs
|Name ||Enter a name for this builder call. The WebSphere® Portlet Factory Designer displays this name in the builder call list.|
To differentiate multiple Portal Document Manager Access builders in your model, include in the name the type that you are working with. For example, documents stored in the Document Manager are of type CollaborativeDocument; therefore, use CollaborativeDocument as a value for this input.
Document Type Selection
Table 2. Document Type Selection inputs
|Search for Document Types||Click this button to populate the chooser in the Document Type input with document types and document containers registered with the Content Model. Examples of document containers include Folder and DocumentLibrary. An example of a document type is CollaborativeDocument. By default, the button queries the Content Model for all types that descend from Document and Folder. |
If you receive an error or the Document Type picklist contains no data after you click this button, check the following conditions:
- Ensure that you have a server configuration correctly configured for your project and that your project has been published.
- Check for mistakes in your server configuration for your WebSphere Portlet Factory project. For example, check the server name and port.
- Ensure the portal server is running and that you can log into the portal manually.
- If you recently restarted the portal server, try loading the main login page of IBM® WebSphere Portal server. Content Model service calls may not be initialized until the login page is requested at least once after the server restarts.
|Document Type||After you click Search for Document Types to populate the chooser for this input, click the chooser and use the picklist field to select a document type or document container type to work with. For example, if you select CollaborativeDocument, you can query and operate only on documents stored under Document Manager control. If you select Folder, you can operate on folders under Document Manager control.|
|Enable Schema Caching||A schema is created during model regeneration that is specific to the content type selected in the Document Type input. This is done by querying the Content Model for type properties. If the metadata of this content type is static, you can enable schema caching to improve regeneration performance for the builder.|
This section allows you refine what data is retrieved from the Content Model. By default, search criteria values are entered by the user at runtime and retrieved from a variable. However, you can use this section to override all or some of the search criteria.
Table 3. Search Criteria inputs
|Search Paths||The Content Model and underlying JCR implementation can be thought of as a tree structure. All document containers and documents in the Content Model are addressable by a path. This input lets you limit the scope of the documents to work with to only certain paths in the tree. |
For example, to search only the default document library that is installed with WebSphere Portal Version 6, enter /contentRoot/icm:libraries.
Tip: To find the paths to all Document Libraries configured on the WebSphere Portal server, run the sample model FindAllDocLibs.model.
|Search Depth||Specify the extent of the search. |
If this input is not overridden here and is not set in the buildernameSearchCriteria variable at runtime, the default value is Search only direct children of a path.
The following choices are available for this field.
- Search only direct children of a path causes the Content Model to return only the children of the given path. For example, documents in subfolders of a document library are not returned.
- Search all descendants of a path causes the direct children and all descendants are returned. For example, documents in subfolders of a document library are also returned.
|Search Type||Specify the rules to be used in the search. |
If this input is not overridden here and is not set in the buildernameSearchCriteria variable at runtime, the default value is Perform a web-style text search.
Select one of the following options.
Match All Documents
Finds all documents in the specified paths that match the value in Document Type field.Perform a web-style text search
Perform a SQL-style text search
Enables two additional fields, Search String
and Search Property
. Web-style allows you to enter a search string for the Search String
field. The search string can be combined with the following symbols:
+ (plus character)
The results must contain the term. For example, search results for +foo must contain the term foo.- (minus character)
The results must not contain the term. For example, -foo search results must not contain the term foo.^ (caret character)
The result must contain the term, but is not sufficient by itself. For example, ^foo search results must contain the term foo but not only the term foo."" (double quotes surrounding the term)
The results must contain the term within the double quotes. For example, "WebSphere Portal".
For example, the following query means the results must contain spain
, must not contain italy
, and must contain france
, but not only france
With this choice, you can optionally limit the search to a single document property. For example, if your Search Type is CollaborativeDocument, you can select the title
property. This limits the search to just the title field of CollaborativeDocuments. If you do not enter a value for Search Property
, all fields will be searched.
Note: Search Property
is required for SQL-style search, described below.
Enables two additional fields, Search String
. This choice lets you use SQL syntax for the search string in the Search String
When you use the SQL-style search, the Search Property
field is required. The Content Model does not allow you to perform an SQL query across all properties. If you do not enter a search property, you receive an error when you run the application.
The Content Model supports the %
(percent) wild card for SQL-style searches. The following are examples of the query syntax:
- apple – Property selected exactly matches apple
- %apple% – Property contains apple
- apple% – Property starts with apple
- %apple – Property ends with apple
The search term is matched exactly as specified. The search string must be in the format of the underlying content repository. This may mean dates, users, or other types might need to be converted to the proper format before the call.
|Refresh Search Properties||If Web-Style or SQL-Style is selected for the Search Type input, this button queries the Content Model for all properties of the type selected in the Document Type field and automatically populates the Search Property picklist field. You can select a property from the picklist to search on.|
|Search Property||This field is available when Web-style or SQL-style is selected in the Search Type input. After you click the Refresh Search Properties button (described above), this picklist field lets you select a single property to search on. This field is optional for web-style searches; if no property is selected, all fields are searched. This field is required for SQL-style searches; if no property is selected, you receive an error in your application. See the description for the Search Type field above for additional information.|
|Search String||This field is available when Web-style or SQL-style is selected in the Search Type input. You can specify a search string. The syntax for the search string depends on the choice you selected for the Search Type input. See the description for the Search Type input for additional information.|
|Max Documents||Specify the maximum number of search results to retrieve from the Content Model.|
Table 4. Content Handling inputs
|Search Results Content Handling||Typically search results contain only metadata about documents found from the query; binary data is not retrieved until the user selects a result. The following choices are available:|
Omit from XML
Embed in XML
Omits the actual binary document content (for example, an image or PDF file) from the search results.
Note: You can use the downloadDocumentContent LJO method to stream the binary contents to the browser.
Embeds in the search results data from the binary content of the document, for example, HTML or XML. Use the Character Set Selection field to specify the character set to use in decoding the content.Custom (Fire A Decode Event)
Delegates handling of the binary data to a custom method. This lets you customize the data transformation.
|Detail Content Handling||Specify how to handle content when the document detail is retrieved. This input provides the same choices as Search Results Content Handling. If Embed in XML is chosen, use the Character Set Selection field to specify the character set to use in decoding the content.|
Typically you can select Omit from XML and instead stream the binary content to the browser with the downloadDocumentContent LJO method.
|File Upload Tag||If you use the File Upload builder to upload a file, enter the page tag name used for the File Upload builder.|
|Character Set Selection||Specify the character set to use in decoding the actual document content. |
If Embed in XML or Custom (Fire A Decode Event) is selected for Search Results Content Handling or Detail Content Handling, this input is available.
Select one of the following options.
Use the Mime type declared by the document
Use an explicit character set
Instructs the builder to get the character set information from the declared MIME type of the document. The format expected is
For example,text/plain charset=us-ascii
Enables an additional input field, Character Set for Decoding.
|Character Set for Decoding||Enter a specific character set. The character set is used to decode content in the search results, for example, UTF-8 or US-ASCII. |
This input is available only if Use an explicit character set is selected for the Character Set Selection input.
Table 5. Advanced inputs
|Base Document Types||Filters the document types available in the Document Type input to the usable Content Model types and their descendants. Because all document and document container types extend from Document and Folder, generally ignore this input and use the default values.|
Parent topic: Portal Document Manager Access builder