Invoking template without having the templates physically in the WA

TS 6.7.1 SP2 Win 2003

I have a question. This might sound stupid but is really a food for thought. Can one place the datacapture.cfg completly out side the teamSite store and use some means, some way to make the tempalting engine read this datacapture file and renader the TeamSite form? I want to completly bypass the use of "New Form Entry" and want to have the datacapture as a part of iw-home and not the store.

This is not for any customer or a project. This question is just a product of my curiosity.

Find more posts tagged with

Comments

iw_store

TS 6.7.1 SP2 Win 2003

I have a question. This might sound stupid but is really a food for thought. Can one place the datacapture.cfg completly out side the teamSite store and use some means, some way to make the tempalting engine read this datacapture file and renader the TeamSite form? I want to completly bypass the use of "New Form Entry" and want to have the datacapture as a part of iw-home and not the store.

This is not for any customer or a project. This question is just a product of my curiosity.

I feel this is not possible, lets wait for experts. As the templating engine is defined to look all its assets in a defined location.

Adam Stoller

TS 6.7.1 SP2 Win 2003

I have a question. This might sound stupid but is really a food for thought. Can one place the datacapture.cfg completly out side the teamSite store and use some means, some way to make the tempalting engine read this datacapture file and renader the TeamSite form? I want to completly bypass the use of "New Form Entry" and want to have the datacapture as a part of iw-home and not the store.

This is not for any customer or a project. This question is just a product of my curiosity.

Yes and no.
You would have to have a DCT within the store/branch/workarea - but that DCT could consist [almost] entirely of an inline statement that essentially included the contents of a file that lives inside iw-home as opposed to inside store/branch/workarea - and you'd still have to utilize New Form Entry to create / edit DCRs through the FormsPublisher GUI.

Note: Having DCTs within store/branch/workarea is generally "good" because you can version the DCT code.

Note: If your intent is to bypass the FormsPublisher GUI - then you're basically out to implement your own custom interface for templating and you could probably do anything you wanted - but then the investment in the software to begin with seems a bit questionable.

Note: If your intent is to create DCRs programmatically rather than through user interaction (like translating news-feeds into DCRs perhaps) - then you can pretty much do so without ever having to use New Form Entry - but if you ever want to edit those DCRs you'll need the DCT to be within the store/branch/workarea - even if it's just an over-glorified include of the DCT XML from some file outside of the store/branch/workarea.

In short - you can do some of what you asked about, but I think the effort is questionable from start to finish.

Doc1.doc

nipper

A normal best practice is to have the DCT (and TPL) as stubs in the local workarea and use inline (for DCT) and iw_include (for TPL) to reference another location.

I usually put them in iw-home/custom/project/[inline|iw-include]. The files are placed on my config branch and pushed to iw-home through workflow.

HTH

Andy

Ambuj

TS 6.7.1 SP2 Win 2003

I have a question. This might sound stupid but is really a food for thought. Can one place the datacapture.cfg completly out side the teamSite store and use some means, some way to make the tempalting engine read this datacapture file and renader the TeamSite form? I want to completly bypass the use of "New Form Entry" and want to have the datacapture as a part of iw-home and not the store.

This is not for any customer or a project. This question is just a product of my curiosity.

Bypassing "New Form Entry" for creating new DCRs are very much possible but for this you will have to put your datacapture.cfg in specific branch/workarea....

You can generate a sample DCR n then you can use perl/javascript/OSPs to create DCRs without using "New Form Entry"...

It again depends on the kind of requirement you have....

Cheers,
Ambuj :-)

FunctionalDesignSpecs_report_v1_E-1.pdf

Frederik

A normal best practice is to have the DCT (and TPL) as stubs in the local workarea and use inline (for DCT) and iw_include (for TPL) to reference another location.

If I'm correctly informed, it's impossible to use a chain/nesting of < inline>, meaning that the dct that you pull in via that stub/inline, can not itself contain < inline>.

So using your approach, you can not use < inline> for its typical use, like loading select options from somewhere else...

Isn't that a serious bummer?

nipper

I do not know about that. I use a bunch of Perl to build up the remainder of the DCT dynamically. so that is not an issue for me.

ISCBorisB

If I'm correctly informed, it's impossible to use a chain/nesting of < inline>, meaning that the dct that you pull in via that stub/inline, can not itself contain < inline>.

So using your approach, you can not use < inline> for its typical use, like loading select options from somewhere else...

Isn't that a serious bummer?

It is not that serious, not really. You are correct in your basic assumption, DCT Parser uses one time pass to build DC Form.
So, if inline-generated fragment contains nested inline Tag that latter one won't be evaluated.

It is not that hard however to build "inline-wrapper" that starts with some parameter root inline and then recursively executes
nested inlines if any. You would have to remove nested <substitution> Tags (or code inlines with "bare Format" switch) and
detect/report endless combinations like a-b-c...b... but that's again trivial.

We use (slightly less ambitious) inline wrappers to abstract shared DCT fragments into DCT Libraries