Showing internal ID in form

[Bauer]

Per this thread in 2.0 forum http://fabrikar.com/forums/showthread.php?t=24434 - I changed an internal ID to a "field" type (integer 6) because I want the ID to show in a form (though disabled).

However I found that when this was done, the auto-increment value for added records was lost. (The new id is zero)

Can something be done to allow an internal ID to be show in a form?

 

[cheesegrits]

Hmmm, I know we used to have code that prevented the autoinc from getting lost, I'll have to test to see if it survived the 2.x to 3.x migration.

Meanwhile, you can recover your autoinc number by executing ...

ALTER TABLE your_table AUTO_INCREMENT = 100;

... in yoru MySQL console of choice (i.e. phpMyAdmin), obviously replacing the table name, and the number (your current highest PK val + 1).

-- hugh

 

[cheesegrits]

Hmmm, I know we used to have code that prevented the autoinc from getting lost, I'll have to test to see if it survived the 2.x to 3.x migration.

Meanwhile, you can recover your autoinc number by executing ...

ALTER TABLE your_table AUTO_INCREMENT = 100;

... in yoru MySQL console of choice (i.e. phpMyAdmin), obviously replacing the table name, and the number (your current highest PK val + 1).

-- hugh

 

[cheesegrits]

Unless of course that field is no longer set as autoinc, which may be the case. In which case editing and saving the List one time should (I think) reinstate as the primary key with auto-inc. Then you can reset the autoinc value by hand.

Anyway, I'm testing the element type change now.

-- hugh

 

[Bauer]

I'm pretty familiar with phpMyAdmin and MySQL in general. I appreciate you looking into it.

In the meantime I got around this by creating another integer field "thisid" and used Eval to fill it with the internal id. A half-assed workaround - but I do what it takes.

 

[troester]

In fabrik2 you could say "Cancel" if asked to change the database column but the fabrik element was changed from internalid to field.

In fabrik3 you first must set your list to "Alter existing fields"=no, then you can modify the id to field/integer (+ editable=nobody)

 

[Bauer]

In fabrik2 you could say "Cancel" if asked to change the database column but the fabrik element was changed from internalid to field.

In fabrik3 you first must set your list to "Alter existing fields"=no, then you can modify the id to field/integer (+ editable=nobody)

Grrr. Whatever. Now I'm starting to get cranky again.
My "fix" didn't work. I can't get Eval to replace the element I created with the current internal id.

And your fix means if I want to change other elements in the List a week from now I have to remember that I changed the "Alter existing tables" setting to "No".

Would it be too much to ask that internal ids are displayed (and of course set to read-only by default)? It's just a matter of changing the directive from "hidden" to "readonly". It makes no sense to me - as the id can be displayed in the List. If you don't want users to see the internal id you can always configure the view for both the List and Form via the "Access" settings.

If this is something that seems to be too much of a "demand" - can someone point me to the code where it is being set to "hidden" and I will change it myself (and add it to my list of personal tweaks I must "fix" on my own every time I update from GitHub).

 

[troester]

I think the easiest way is to add a calc element, ajaxcalc=yes

$a='{your-table___id_raw}';

if ($a=='{your-table___id_raw}') return '';//in new records the placeholder is showing placeholder name itself
return '{your-table___id_raw}';

Default eval is only executed in a new record.

And your fix means if I want to change other elements in the List a week from now I have to remember that I changed the "Alter existing tables" setting to "No".

You could reset it immediatly.

 

[Bauer]

I'll get back to you on using the Calc -
I know Eval is only executed on a new record - and that's the only time you'd need to fill my "thisid" "field" element with the internal id. It only gets added once - just like the internal autoincrement id. Or is my problem because I set it to "read only"? But that shouldn't affect Eval code, no? - only prevent user input. My guess it that when the Eval is triggered Fabrik doesn't know the new internal id value yet? That doesn't make sense either. Lets' just put it this way - my whole Fabrik component is "acting up" today - not doing things as expected - and I have no idea what's wrong.

 

[troester]

I think there a two points:

A readonly element is readonly, so it should not be submitted to the database (maybe at the moment there's still a bug submitting NULL).

The autoincrement internal id of a new record can't be known when the form is loaded: you may not submit the form at all, others may submit at the same time...; the internal id of a new record is 0 until the record is saved in the DB.

 

[Bauer]

I kinda knew how it was supposed to work all along. Then I got to wondering if placeholders weren't allowed in Eval. Did some research and it seemed OK to do. I had tried every combination of the placeholder I could think of (including as in your example) - for the past 2 hours - but it just doesn't like the placeholder.

I put a debugging
echo $a;
exit;

after initializing $a - and it either echos...
{fb_surveys___id_raw}

(i.e. the placeholder verbatum)

or

'{fb_surveys___id_raw}'
if I put single quotes around it.

Go figure. Do you have the latest GitHub? If so would you please try doing the same and let me know if you have the same problem?

I'm on to trying using as Calc per your other suggestion...

This is what drives me crazy most about programming. Things are chuggin' along like a breeze - then all of a sudden you get some stupid "little" thing like this that will have you going in circles all day.

 

[troester]

I'm not sure if you can use placeholders in default eval; it's only evaluated if it's a new (=empty) record, what should the placeholder contain? At least you can't use the id placeholder because the id isn't defined before saving the record.

Forget about ajax=yes (it doesn't make sense as the id is never modified by user input) and the if... in my calc code.

Set ajaxcalc=no and code just "return '{your-table___id_raw}';"

 

[Bauer]

I used field type "Display" - and entered the internal id element placeholder as the Default (Eval not checked)

{fb_survey_steps___id}

and all is well.

 

[cheesegrits]

I've fixed the bug with auto_increment, so we now correctly preserve NOT NULL AUTO_INCREMENT if the element you are changing is the PK of the table and set to auto_inc in the List settings.

I've tested changing a PK element from element type 'id' to 'field' (integer), and back again, and it correctly preserved the auto_increment setting and current value.

Not sure what the rest of this discussion is about, but the initial bug is fixed. We did have code to test for that already in place, but it got broken at some point, and was comparing DB `name`.`quoted` against non name.quoted strings for the PK name, so was not correctly identifying the element being edited as the PK for that auto_inc test.

-- hugh

 

[Bauer]

I've fixed the bug with auto_increment, so we now correctly preserve NOT NULL AUTO_INCREMENT if the element you are changing is the PK of the table and set to auto_inc in the List settings.

I've tested changing a PK element from element type 'id' to 'field' (integer), and back again, and it correctly preserved the auto_increment setting and current value.

Not sure what the rest of this discussion is about, but the initial bug is fixed.[...]

-- hugh

Thank You, Hugh. The original discussion was more of a request than to report a bug.

By design, the internal ID is not shown in forms (but can be shown in lists). I was trying to come up with a way around this as I want to show the ID in the form and detail display (as read-only of course).

I just questioned why the default is to not show it at all when (if the admin doesn't want users to see it) he/she can always set that visibility via the "Access" tab? If that "special rule" for the internal ID was removed (but changed so it is always read-only), I wouldn't have had to spend a good part of my day yesterday figuring a way around it (i.e. creating another element just to display the value of the ID).

 

[cheesegrits]

That's just the way it is. We originally weren't even going to provide list display for the internalid element, but for gory technical reasons we had to (so it can be used for sub-grouping).

The official way of display it in forms is to change it to a field element, of type integer. You just ran in to a bug that had crept in at some point, which stripped the auto_increment property when changing the element type of the List's PK.

No plans to change how the internalid works in forms, as that's why we created it in the first place, to avoid a number of traditional support issues with people doing things they shouldn't with their PK elements on forms, back when the ID was created by default as a simple field element.

-- hugh

 

[Bauer]

From now on I'm just going to walk away and repeat to myself 10 times over "this is a beta, this is a beta, this is a beta,..."

And I'll try not to rush to judgement, understanding that. I'm just the kind of guy who, when I run into a problem, will work relentlessly until it's fixed the way I want. I have to learn to put my priorities aside and let nature (or the nature of things around here) take its course. I'm trying, really.

 

[cheesegrits]

One thing you'll discover about Fabrik, if you haven't already, is that it's constantly evolving. The code base is now about the same size as the rest of J!, but maintained by just the two of us, and covers an insane amount of functionality, with usage cases limited only by the imagination of our users. And with a lot of users who have their own specific needs and priorities.

So you'll always be running in to things where the code doesn't do exactly what you want, or you uncover a bug. Which is essentially why we have the three levels of support, so we can prioritize feature additions and bug fixes, both by impact / severity, and support level. Straight out bugs in core code we'll always fix as high priority, but everything else gets prioritized by support level, severity, and (as previously discussed) how many people are asking for a given feature, and (in this case) whether there is a perfectly acceptable workaround.

-- hugh

 

[Bauer]

I can't even begin to imagine the stress you guys are under with such a huge project. I can't walk and chew gum at the same time anymore. And it's probably 10 years of the stresses of full-time programming that brought on "my condition" that now has me disabled. So don't fry yourself over "your job".

I've interacted with plenty of Joomla developers and sometimes I am pleasantly surprised with the support (like here). The Fabrik team is lucky to have a guy like you willing to keep up like you do.

I was heavilly involved with the Feedgator project for a while. Matthew must have totally burned himself out as he rarely even shows himself in the support forum anymore. That project turned into a 5-headed monster and if you dive into the code you can understand why he's overwhelmed. It relies heavily on other 3rd party APIs and that only adds to the inability to "keep things current". He hasn't posted an update in 6 months and has a to-do list longer than your arm. Two guys is a little better than one - but I know its' not easy. Hell, I can't walk away from something for more than a day anymore without totally forgetting where I was. As long as your mind and memory stays clear you have a future in programming - without that your just another frustrated "Bauer".

Then there's a lot of Joomla developers who do a good job of putting up a "front" to make it look like they have a staff of 50. A good web interface can fool the best of us.

One guy I have the utmost respect for is Peter van Westen at NoNumber - he must be a genius, literally. Most of the extensions he makes should be part of the Joomla core - especially the Advanced Module Manager. I don't know what I'd do without it. And he's on top of fixing bugs as they come up and has a great Extension Manager that handles updating
all 20 of his extensions. How can you not be impressed?

You guys seem to do well in that regard too. Kudos to you - and best of luck with this endeavor. You seem like a couple of highly motivated individuals and deserve your due.

 

[skyrun]

very old thread, but found it looking for this. and i'll add another workaround is to put text 'ID: {mytable___id}' in the form text, then it shows up on top of the form and you don't have to add a fake column by adding the 'display' element it.

at the risk of adding to the already 19 back and forths defending why the id can't be displayed on a form r/o when it's there (ie not a new record)... i too don't get why it can't be hidden yes/no option on the internal id plugin with the default yes for internal ids. (and while you're at it, put hidden yes/no on EVERY element type... so we don't ahve to make it a field, save it, make it what it should be and save it again... sloppy).

these work-arounds (fake/display element that adds a column to your db or showing the text on top) do work, just not intuitive. (off soapbox).