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

label of the field

Meena25

Is there a way to fetch the label of a field in the tpl?

Thanks.

Find more posts tagged with

Comments

kaalraa

Is there a way to fetch the label of a field in the tpl?

Thanks.

Is there a way to fetch as what TS version you are using and on what platform?

Meena25

I am using TS 6.7.2.
Platform : Windows XP.

gzevin

Is there a way to fetch as what TS version you are using and on what platform?

was that SO important to know? Once you know the version, go for the answer ...

ISCBorisB

Is there a way to fetch the label of a field in the tpl?

Thanks.

Not without some coding. PT parses DCRs and DCRs retain only Values, not Labels.

You can for example get your Label in FormAPI onSave and populate DCRs' hidden Item, etc.
Alternatively you may find/parse corresponding DCT from your presentation template but the first
option is IMO much easier to implement

gzevin

Not without some coding. PT parses DCRs and DCRs retain only Values, not Labels.

You can for example get your Label in FormAPI onSave and populate DCRs' hidden Item, etc.
Alternatively you may find/parse corresponding DCT from your presentation template but the first
option is IMO much easier to implement

I myself would go for the second option. Maybe because I don't like formAPI as such (probably because I coded too much in it at one point Smiley Happy

). But seriously, architecturally the second option looks clearer to me.

ISCBorisB

But seriously, architecturally the second option looks clearer to me.

I agree, formally It looks clearer to me as well.

One unpleasant complication of this approach is an 'inline' though. Imagine that you want a Label of the selected Entry from the Drop-Down List generated by the inline.
Granted, you can recognize the fact on parsing and re-run inline yourself from the PT. If however corresponding inline script uses run-time Environment we are doomed

gzevin

I agree, formally It looks clearer to me as well.

One unpleasant complication of this approach is an 'inline' though. Imagine that you want a selected drop-down Entry label that has been
generated by an inline. Granted, you can recognize the fact on parsing and re-run inline yourself from the PT. If however corresponding
inline script uses run-time Environment you are doomed

true. especially for me, I like inlines for DCTs Smiley Happy

However, all could be tied to a specific implementation. E.g., if I use, say, .ipl's to produce DCTs, the same IPLs could produce a non-runtime DCT that will be suitable for parsing purposes (or, even better, write up a hash table that will have XPATH of elements as keys and corresponding labels as values).

ISCBorisB

true. especially for me, I like inlines for DCTs However, all could be tied to a specific implementation. E.g., if I use, say, .ipl's to produce DCTs, the same IPLs could produce a non-runtime DCT that will be suitable for parsing purposes (or, even better, write up a hash table that will have XPATH of elements as keys and corresponding labels as values).

Agree again - we are on the same Page!

Let me play Devil's advocate though. It's easy to come up with the scenario where this non-runtime persistent Component of
yours should be tied to the DCR, not DCT (User-dependent processing, and the like). That's the problem, within the inline
DCR is never known, it may not even exist yet. That is certainly a poor Design but then a Design where you need a Label in the
PT IS a poor Design to begin with! Smiley Happy

gzevin

Agree again - we are on the same Page!

Let me play Devil's advocate though. It's easy to come up with the scenario where this non-runtime persistent Component of
yours should be tied to the DCR, not DCT (User-dependent processing, and the like). That's the problem, within the inline
DCR is never known, it may not even exist yet. That is certainly a poor Design but then a Design where you need a Label in the
PT IS a poor Design to begin with!

well, let me also agree with you (however we could propably work out how to safeguard the logic, if we lay out the whole solution) and we close this conversation, as you truly pointed out that the whole requirement is a bit dubious to start with!