Hello Fabrik Community
Fabrik is now in the hands of the development team that brought you Fabrik for Joomla 4. We have recently transitioned the Fabrik site over to a new server and are busy trying to clean it up. We have upgraded the site to Joomla 4 and are running the latest version of Fabrik 4. We have also upgraded the Xenforo forum software to the latest version. Many of the widgets you might have been used to on the forum are no longer operational, many abandoned by the developers. We hope to bring back some of the important ones as we have time.
Exciting times to be sure.
The Fabrik 4.0 Official release is now available. In addition, the Fabrik codebase is now available in a public repository. See the notices about these in the announcements section
We wish to shout out a very big Thank You to all of you who have made donations. They have really helped. But we can always use more...wink..wink..
Also a big Thank You to those of you who have been assisting others in the forum. This takes a very big burden off of us as we work on bugs, the website and the future of Fabrik.
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