>>But I don't understand how a db and FM interact. Is it
>>possible to
import a figure by reference into a FrameMaker
>>file from a database?
Can you point to a db directory the
>>way you would to a regular Windows
Explorer directory?
Unless I missed it, the answers I saw to this question don't seem to hit the
specific question -- can you have a Maker document open, put the IP somewhere
(or select an anchored frame), and import a graphic *by reference* from a
database? Especially important, I think, would be the notion that you don't
have to launch the database and exercise the queries for each image every time
you open the document. Likewise, if you're planning on an intranet or internet
database connection, you couldn't be in the position of transferring the image
over the wire every time you open the document.
The PDFs that discuss Maker/dB integration are good. But they seem geared
toward last-minute publishing of data that's in the dB. I don't think that's
what this question is about. Maybe I'm wrong, and the issue is already well
understood... Anyway, I see a few possibilities. Please set me straight on
any of these!
* Use your file system as a database, and just organize it really well. If you
store it on a web server that everybody in your intranet can access through
file commands, then you can make web pages that list the graphics. I did this
once for a quasi-doc management system, back in the mid-90's. I had a dir tree
where dir names indicated categories, until the final leaf folders were the
names of the books. Executing a dir command such as "dir
myLib\*\productA\features\specs\Japanese_Language_Support" returned a listing
of all feature specs for the Japanese Language support of productA. The
following command would return all documents for that feature, including
marketing docs, design docs, etc. -- "dir
myLib\*\productA\features\*\Japanese_Language_Support". You can wrap this up
in a web page, so queries aren't so hard to make. With such a system, you could
then get the explicit path to your explicit file, and you're good.
* Store the files in a shared file system, and track locations in the database.
I guess you can use tagging and other tricks to help identify the image records
-- do your queries until you find the image you want, then get the true-path
field from the record and use that. I'm sure you could wrap these actions in a
FrameScript or plug-in to some degree. I think actually browsing the images
would be important -- hopefully the dB offers that. If the dB includes a
suitable API, you could then call a plug-in process that performs the actual
import action in Maker.
* True dB File Access -- I think this is what the original question asked for.
I just don't know enough about how a dB stores things like graphics to answer
this. If the dB uses a file system to store the images, then you have a
variant of the above (assuming the tree isn't protected somehow). If not, I
don't know what to say. Maker needs to import the graphics every time you open
the file, so it would be a bit of work to trap that import request and
re-execute the query. And I don't know that it would even be desirable to do
so.
Just random thoughts, but that's how I would consider skinning this cat. Am I
overcomplicating the issue?
cud
_______________________________________________
You are currently subscribed to Framers as [email protected].
Send list messages to [email protected].
To unsubscribe send a blank email to
[email protected]
or visit
http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com
Send administrative questions to [email protected]. Visit
http://www.frameusers.com/ for more resources and info.
