I can't reference a field using the subcontext from the ticket

Honestly, I hardly understand anything in your description. Would you explain in more detail, what you want to achieve, please? Puzzled ...

Further guidance:

• Always include exact versions/revisions of installed Trac and Trac plugin.
• Provide detailed guidance, how to reproduce issues. Provide all relevant custom ticket/wiki content (private/sensitive information stripped - of course).
• Mark tickets (type|priority|severity) appropriately. Especially ask yourself, if/how your issue justifies the rating given to the report, and don't give high ranks at will. Or worst: to possibly catch more attention, because this could yield to adverse results. Developers (me too) are often open-minded, but could react badly, if ask for more than they are willing to give.
• AFAIK there's no claim for making a duplicate of a form field, nowhere, not in the same form (strictly forbidden) nor in another form (impossible, at least yet), if this is what you want to do.
• Ticket system here is not for install/configuration support, but dedicated to software development. Ask questions at the th-users mailing list, please.

I wonder how, in the "wiki formatting", to repeat any one field. Example: [tf.textarea:''10 1 comment18] => now i need to use it again, but how to reuse it?

Sorry, my english is not so good.

Replying to hasienda:

Honestly, I hardly understand anything in your description. Would you explain in more detail, what you want to achieve, please? Puzzled ... Further guidance: * Always include exact versions/revisions of installed Trac and Trac plugin. * Provide detailed guidance, how to reproduce issues. Provide all relevant custom ticket/wiki content (private/sensitive information stripped - of course). * Mark tickets (type|priority|severity) appropriately. Especially ask yourself, if/how your issue justifies the rating given to the report, and don't give high ranks at will. Or worst: to possibly catch more attention, because this could yield to adverse results. Developers (me too) are often open-minded, but could react badly, if ask for more than they are willing to give. * AFAIK there's no claim for making a duplicate of a form field, nowhere, not in the same form (strictly forbidden) nor in another form (impossible, at least yet), if this is what you want to do. * Ticket system here is not for install/configuration support, but dedicated to software development. Ask questions at the th-users mailing list, please.

Remaking my question: I'm currently using Trac 0.12.2, with TracForms? 0.4.1 and TracIncludeMacro? 2.1. What I can not do, is to reference a field from another form. I mean, if I include (using include macro) 2 forms with the same subcontext (#! subcontext 1 for example), I can reference a field from the first form, in the second, just by putting [tf.value:fieldname], instead of [tf.value:1:fieldname] (subcontext:variable)· But this way, when I update one form, the information from the other gets erased. I've tried setting different subcontexts in each (#! subcontext 1 in the first, and 2 in the second), but when I try to get the value from the first form in the second, with [tf.value:1:fieldname] it doesn't get any value.

Replying to cobratec:

Remaking my question:

Thank you.

I'm currently using
* Trac 0.12.2, with
* TracForms? 0.4.1 and
* TracIncludeMacro? 2.1.

Ok, that's clear now (slightly re-formatted).

What I can not do, is to reference a field from another form. I mean, if I include (using include macro) 2 forms with the same subcontext (#! subcontext 1 for example), I can reference a field from the first form, in the second, just by putting [tf.value:fieldname], instead of [tf.value:1:fieldname] (subcontext:variable)· But this way, when I update one form, the information from the other gets erased.

Yes exactly. This is as it is by design. TracFormsPlugin uses

• parent resource realm (i.e. ticket or wiki plus
• resource ID (following previous examples ticket number or wiki page name respectively) plus
• optional(!) subcontext

to build and later reference a unique form ID. So it's technically possible (done so myself for testing) to build two forms with same subcontext (hint: no context on both would essentially be the same subcontext too) within the same parent resource. Current TracFormsPlugin doesn't complain about the duplication an full or partial overlap of fields. Both will be populated independently. Because you can't press commit button on both at the same time, again there is no conflict. Only the 'duplicated' field values get overwritten as often as you save one of both forms.

You can't achieve a reference across different parent resources, i.e. to display values of Form 1 in wiki/SandBox1 in Form 2 in wiki/SandBox2, simple because there is currently no syntax to refer to a form ID. It's always calculated dynamically, or a new form ID is created, if no previously saved data is found for a given parent resource + subcontext combination. Simply put: Currently you can only input and re-get value for a given field name inside the same or identically defined form inside the same parent resource.

I've tried setting different subcontexts in each (#! subcontext 1 in the first, and 2 in the second), but when I try to get the value from the first form in the second, with [tf.value:1:fieldname] it doesn't get any value.

Well, expected. If you follow my previous explanation, you'll already know yourself, that you just created two different forms here, right? :-)

You may still want to tell me, why you want/need that cross-reference to work. How should this work, i.e. how will TracFormsPlugin know what's the original, what's the copied form (field), if only one should be allowed to receive and commit updated values? Please give a full example workflow here to make your expectations clear. I can still only guess by now: Is it right, that you need some kind of a read-only field copy, or do you require concurrent input/re-display of same information in different parent resources/different subcontexts? Why?

What I'm needing is a little to customized for Trac, I guess... I'll try to explain my needs, if you do not undestand just ask and I'll try to make it better explained.

I got a form, for users to submit, but it has 5 sections, and I made each section a wiki page. That way I got /wiki/section1, /wiki/section2 ... to /wiki/section 5. Then in each ticket, I used the Include macro [[Include(section1)]] [[Include(section2)]]...[[Include(section5)]] in the new ticket default description."

As example of a section, let's say:

{{{ 
#!TracForm
|| Module || Type  || Language || To be done || [[BR]]
||[tf.textarea:comment8 '' 20 1]||[tf.textarea:comment18 '' 10 1]||[tf.textarea:comment28 '' 15 1]||[tf.textarea:comment38 '' 20 1]||[[BR]]
.
.
.
}}}

And then in another section, I would like to get the value of this section, it can be read-only, since I really need the same value in both...
Also, I've looked at DynamicFieldsPlugin, and I was hoping it could be used inside TracForms?. To make it clear, lets say I have some value fields, but I need the sum and multiplication of then to be made dinamically into another field! I don't know if this is possible, and also don't know if it's the tool for doing it, but that's what I need now.. I don't know python, but just playing around I've done the op_mul function to multiply the way I want. (using as example your op_sum function!)

Replying to cobratec:

What I'm needing is a little to customized for Trac, I guess... I'll try to explain my needs, if you do not undestand just ask and I'll try to make it better explained.

Sure.

I got a form, for users to submit, but it has 5 sections, and I made each section a wiki page. That way I got /wiki/section1, /wiki/section2 ... to /wiki/section 5. Then in each ticket, I used the Include macro [[Include(section1)]] [[Include(section2)]]...[[Include(section5)]] in the new ticket default description."

Ok. Including one wiki page with 5 different forms would work too:

{{{ 
#!TracForm
#!subcontext section1

... field definitions ...

}}}
{{{ 
#!TracForm
#!subcontext section2

... field definitions ...

}}}
...
{{{ 
#!TracForm
#!subcontext section5

... field definitions ...

}}}

at least, if you always want them in a fixed order. If you'll need to re-arrange or only use sub-sets of these sections, then the multiple-wiki-page approach is a must.

As example of a section, let's say: ...

Ah, some real-world code, most appreciated.

If I think calculation, I don't use textarea but plain input fields ([tf.input:fieldname]). Apart from that, it's ok.

And then in another section, I would like to get the value of this section, it can be read-only, since I really need the same value in both...

Sorry, repeating once again, this is currently impossible. You can't clone/refer/re-display a field of another form. Because there is no guarantee on the from ID (ID is assigned in a first-come-first-served manner, you know.?), there would even be no easy way to refer to the field before first form value commit. It could be made working with a generic ref like [tf.input:subcontext:section1:fieldname], but I just made this up, nothing that works right now.

Also, I've looked at DynamicFieldsPlugin, and I was hoping it could be used inside TracForms.

No, it doesn't know anything about TracForms, nor would I suggest to change that. This is an entirely different subject. DynFields is about Trac (true) ticket fields defined in Trac core, including custom ticket fields defined in section [ticket-custom]. No connection to TracForms, as this plugin supplies an additional document realm, much like ticket and wiki, but always as a child resource, so actually attachment realm is the most appropriate parallel.

To make it clear, lets say I have some value fields, but I need the sum and multiplication of then to be made dinamically into another field! I don't know if this is possible, and also don't know if it's the tool for doing it, but that's what I need now..

Inside the same form, yes. Outside, no. You might want to look at WikiFormsPlugin, dunno, if you could do it with that plugin. But the downside is, it seems unmaintained AFAIK.

I don't know python, but just playing around I've done the op_mul function to multiply the way I want. (using as example your op_sum function!)

I see, this could make a nice enhancement. Actually I've been thinking about how to accomplish arbitrary calculations, not just sums and differences. But this is unfinished either.

Due to limitations, I have changed the way I was doing it, but I still need some functions to achieve my goal.
I got all the forms together, that way, when a new ticked is made, it has included only one wiki page: [[Include(Form)]]
The issues:

• The form in the wiki page has about 330 fields (a lot, right? I know...);
• It's a 10 step workflow, and some fields have to be blocked or unblocked depending on the step it is. (It is an adaptation of a Excel spreadsheet, but it has to be online, and available for all users);

Maybe you can help me in some way to do that. Any hints on how to achieve this. And I will probably need the dynamic fields thing to work with tracforms. Where should I start?
Also, I'm using postgresql, is there a limit of form fields?

Replying to cobratec:

Due to limitations, I have changed the way I was doing it, but I still need some functions to achieve my goal.

Any more detailed specifications, because despite our conversation here it's not clear to me right away.

I got all the forms together, that way, when a new ticked is made, it has included only one wiki page: [[Include(Form)]]

Ok, obviously you followed my hint to possible simplification of the form template.

The issues:
* The form in the wiki page has about 330 fields (a lot, right? I know...);

No limitation here, but interesting to know some working real-world application numbers.

* It's a 10 step workflow, and some fields have to be blocked or unblocked depending on the step it is. (It is an adaptation of a Excel spreadsheet, but it has to be online, and available for all users);

I see, but if you like to have instant reactions on user input without explicit form submission, you'd need to go for (yet non-existent) ajax support (that is JavaScript based background interactivity between client and server). While it's really nice, i.e. the side-by-side wiki editor has it, this is not an easy task. In Trac 0.13 that mechanism would even have to compete with Trac core interaction, because ticket editor will have it's auto-updated preview too, similar to the wiki editor today. This could yield some nasty interference.

Maybe you can help me in some way to do that. Any hints on how to achieve this.

Sure? Dunno. My 2 ct are already thrown in above.

And I will probably need the dynamic fields thing to work with tracforms. Where should I start?

Not sure, if your read my comment on DynFields thoroughly enough, because I already mentioned there, that it has a totally different focus. Any dynamic behavior required for TracForms would have to be coded into the forms itself. This implies, that the regular user of such (test) forms should normally not have access neither to the ticket description code nor to the template code for possibly looking behind the form or even tempering with it.

Also, I'm using postgresql, is there a limit of form fields?

Why should this impose a limitation? AFAIK PostgreSQL is one of the most powerful RDBS engines. We had to struggle to allow full compatibility with that db backend in the past, but not due to limitations in PostgreSQL but due to weak plugin code. PostgreSQL has a tendency to uncover shortcomings in Trac plugins, not only this one. Should be really fine, if you can handle the db administration itself.

Hmm, I see... And I have seen your comment about DynFields, I'm just saying that I need it, even if I have to do it another way, or code it myself. Can I e-mail you with more detailed specifications and details?

Replying to cobratec:

Hmm, I see... And I have seen your comment about DynFields,

Ok ,just curious

I'm just saying that I need it, even if I have to do it another way, or code it myself. Can I e-mail you with more detailed specifications and details?

Sure, right-away. But I tend to fulfill even the most specialized demand in the most general way possible, so the probability for broader interest is maximized. Let's see, if we can get an acceptable solution for you and break it down to some potentially re-usable pieces in the same run.

I sent the e-mail on the address at your wiki page! If you did not receive it, post here so I can send again.

(In [11132]) TracFormsPlugin: Add some more useful arguments for input fields, refs #9640.

Some private discussion led to this, because especially the TITLE attribute is very useful when rendered as tooltip by many web browsers per default.

(In [11283]) TracFormsPlugin: Add optional write protection to input fields, refs #3264, #5353, #8715 and #9640.

A new keyword argument '-mode', for now exclusive to tf.input and tf.textarea, with value to choose from the following list:

• ro - input blocked, like static text, but in non-editable form field
• rd - same as 'ro', but don't display stored value but default instead
• rw - regular input behavior at all times (default)
• once - initially 'rw', but blocked ('ro') after first form submission

It's an optional argument, retaining full backwards-compatibility with existing field definitions by choosing -mode=rw as implicit default.

This forked a rather extensive private coaching for a private development, very custom development.

For now this ticket will remain and may serve as an inspiration further on, eventually even help to fulfill the initially requested feature somehow.