We have now opened a commercial services section here on the forum for registered users. If you have a Fabrik project that you wish to have someone work on for you, post it under Help Wanted. If you are an application developer and wish to earn some money helping others, post your details under Fabrik Application Developers.
Both of these are unmoderated. It will be up to both parties to work out the details and come to an agreement.
For running J!5.1 you must https://fabrikar.com/forums/index.php?wiki/update-from-github/ or include the new file manually https://fabrikar.com/forums/index.php?threads/joomla-5-1-and-fabrik-cannot-find-files-error.54473/post-285151 See also Announcements
I should have explained better. I didn't mean a total count - I meant an incremental counter.List option "Show total" (Navigation group)?
I don't know - I don't have a survey with more than 10 steps.Out of interest, does this work if you paginate? So going from page 1 to page 2 of a list, does it restart the count at 1 on page 2?
-- hugh
I said the query would have to be re-run every time the order was changed (that includes if filters change).Not really a workable solution, given that the row numbering would change with every permutation of filtering.
OK - So as usual I'm just making things more difficult than they need to be. So do it that way. All I'm looking for is a read-only "counter" element that is treated as not part of the table, yet can be displayed in both the list and forms.The element I had in mind would simply factor in the current limit arg (essentially the list display's "page number"). So instead of starting at 1 each page, it would add "page num * rows per page".
It's one of those things I've considered writing an element plugin to handle, as we get this request on a semi-regular basis, which would have no presence on forms, but would display the simple row count / display order on Lists. But as usual, it's a case of finding the time to do it.
I said the query would have to be re-run every time the order was changed (that includes if filters change).
ps. I still like the idea of a mappings table. The idea of creating a new table for every mutiselect element is adding dozens of (IMO unnecessary) new tables to my database. Why not have just ONE table holding all mappings - with those same fields PLUS the "element name" as another field (e.g. - "fb_surveys_repeat_access_level") - then just querry the mappings table on that element name to get the mappings?
Whatever. If you were consistent in your argument then you?d agree that the Elements table is poor design. There should instead be individual tables for each Element Group. No?Because that would be the wrong way to do it, for oh ... I can't even begin to count the reasons. Read up on database normalization and indexing.
-- hugh
I?d say that a mappings table (just like the elements table) would be ?read-intensive?.However, when denormalizing the schema, do take into consideration, the number of times you would be updating records compared to the number of times you would be executing SELECTs. When mixing normalization and denormalization, focus on denormalizing tables that are read intensive, while tables that are write intensive keep them normalized.
(...and the calculation would change the "this_count" row numbering with every permutation of filtering! It's meant to be a read-only field and the row values will get recalculated on every page refresh. Isn't that the whole idea of the calc field?)Not really a workable solution, given that the row numbering would change with every permutation of filtering.
The element I had in mind would simply factor in the current limit arg (essentially the list display's "page number"). So instead of starting at 1 each page, it would add "page num * rows per page".
-- hugh