nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Build DCT, based on data model

jackvinson

Please forgive me, if I am asking this in the wrong place.

A consultant has suggested that we store our metadata model in a database and actually build the DCT/DCR "dynamically" by reading from the database and building all the input fields when a user begins creating a new DCR. The purpose for this would be to enable more flexibility for adding/changing input data without having to create new DCT's. In their model, making changes to the metadata library in the database is going to be easier than modifying the DCT. (This point can be argued, of course.)

My question: Is it possible to create nearly all the input areas / controls on a DCT, completely based on information that Interwoven would read as it opens the DCT? Are there example or other writing that describes how one might do this? What language should I be using to describe this?

More details / user flow
1. User starts new DCR
2. User selects Content Type (metadata tags are tied to the content type; content type is also in the database)
3. system draws controls for tags that are tied to this content type
4. user enters data
5. user saves DCR
6. data is saved to database during the publish process

Regards,

Jack Vinson @ Allstate
Knowledge Management Systems Analyst

Find more posts tagged with

Comments

Dwayne

While what you're describing is certainly do-able in theory, I think there are some practical concerns.

Leaving aside the performance question,

1. What about older DCRs? If you change the data in the database that defines the structure of your DCT, then the old DCRs will no longer be readable, unless you're always extending, rather than modifying, the structure

2. What about the presentation templates? Will they be dynamica built as well, to reflect the changes to your DCT?

--

Current project: TS 5.5.2/6.1 W2K

brandon1

3. system draws controls for tags that are tied to this content type

Does this mean that you want to have the code (html) to build the item in the DB as well?

Current Project: Content Services implementation

jbonifaci

I'm assuming your metadata fields are just a series of selects? Now, do you have multiple content types in your dcr, or is each content type a different dcr?

If each content type is a different dcrs, you could accomplish what you want fairly easily with inlines and/or formapi on load of the dct.

If you have a radio button or select box in your dct that determines what content type the dcr will be, you will need to do have an onItemChange item handler that will trigger a function to populate your metadata fields based on the content type the user selected. Your function will need to perform an IWDatacapture.callServer to a script that will build the list of appropriate values for each metadata field and pass them back to the dct and populate your metadata fields via formapi.

These are all fairly basic concepts of templating/formapi and should be easy to accomplish. If you get into this and have any sepecific questions, please post them in the TeamSite FormsPublisher (Templating) forum, as they will be more appropriately addressed in there.

Good luck,
Jeff Bonifaci

brandon1

To provide another alternative.. You might want to also investigate Content Services. This would allow you more control over how the GUI side works. Heck, even just use teamsite as a repository and scrap templating all together.

Current Project: Content Services implementation

brandon1

Here is an even scarier thought... Get jbonifaci to do it. He might sit down the street or down the hall from you if you are in Northbrook.

Current Project: Content Services implementation

Adam Stoller

It sounds to me like you need to do a bit more design specification / requirements gathering to make sure you understand what you're really trying to achieve.

As stated - it doesn't sound to me like you have much need for TeamSite / TeamSite Templating as you seem to be trying to create an interface to manage a DB system rather than a content management system.

I'd suggest you start with the finished product (web pages?) and work your way backwards to figure out how those pages get constructued and back from there to figure out the design of your input gathering process - and then start working forward in terms of how you would handle the details of implementation - and then start the actual implementation.

Right now it sounds like you have a bit of the cart-before-the-horse kind of idea of what you're doing and are being led in a particular direction by a consultant who may or may not have any real understanding of Interwoven products.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

jackvinson

Thanks all for your comments. I may hook up with jbonifaci, but even he thinks you guys collectively know much more than he can tell me. However, he might be able to help me begin using the right words.

This is, in general, part of a much larger project. I was asking this specific question because the consultant recommended that we try it. If it doesn't work, we will go with building DCT's the way our current team already knows how to build them. The goal with this concept is to enable greater flexibility over the long haul without having to create separate DCT's when developing content types. [I've coming to the opinion that this is too complicated for the value it provides.]

Let me reply to a few specific questions / comments:

Dwayne: Older DCRs. The intention would be to leave the data/field definitions would remain in the library (reference table in the db), so that an "old" DCR could always be re-opened, based on the information in this reference table.

Dwayne: Presentation will be dynamics - essentially coming out of the database where content is pushed. Current model has no direct creation of web pages from the Interwoven publish process.

Brandon: Drawing controls dynamically. We don't know how to do this (thus my question). We'd need to store enough information in the metadata library to define the label, the type of control (text, select, multiselect, radio, etc), values associated with selects, data validation and anything else appropriate for the control.

jbonifaci: Selects/Multiselects. We'd need to define where each control would find data to populate a select or multi select list.

jbonifaci: The claim was that we could have one DCT that first asked which content type you want and then read the data library, based on that selection to display the input controls. Maybe this is really done without a DCT at all? This is essentially what Brandon said.

Ghoti: And Ghoti is also right in that we essentially are describing an interface to a database. There were business claims that we need to use Interwoven for content management because it is already a standard for creation and approval. Please don't tell me that this is backwards.

What the team really wants to know is "Can it be done?" (apparently, yes) and more importantly, can someone point us to examples of it working?

Again, thank you for your comments already.

Regards,

Jack Vinson

brandon1

As an ex-Allstater who worked with TeamSite, I fully understand this statement:

There were business claims that we need to use Interwoven for content management because it is already a standard for creation and approval.

But what you are trying to do sounds like it would be easier and cheaper to build ASP.NET,JSP pages to update the database. And if workflow is needed use Teamsite to perform the approval/deployment process. This could be accomplished via command line /cgi integration with 5.5.2 or using command structure provided with the UI tookit. The key to your success is going to be a good Architect with both an understanding of what Teamsite can and can not do as well as proficiency with your choosen language from above (ASP.NET/JSP, etc)

Current Project: Content Services implementation

Adam Stoller

Ghoti: And Ghoti is also right in that we essentially are describing an interface to a database. There were business claims that we need to use Interwoven for content management because it is already a standard for creation and approval. Please don't tell me that this is backwards.

Well - from the sound of it you are NOT using TeamSite for content management - you're using it only as a vehicle for providing a UI to DB management. It isn't clear whether you are (or care about) versioning the DCRs you will be creating in TeamSite or whether you are just using them to reflect the current state and/or change the state of data in your DB - which is then also being used by your web server to generate the pages on the fly dynamically - yes? (or did I miss or misunderstand something?)

It's kind of like buying a plasma TV and a DVD player but no cable, dish or antenna - and you have to wait until a TV show's series is over so you could buy the "series" DVD and watch it - i.e. you could probably do what you're asking - but I'm far from convinced that it makes any sense and that you'll probably waste far more time trying to get all this to work than it's really worth.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com