Core Content Only

Archive for August, 2008

There are at least two possibilities for increasing metadata field sizes. The request most often heard inquires about increasing the default memo field size (which is originally 255 characters). The second avenue is to increase the size for a single one-off metadata field.

Expanding Default Memo Field Size

We can use a configuration variable within Content Server named "MemoFieldSize" to increase the default size of new memo fields beyond the original limit of 255 characters. Keep in mind this affects memo fields that you create AFTER you add this configuration and restart content server. For fields that have already been created you will also need to go into the database and directly increase the column size for that individual metadata field within the DocMeata table.

If you operate in a database with UTF8 encoding you should keep in mind that this can affect that actual number of characters your users will be able to input. Oracle has a 4000 byte per column limit for varchar2/nvarchar2 data types. Hence, if you set the column to the 4,000 byte maximum and each character takes 3 bytes of space you get roughly 1,333 characters to work with.

So, what to do where, when and how. Log into your content server with administrative privileges and select Admin Server from the Administration menu. Click the button for the instance you will be working with and then select General Configuration from the left hand menu.  Add this configuration setting:

MemoFieldSize=1024

as a new line in the variables list and click save.  Restart.  Similarly you could go directly to the file system and add this configuration setting to the config.cfg file.  Oh, and don't forget to get out your favorite database manipulation device and increase those columns sizes!

Expanding a Single Field

Great, right, so that's all nice and what not but I don't want to increase ALL my memo fields. I only want to increase the size of a single field. Well sure you do, who wouldn't? In this case you can again use config.cfg or go through the admin server to add a configuration setting something like this:

xMyMetadatafield:maxLength=1024

or whatever your new field size is meant to be.  Again, change the table definition in the database and restart your content server.

Notes:

1. Increasing field sizes also more than likely will increase indexing and searching time.  More stuff equals more time.  Pretty simple, but a reminder of that fact is relevant.
2. I performed these actions on a 10gR3 content server and 11g database with existing content. The field widening did NOT erase my data. Obviously if I were to restrict down the field size instead of widen the field my data would have been truncated.

Sometimes you have a Content ID and need to find the path to the Vault file.  If you are in a JSP (Java Server Page) or in a Java Class in your backend component you can use this method.  10gR3 introduces the FileStoreProvider component that is not necessarily compatible with this method.  I'll try to conjure up a FileStoreProvider compatible version in the future, someday.  If you already have one and want to share please drop me a note!  This is not without issue I suppose but it should get you started:

private String findLatestVaultPath(String strContentID) throws DataException{ 	// Setup a value to return 	String strPath = null;

 	// Setup a binder to perform our lookup with 	DataBinder dbDocInfo = new DataBinder(); 	dbDocInfo.putLocal("dDocName", strContentID);

 	// Grab latest id by name 	ResultSet rsLatestByName =      m_workspace.createResultSet("QlatestIDByName", dbDocInfo);

 	// If we didn't get any results we are returning null 	if(rsLatestByName != null && rsLatestByName.isRowPresent()) 	{ 		// Get out the id 		String strID =        rsLatestByName.getStringValue(ResultSetUtils.getIndexMustExist(rsLatestByName, "dID"));

 		// If we don't have an id we're returning null 		if(strID != null && strID.length() != 0)     { 			// Put the id in our binder 			dbDocInfo.putLocal("dID", strID);

 			// Look up the DOC_INFO 			ResultSet rsDocInfo = m_workspace.createResultSet("QdocInfo", dbDocInfo); 			DataResultSet drsDocInfo = new DataResultSet(); 			drsDocInfo.copy(rsDocInfo); 			dbDocInfo.addResultSet("DOC_INFO", drsDocInfo);

  		  // Finally, compute the path 			strPath = DirectoryLocator.computeVaultPath(DirectoryLocator.computeVaultFileName(dbDocInfo), dbDocInfo); 		} 	} 	return strPath;}

The other day I was trying to execute a search against content server in some JSP's (Java Server Page) and I wanted to perform a multi column sort, similar to how the old Multi-Sort component used to work. The content server in question was configured for DATABASE.FULLTEXT. Turns out, this is simple to perform. When you form your URL or binder (Local Data?) you need a variable named SortSpec and it should start with "order by" and follow the basic rules of a database query.

Example:

SortSpec=order by dDocType asc, dDocName desc

Another example:

http://yourserver/instance/idcplg?<original query>&SortSpec=order%20by%20dDocType%20desc,%20dDocName%20asc

Perhaps the context is Site Studio. Perhaps the context is a JSP (Java Server Page) checked into Content Server. Regardless, you will eventually begin to wonder "What is this ServerBean thing?" and "What can I do with it?" I often get asked about the existence of documentation on ServerBean, and it has recently been pointed out to me that this is covered in Bex Huff's book The Definitive Guide to Stellent Content Server Development (which is pretty darn good, so get it if you don't have it).

That said, there is some information I can present here about the ServerBean class starting with the signatures of the public methods. I've sprinkled sparse notes among the methods that may or may not be of use. The simplest description of ServerBean is a shortcut class for performing actions like manipulating the local data, executing services, reading enviornment variables and executing IdocScript.

class ServerBean{   // Constructor   // NOTE: A single, no argument constructor is supplied and you    // must use the init method to initialize   ServerBean()

   // After the constructor you must initialize with this method   void init(ServletRequest servletrequest)

   // Remaining Methods ////////////////////////////////////////////

   void addOptionList(String s, Vector v)   void addResultSet(String s, ServerResultSet serverresultset)

   // Remaining methods in alphabetical order   String evalIdcScp(String s) throws ContentServerException

   // If the flag is true it means you have already wrapped the String    // in <$> offsets   String evalIdcScp(String s, boolean flag)throws ContentServerException   String evalResInc(String s) throws ContentServerException

   // This is the long hand version of evalIdcScp, just use    // evalIdcScp to save some processing   String evaluateIdocScript(String s)throws ContentServerException   String evaluateResourceInclude(String s) throws ContentServerException   void executeService()throws ContentServerException   Object getCachedObject(String s)   ServerResultSet getCurrentActiveResultSet()   Properties getEnvironment()   String getEnvironmentValue(String s)   String getLocal(String s)   Properties getLocalData()   Vector getOptionList(String s)   Enumeration getOptionLists()   ServerResultSet getResultSet(String s)   Enumeration getResultSetList()   void parseExecuteService(String s) throws ContentServerException   void parseExecuteService(String s, char c, char c1)throws ContentServerException   void putLocal(String s, String s1)   void removeLocal(String s)   ServerResultSet removeResultSet(String s)   void setCachedObject(String s, Object obj)   void setEnvironment(Properties p)   void setEnvironmentValue(String s, String s1)   void setLocalData(Properties p)}

If you have not had a chance to check out the latest iteration of the Web Content Management offering from Oracle you are missing out. From a development point of view this is the most flexible version yet, and from the developer perspective it is certainly the most full of promise. There are at least three features of this release that can via for a compelling reason to upgrade.

Some of you may have heard of the new Ephox based editor. That is pretty neat, but I going to side step that and save it for another post. No, the more compelling storyline and the first of the three most interesting points is the part that wraps the editor. Very nearly everything but the Site Studio Designer is now web based (or more importantly component based). This means we can create components and override/enhance almost anything. Should we? I guess that depends on your level of daring-do. This also means you could swap out Ephox if you didn't like it for something like FCK Editor.

The second feature I find most interesting is the new data file structure. This is a major leap forward towards true content reusability. Data files can now be used in more than one place on the site. Even if the regions are named differently. In fact, if you wanted you could use the same data file in multiple content regions on the same page.

Finally, one of the big improvements I like most as a developer is really tied to one of the latest Core updates for content server which adds JSON support. Many of you already knew that you can use IsJava=1, or IsSoap=1 in the url to get the underlying data stream for the page to display in various (HDA/XML) formats. Now you can get that data in JSON format as well. This can make AJAX integration with content server simpler and perhaps less expensive. Somewhat tied to this is the new console window. When you are in contributor mode sometime try pressing CTRL-ALT-SHIFT-C all at once and check out the window that pops up. Some nifty stuff in there.