Form with 300 field

That may certainly affect perfomance. Tell us mmore about your setup and what you are trying to make and maybe we can chunk it in to smaller pieces.

Following... ;)

Sergey maybe we can chunk it in to smaller pieces.

This reminds me on another Joomla club site, where I've had a membership. It was a CB profile with several fields, modules and some custom data. All those "chunks" were split into different CB tabs. The interesting thing was... :

The tab's contents did not load at once! Only the first visible tab loaded his data. All hidden tabs were actually empty, until I clicked on it and gave focus to it. Then the tab content was loaded via AJAX.

Maybe something like this makes sense for Cobalt's field groups?!

Maybe also interesting for Relation fields and their template override. i.e. first display title with link, but load extra data (intro fields) via AJAX.

Thanks for listening.

Hi Sergey! You are like a Spirit, you can be anywhere where you are needed. Ok, this will be an intranet site for my company. First there is 3 types and three section.

1. Orders
2. Clients
3. Tool types

Client and Tool types have only few field not a big deel but Orders sometimes need at least 300 fields. Lets see why.

On the image above you see orders type's form. The last row on the picture must be repeated at least 40 times. Every row is a tool. In most cases 10-15 row will be filled out but sometimes need 40. You see that there is 8 field in those rows and 6 are textarea. These must be multiline anyway. The form has 4 select list field with SQL query from the other 2 types. One of this SQL field will be repeated in every row.

Orders type form will be filled out about 2500-3000 times per year. But probably with time more types will be need.

Seblod has an interesting field type (x field and x group maybe) similar to drupal you can duplicate field or fieldgroups on the fly during form submission. A field type like this could be good for us too. I don't tested the form yet with all of the fields but if there isn't serious speed issues I don't care I just thought ask before begin duplication of that row. If there is speed isuues I have to find some solution because I have to finish this next week.

danielbidala you can duplicate field or fieldgroups on the fly during form submission

Yes, this fielsd is first in the line of new fields for Cobalt 9.

danielbidala but if there isn't serious speed issues I don't care I just thought ask before begin duplication of that row

Actualy I do not see any problem why 300 fields should not work. I did not test but I am almost sure it will work smoothly. Just make sure not more than 10 fields have "Show in the list" set to Yes.

Hi Sergey!

I think I found a serious and strange speed issue in list view. I use Cobalt 8.630

I have a test site and it has a type with about 100 fields. In list view (table template) only 8 field visible. I imported 16K records to test the speed (this site will run with about 100K records). I imported only about 20 fields to every record.

Case 1. Default records per page is set to 30. In list view (table template) only 8 field visible. All the 100 fields are published. Joomla debug is on. And the result:

Case 2. Default records per page is set to 30. In list view (table template) only 8 field visible. Only 20 fields are pulished including the 8 that are visible in list view (all other fields are unpublish). Joomla debug is on. And the result:

As you can see the load time is more than double in first case but the visible fields in list view are the same in all case. If I unpublish further fields and only the 8 visible fields in the list view are published the load time continue to fall. The db query time is almost the same but in the Application: afterDispatch there are big differences.

Is this normal? If yes. I have to find some solution to the 80 repeatable fields in my type (8 fields are repeated in 10 row = 80 fields)

We need to look into queries and find most long queries in debug report. What are those? Then I can say how to optimize.