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; } } }

Alternative for inline tag

Vishakha

We require including values from a file in the DCT. Is there any other method other than inline? Since in our last project our experience was that using too many inline calls makes the dcr load slowly. We alerady have around 40 fields in the dcr and almost 15 of them would be inline fields.
Has anyone tried out any other approach and suggest it?
Also is there a way to write a common file of some fields(items) and then include it in the datacapture.cfg?

Find more posts tagged with

Comments

moonkhanna

If you elaborate your exact requirement, there may be a workarround

Pawan

We require including values from a file in the DCT. Is there any other method other than inline? Since in our last project our experience was that using too many inline calls makes the dcr load slowly. We alerady have around 40 fields in the dcr and almost 15 of them would be inline fields.
Has anyone tried out any other approach and suggest it?
Also is there a way to write a common file of some fields(items) and then include it in the datacapture.cfg?

I understand your main goal is to load the dcr faster, so, you need to do know some facts such as how many inlines are fetching data from files/database and the number of values populated inside the fields.
Try removing the fields with large data in it or inlines with database calls to figure out whether it helps in loading faster.
Try to load the same dcr in IE as well as Firefox.

ISCBorisB

We require including values from a file in the DCT. Is there any other method other than inline? Since in our last project our experience was that using too many inline calls makes the dcr load slowly. We alerady have around 40 fields in the dcr and almost 15 of them would be inline fields.
Has anyone tried out any other approach and suggest it?
Also is there a way to write a common file of some fields(items) and then include it in the datacapture.cfg?

There are several techniques to deal with *expensive* inlines. For example:

1. Cache output. That works if there is a *cheap* way to check if underlying data has been modified since the last inline call.
If that's the case your inline may cache ready-to-go substitution and use this cache instead of full processing. Depending
on inline Data Source, Cache rebuild may or may not be inline script responsibility, could be some other process, template
based generation, etc

2. Use standard XML Entities. External entities seem to be easiest to use in your case.

nipper

It really depends on what causes the 15 inlines to be slow. There are 2 possibilities, the start of a new shell to run iwperl and the script is not trivial, but IMHO, that should not make a significant increase in DCR load time, or that each inline takes a couple seconds (say to query a DB) and in total it is unacceptable.

As a test put all of your inline code into 1 large script (do not just run iwperl on each) and see how long it takes to run.

If that is acceptable, you can make the DCT one large inline. I do that often. More likely you will need to figure out how to cache like Bo suggested.

Mr_Cruise

The answer really depends on how dynamic the data is that you have to load using an inline. I am guessing that the inline retrieve some sort of data and this is where your real issue lies. Caching Perl modules can help but the then increases complexity and thus risk of failure.

In this sort of situation I prefer to pre-generate the xml that each inline includes, with a separate script. This way you can set different a different frequency update on each inline data. All you need to do is create a cron job that invokes the creation of the xml files.

Hope this helps

Lee

Valentine

You can also use form api to accomplish. The DCT would load faster, but formapi would be still populating the fields Smiley Happy

ISCBorisB

You can also use form api to accomplish. The DCT would load faster, but formapi would be still populating the fields

Valentine's Post is a good illustration of the peculiar misconception about DCT <inline> Tag and it's role, I've seen that before.

DCT's inline is an instrument to modify DCT (a template!) upon rendition. FormAPI is an instrument to provide GUI, dynamic Data Capture and
modify DCT Form Values, not a template itself. There is a small cross-section between the two like for example conditional drop-down population and the like.
Still, if DCT inlines are used correctly FormAPI can not provide an easy alternative.

nipper

DCT's inline is an instrument to modify DCT (a template!) upon rendition. FormAPI is an instrument to provide GUI, dynamic Data Capture and
modify DCT Form Values, not a template itself. There is a small cross-section between the two like for example conditional drop-down population and the like.
Still, if DCT inlines are used correctly FormAPI can not provide an easy alternative.

Making matters worse, this suggestion (which would likely require 15 call servers) and would certainly be significantly slower than the current implementation. The idea was to increase performance.

Valentine

Making matters worse, this suggestion (which would likely require 15 call servers) and would certainly be significantly slower than the current implementation. The idea was to increase performance.

That would be true if you are going to do 15 calls. You can always craft the
query, and do 1 call, get all data in JSON/XML format.

kvargas23

I basically setup some Perl code in my inline call outs to save the output of my lines to files and keep them "in cache" I'd be happy to send you the code if you send me a private message.

Keith

ISCBorisB

You can always craft the query...

Do you mean that in general Client-Side Java Script processing plus at least one (and quite possibly more) Client/Server round trips with
asynchronous calls will make an overall process more efficient?

Like Build Form => Render Form => JSP-Call Server => Parse JSON/XML => Call Back is somehow more efficient than Build Form => Render Form?
Oh btw, what should happen if DCR is opened in the View mode?

Tim__D

Do you mean that in general Client-Side Java Script processing plus at least one (and quite possibly more) Client/Server round trips with
asynchronous calls will make an overall process more efficient?

Like Build Form => Render Form => JSP-Call Server => Parse JSON/XML => Call Back is somehow more efficient than Build Form => Render Form?
Oh btw, what should happen if DCR is opened in the View mode?

In a dct I'm working on right now in fact I have two inlines that can occur in 18 different locations within my DCT. With verbose logging turned on I can see that IWOV is actually executing the things 18 separate times. Now, these scripts are fast, under a second each but when you add 2 x 18 seconds it put the rendering time at about 30-36 seconds. Remove the inlines and the thing loads in seconds.

A callServer on the other hand for both would in theory only take about 5 seconds. The problem is, in order to pre-populate the selected options like an inline command on a large DCT takes trawling through it and doing a lot of searching, matching creating options objects etc.. which is expensive and could hang the form for a bit until its done So, I'm on the fence. In my case the calllServer would be faster than an inline to get my data as objects the way IWOV has executed inlines but setting all the pre-selected values after doing a callServer()etc would surely be quite painful. I still have to make up my mind about how to handle this one.

nipper

In a dct I'm working on right now in fact I have two inlines that can occur in 18 different locations within my DCT. With verbose logging turned on I can see that IWOV is actually executing the things 18 separate times. Now, these scripts are fast, under a second each but when you add 2 x 18 seconds it put the rendering time at about 30-36 seconds. Remove the inlines and the thing loads in seconds.

A callServer on the other hand for both would in theory only take about 5 seconds. The problem is, in order to pre-populate the selected options like an inline command on a large DCT takes trawling through it and doing a lot of searching, matching creating options objects etc.. which is expensive and could hang the form for a bit until its done So, I'm on the fence. In my case the calllServer would be faster than an inline to get my data as objects the way IWOV has executed inlines but setting all the pre-selected values after doing a callServer()etc would surely be quite painful. I still have to make up my mind about how to handle this one.

Neither is a good solution. Make the whole DCT an inline and have it generate the complete XML. The the 18 different inlines are a variable or a PM call. *much* faster.

Tim__D

Neither is a good solution. Make the whole DCT an inline and have it generate the complete XML. The the 18 different inlines are a variable or a PM call. *much* faster.

Interesting concept. Are there techniques that you use to make your PM generated DCT's easy to update?

nipper

Interesting concept. Are there techniques that you use to make your PM generated DCT's easy to update?

Yea, it is a script so it can be changed easily and make decisions on its own.

Email me offline and I can send you my GearUp preso from a couple years ago, this was a large part of the plan.