UNDERSTOOD - Solution pending commit: Validation throwing "[Object] [Object]"

bggann

bggann

Active Member
I've got some text fields running php validation to strip leading and trailing spaces and to force capitalization.

It is 'php' validate
Code in "condition" is
return(TRUE);

Code to run is:
return (trim(strtoupper($data)));

Match or replace is set to "Replace"

When the issue happens, the field is filled with "[OBJECT] [OBJECT]" after validation runs in AJAX (without the quotes).

Any thoughts? This is intermittent - but appears on certain records. The fields are in repeated groups.
-bg
 
Can you point me at the form (which site, form name, element name), so I can check settings and create a test case locally.

-- hugh
 
I'd still like to understand this, but I've resolved the problem by implementing JavaScript at the element level.
On change I execute:
var value = this.get('value');
var uppercase=value.toUpperCase();
var trimmed=uppercase.trim();
this.update(trimmed);
 
cheesegrits said:
Can you point me at the form (which site, form name, element name), so I can check settings and create a test case locally.

-- hugh
Click to expand...
Look at the training site in my sites.
Add MMA Log under Add Aircraft Log.
In repeated group
Incident Name, Incident Number and Financial Code all did this.
I've replaced the code in Incident Name with the Java Script.

Note- this was happening on the live site, and only intermittently. Not sure it will happen on the training site.
- bob
 
It doesn't seem to be firing any AJAX validations for those fields. Is it using the JS workaround?

BTW, have you set your 'max_input_vars' up in your PHP ini? I can't remember if we've run across this as an issue before, but with a form with that many fields, in repeat groups, you are quite likely to run foul of the default max of 1000 inputs.

-- hugh
 
Did you notice if I republished the validation? I may have forgotten - was running out the door. I'll check when I get back to the office in 15 min

I'm not aware of any just work around unless you mean the one I posted here .it is not ussing that.

I have upped the max vars to 3000
 
On incident name yes, but not incident number or financial code.

I was just able to get it to fail on financial code.

The process was enter something in incident name, number and financial code on group repeat one . Then added a group. Tried the same feilds in group repeat 2. Noted that it did not fire validation there. When back to repeat 1 and changed financial code. 1st time I changed it I got stuff, stuff (weird) then changed it again and got object, object
 
OK, I've replicated and fix the [OBJECT][OBJECT] thing locally, but still working on the "validation doesn't fire when adding a new group" issue.

-- hugh
 
cheesegrits said:
OK, I've replicated and fix the [OBJECT][OBJECT] thing locally, but still working on the "validation doesn't fire when adding a new group"
issue.

-- hugh
Click to expand...

Was it something I did in the validation or is it a system problem?

I had a problem on another site where a calculation doesn't fire on second and subsequent records in a group but not validation. Wonder if they're related.

you'll see I'm one rev back on fabrik . I'm leery of updating the live site during Fire season, especially one this busy.
 
Both issues are in Fabrik itself. I should have fixes committed to github today some time.

Can you point me at the calc issue? I use calc's a lot in repeat groups, never had a problem with them not firing.

-- hugh
 
cheesegrits said:
Both issues are in Fabrik itself. I should have fixes committed to github today some time.

Can you point me at the calc issue? I use calc's a lot in repeat groups, never had a problem with them not firing.

-- hugh
Click to expand...
Great - thanks. I'm assuming you fixed the local code on the 'training' site. I'll need to know what to move to the live site to fix it there. I don't want to update the live site from Github right now (site is too busy).

your recommendation --> Should I use the fixed validate method or the java 'workaround' method. The Java seems to be working fine and seems faster, but I'm not as familiar with Java as PHP.

Regarding the non-firing calcs. I was wrong - it is the same site and we've chatted about it (I forgot).
See this thread.
http://fabrikar.com/forums/index.ph...g-on-2nd-and-subsequent-repeated-group.49185/
I've got Calc on load set for those fields to work around it. I can go turn that off and see if it re-appears.

-bob
 
Great - thanks. I'm assuming you fixed the local code on the 'training' site. I'll need to know what to move to the live site to fix it there. I don't want to update the live site from Github right now (site is too busy).
Click to expand...

Nope, haven't touched your site. I'm just working locally on my dev setup, and will commit the fixes to github when they are ready. Then it's up to you to update the site and test the fixes.

your recommendation --> Should I use the fixed validate method or the java 'workaround' method. The Java seems to be working fine and seems faster, but I'm not as familiar with Java as PHP.
Click to expand...

Entirely up to you. Yes, JS will always be quicker, as it's all happening in the browser, it doesn't have to make an AJAX call to the server, which then has to load the entire J! and Fabrik frameworks and return a response to the browser.

One Of These Days I'm going to add some built in JS based validation, but for now if you want that, you have to roll your own.

-- hugh
 
cheesegrits said:
Nope, haven't touched your site. I'm just working locally on my dev setup, and will commit the fixes to github when they are ready. Then it's up to you to update the site and test the fixes.



Entirely up to you. Yes, JS will always be quicker, as it's all happening in the browser, it doesn't have to make an AJAX call to the server, which then has to load the entire J! and Fabrik frameworks and return a response to the browser.

One Of These Days I'm going to add some built in JS based validation, but for now if you want that, you have to roll your own.

-- hugh
Click to expand...
Duh - I knew that (that you made the changes locally) I just forgot that I knew it.

I'll probably stick with Java on this - at least for the number and code fields. I like the snappiness. For the name field, I may move it beck to php since I need to run other validations on it anyway.

Thanks!
- bob
 
For the name field, I may move it beck to php since I need to run other validations on it anyway.
Click to expand...

OK - then let's not consider this one SOLVED yet, until I've finished with the bug fixes and committed them.

-- hugh
 
I've changed the subject to reflect that this is understood, but solution is pending. I'll watch for your commits to understand what you did.
- bob
 
You must log in or register to reply here.

Useful links

  • Create a Fabrik Account (Downloads)
  • Create a Forum Account
  • Fabrik Wiki
  • Fabrik 4 Changelog /Install /Upgrade
    • We are in need of some funding.
    More details.

    Thank you.

    Members online

    No members online now.
    Total: 113 (members: 0, guests: 113)
    Back
    Top