The ".dcr" file extension

Hi,

I can't remember exactly why I think it is a "bad idea" to name your DCRs with ".dcr" extensions, but something in the back of my mind is warning me against doing it-- or any extension, for that matter.

I'm at a situation right now, however, where it would be really handy to have a bunch of DCRs named with a ".dcr" extension.

I'm on Solaris 8 with TS 5.5.2, and I seem to recall something about conflicting file extensions with some popular windows program.

Has anyone with my environment had success/problems with file extensions on their DCRs??

Thanks in advance,
Tom

Find more posts tagged with

Comments

iwovGraduate

In the past I have used ".iwdcr" to avoid conflicts with other programs such as Shockwave.

DCR Delphi Component Resource
DCR Kodak Digital Camera Raw Image File (Kodak)
DCR RIF Picture
DCR Shockwave File

Hope that helps.

laj1

I myself don't see any of those file types ever living in ant of my */templatedata/data directories, and since TS knows what to do with the DCRs based on their extended attributes, the extension is just for us people. So you can use any extension or no extension. I prefer using an extension, and I prefer .dcr because I don't want to type .iwdcr, but .iwdcr would be a nice second choice if .dcr was taken off the table.

Len.

Len Jaffe
My Heart Is A Flower
Update your DevNet profile - let us know who you are!

Adam Stoller

I last saw the problem with .dcr as an extension on Solaris when using TeamSite 4.x - from that point on I made it a point not to use .dcr as an extension - but I do know customers who have been doing so without any problem (so whatever I saw that one time might either have been a fluke, or a bug that was later fixed). I tend to use .xml as an extension for DCRs because that's what they are - XML files...

--fish
(Interwoven Senior Technical Consultant)

Johnny

Interesting point... but there a plenty of other files around teamsite that are xml

.cfg .tpl etc etc

I have been using .dcr without any problems for a while. It would be good to hear what are some of the possible issues we could have.

I have used it to keep authors in the mindset.

When they see .dcr they know exactly what the file is.
Its quite common for authors to be confused between generated pages and dcr's.

John Cuiuli
Consultant
Sydney, Australia

Migrateduser

I think that if your TPLs are XML you are just creating problems for yourself - use "loose" presentation templates (there is an article on this somewhere). I also have wondered why Interwoven uses .cfg instead of .xml, especially since some .cfg files (like iw.cfg) are more like .ini files than XML. Time for a new TLA (Three Letter Acronym)?

I personally don't use any extension for DCRs - users are familiar with tools adding extensions for them. And since I have workflows that generate output files that match the DCR name (such as record generates record.xml) I don't want extensions on the DCRs (which would generate record.xml.xml from record.xml). I think I may even have FormAPI that prevents them from entering a period. The exception is when I collect metadata on a binary file or directory - then the DCR just has the same name as the binary file or directory. This could be a problem if users navigated into templatedata and edited files there, but if you have users navigating templatedata through the share (not the browser, which always brings up the DCT) to edit files you probably already have many problems (unless they are pretty well trained - DCRs have special encoding rules that XML editors may not know about, but if they are well trained they should be smart enough to right-click on the file and choose TextPad or XMLSpy regardless of what the extension on the file is).

In fact I say again the existence of templatedata is the problem; I feel it should be a persistent object database instead of a filesystem (but then I guess you couldn't edit DCRs with XMLSpy without some custom solution). So I guess I should add .iwdcr to every DCR and change workflow to trim this off before generation.