Inline edit does not update calc fields

[p38]

Ok, thanks, your last post was a bit misunderstood, I had interpreted it as a work in progress, and not actually fixed.

I will update from GIT and test.

Paul.

 

[cheesegrits]

Regarding the timing of the fix. From Nov 28th is only 7 working days, which is not entirely unreasonable for solving a corner case issue on some "work in progress" code, and it looks like we resolved the original issue from this thread within 5 working days.

Looking at your site, your list.js doesn't seem to have the fixes from Fri 7th, when Rob posted that he thought he'd fixed the remaining issues you raised the day before that.

Can you update your code, and let us know if the issue is resolved by this commit:

https://github.com/Fabrik/fabrik/commit/2564c7de2773ad92b7e89b4efb562ebb26d3b108

-- hugh

 

[p38]

Had some old problems after GIT update, but deleted all browser cache and all looks OK.

I will do some stress tests and see how it pans out.

many thanks,

Paul

 

[p38]

Guys, what is going on?

This was fixed a while ago, now after GIT update, it has stopped working.

It works in IE9, but nothing in FF and chrome?

Also, in IE9, it is extremely slooow, and the dialog box has ALL items highlighted.

I cannot work like this, one step forward, 2 steps back.

Paul.

 

[p38]

Thanks to troester, it looks like this has solved the problem.

http://fabrikar.com/forums/showthread.php?p=160306

Now we just need to find the fix.

Paul.

 

[p38]

Sorry guys, just 4 days later, the latest update from GITHUB has now broken this fix, the inline calc is not updating anymore.

Please fix asap.

bump

Paul

 

[rob]

Inline edit calculations seem to work fine for me in my test case. Can you point us at the url please?

 

[p38]

http://golfscore.co.za/index.php/my-menu/tournament-scores

login with demo p/w demo1234

I had to roll back to yesterday GIThub which works OK. Something changed between yesterdays update and todays update.

I have now just updated latest git for you to test.

Paul

 

[troester]

Your site is working in FF, IE9, IE8 for me.

Maybe you have to clear browser cache?

 

[p38]

Yup, first thing I do after each update.

You probably still have the update from 2nd Jan, which works correctly.

As mentioned, the inline calc refresh was working with the git update from 2nd Jan, but not from 3rd jan. I have not tried todays update.

It is not working in ANY browser.

bump

Thanks,

Paul.

 

[troester]

I've used your link.
Just tested again (IE9): editing Xnd round gross is updating Xnd round nett, total gross, total net.

Edit: also in IE8 and Chrome

 

[rob]

Works for me as well. I update a score and then the total updates fine. Tested on ie 8 & 9 and firefox

 

[p38]

Thanks guys, I think I have found your and my problem.

Please try now and you will see it does not work, as I made the handicap -10, which gives an INTERNAL SERVER ERROR.

The reason is if any record has a failed calculation, it will not do the calculation update of ANY other record.

here is my calcualtion code, I cannot see any reason why a -10 handicap value should fail the calc.

if ({scores___1st_round_gross} > 0)
{
$round1 = {scores___1st_round_gross}-{scores___handicap};
}
else $round1 = 0;


return $round1;

Paul

 

[troester]

I don't know if this is the reason here but you should always use placeholders with quotes to prevent php errors if element is empty.

if ((int)'{scores___1st_round_gross}' > 0)...

 

[p38]

Thank you, this did the trick.

Perhaps Rob can change the calc, so that if it should get a calc error, it will only error on the current record, not the whole list of all records, as in my case?

To summarize, if the calc update should encounter an error, it should not stop working for ALL other valid list record calcs.

Paul.

 

[cheesegrits]

We already take steps to catch errors in user supplied custom code, and where possible we toss a Joomla notice up, saying there was an error, and just carry on regardless.

The problem is, we can only catch warnings and notices, we can't catch fatal errors, because PHP doesn't let you. A fatal error is fatal, and (according to most accepted logic in programming theory) should not be "catchable", it should immediately terminate the running code. The point being that once a fatal error has happened, no code running in that same thread from then on can make any assumptions about the integrity of the system or any the data, so should not run.

So for fatal errors, the whole PHP script, i.e. the page load you are running as part of, just dies right there, and the only thing PHP attempts to do is write out the 500 error msg to the log.

So we never get the opportunity to catch that error, ignore it, and go on to the next row.

Hence needing to be very careful to make your calc code bullet proof, including that (int)'{foo}' placeholder thing, to avoid syntax errors.

-- hugh

 

[p38]

Point taken.

perhaps a note in the hint to that effect, eg: "Please ensure your code integrity is correct, as no error checking is done on your code".

Also, there seems to be a discrepancy regarding the syntax usage of placeholders as most places in the hints of fabrik that are supplied show {table___element} without the apostophe's.

eg (from calc hint):
return {listname___elementname_raw} * 5;

So I was basing my syntax around this.

I will be using apostrophes from now on.

Many thanks

Paul

 

[cheesegrits]

Well, I don't see any need to put that warning everywhere you can enter PHP code. I dunno, just seems obvious to me. If your code has errors in it, it'll blow up. That's kinda like putting a warning on a car saying bad things might happen if you drive it into a tree.

Agreed about the examples in the hints, that's something I'm gradually changing as I come across them.

-- hugh

 

[rob]

That's kinda like putting a warning on a car saying bad things might happen if you drive it into a tree.

Hey what? No one ever told me that was a bad idea. I always aim for them especially after 10 pints, mind by that time I keep missing them