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

changing the size of a readonly field

rabs

I wondering if anyone can help.
Here is my scenario,

I have written a script which generates DCR's based on items returned from a database query.

The items returned from the database are written into readonly fields in the dcrs i.e. the dataapture.cfg file has a tag for every field which is populated on the dcr.

I need to increase the size of a couple of the fields on the dcr, while still keeping it readonly.

any ideas?

Find more posts tagged with

Comments

Adam Stoller

I wondering if anyone can help.
Here is my scenario,

I have written a script which generates DCR's based on items returned from a database query.

The items returned from the database are written into readonly fields in the dcrs i.e. the dataapture.cfg file has a tag for every field which is populated on the dcr.

I need to increase the size of a couple of the fields on the dcr, while still keeping it readonly.

any ideas?

Are you specifying that the fields are readonly in the DCT or setting them to readonly via FormAPI?

The former I believe does not render such fields in an intelligent manner. The latter has a better chance of doing things "right".

If you're dealing with textareas and are trying to dynamically alter the number of rows or columns associated with that textarea - I'm not sure whether this can be done - but chance are you'd have to use "raw" javascript code to do so.

rabs

I am specifying the fields are readonly in the dct.

The only reason I need to increase the size of the field is because the user needs to see the contents of the readonly field without scrolling.

Adam Stoller

I am specifying the fields are readonly in the dct.

The only reason I need to increase the size of the field is because the user needs to see the contents of the readonly field without scrolling.

As I stated before - you'll probably be better off setting the fields as read-only via FormAPI on form initialization - but if you're dealing with arbitrarilly large chunks of data that might not fit within the number of rows you provided for when you defined the textarea you'll have to look at also playing with javascript code to see if you can dynamically alter the row attribute (and somehow figure out how to calculate the number of rows required based on the size of the content) - good luck. It sounds like an interesting but likely to be frustrating project...

RonaldV

Can Iwov pick this up in the next release and create a proper option for defining readonly-fields that look and behave as expected? :-)

Setting field readonly via FormApi is way to much effort and error-prone.

Cheers, Ronald

Adam Stoller

Setting field readonly via FormApi is way to much effort and error-prone.

Well, that's your opinion I guess - I don't find it that much effort or error-prone - I consider it a standard part of the FormsPublisher development process and excessive in neither the effort or the error departments.

RonaldV

Hey, compare this:

[HTML][/HTML]

to your average formapi tasks:
- create a js-file and create a "setReadOnly"-function in it (which is not a 1 line thing because you want/need to test whether the passed field-name really exists)
- include the js-file in your dct
- call your js-function for every readonly field
- add event-handlers when the your readonly-field is part of a replicant (for every field again)
- and then hope your js-code does not break somewhere along the line which would expose your readonly field to user-input.

and tell me which is more complex and error-prone.

Adam Stoller

Hey, compare this:

[HTML][/HTML]

to your average formapi tasks:
- create a js-file and create a "setReadOnly"-function in it (which is not a 1 line thing because you want/need to test whether the passed field-name really exists)
- include the js-file in your dct
- call your js-function for every readonly field
- add event-handlers when the your readonly-field is part of a replicant (for every field again)
- and then hope your js-code does not break somewhere along the line which would expose your readonly field to user-input.

and tell me which is more complex and error-prone.

I won't argue that it doesn't take more lines of code - of course it does - but it provides much more flexibility and control on the part of the developer instead of relying on the vendor to make it work "right" in all situations.
Once you've done this a few times, it's easy to use existing working examples to base new code on, and even to put the function into a library so that you can use it multiple places - once you've done that - it should no longer be very complex or error-prone to use.

However - yes, based on your comparison of a one-time-only-use example - the FormAPI method is more complex and error-prone.

RonaldV

In that case you're better of writing your own cms from scratch. :-)