Ajax calls - Performance and security

PS: This is for filter mode auto-complete ...

I agree. We will solve this when we update listautocomplete component to new one we created.

https://github.com/Serhioromano/bootstrap-tags

When using the filters, I would even prefer a loading on demand and not to get them ahead of time

I very much agree with Sackgesicht on this regarding both performance and data security.

I'm working on my first project with cobalt and havent really taken too much notice of how the filters work until now.

In a test site with around 15k records (I expect many more) and a few filter fields the amount of data the ajax filter calls are pulling in is well over a megabyte - I know its not gzipped etc yet but thats not acceptable.

And concerning sensitive data - whilst I know scrapers are often clever, I usually have at least some chance of blocking them.

But with the ajax filter data - I would be presenting several nicely formated sets of the entire sites valuable (and possibly sensitive) data every single page load.

Mainly what I dont get is - Why does all that data have to be passed out to the client at all?

I had a quick look at the github Bootstrap tags project - will this solve this problem?

Is there a timeline for including it?

thanks for listening :)

havent really taken too much notice of how the filters work until now.

I see quite some room for improvement in the way Cobalt uses filters.

As an example: If a filter uses inline JS and the same field type is used several times for a filter, all the code will be replicated on the side.

For small projects/number of records, the approach to load everything ahead can be an advantage, but when you reach a certain number of records it will become a time and memory consuming problem.

Out of a selection of many filters, the user might just choose 1 or 2. With the existing default tab setup, it might be a better approach to load the filter values (especially for a typeahead) on demand.

Similar problem with the list template when using a relate field within one table row. See here

For Cobalt 9, a maintenance/analytic tool would be nice. This tool could analyze different query scenarios and give suggestions for Cobalt parameters (e.g. when to use Smart/fast search, based on settings and record size etc) --> Profiling a section

I just included a filter module. I now see that all filter calls are made twice and the data fetched twice per filtered field.

If I put filter on some basic text fields such as address city etc thats over 2.5 mb of ajax!

and the same field type is used several times for a filter

Is that similar to what you meant?...

I wonder: have I missed something in the fields setup here? Or is this standard behaviour?

Also:

The filter link is very useful in front end, but afaik the ajax fetch isnt neccessary for filter link to work.

Well I tested this by enabling filter on a field, and then disabling output of onFilterGetValues.

And in this scenario the filter link still works ok(-ish).

So can I just have a field option to turn on the filter link - but turn off the associated ajax fetch please?

I still feel I'm missing the point of something here and I cant find any info in forum or docs or clue in code, so I ask again:

Why does all that data have to be passed out to the client at all?

thanks

It might be called twice because you have them twice on the page. One time in advanced serch and second in filter module.

So can I just have a field option to turn on the filter link - but turn off the associated ajax fetch please?

Every filter parameters group has Hide filter parameter. this is exactly what you need. Filter is enabled but it is not in advanced search. Only links.

Every filter parameters group has Hide filter parameter. this is exactly what you need. Filter is enabled but it is not in advanced search. Only links.

almost perfect - thank you

I say almost perfect because when I asked this:>

Every filter parameters group has Hide filter parameter. this is exactly what you need. Filter is enabled but it is not in advanced search. Only links.

So can I just have a field option to turn on the filter link - but turn off the associated ajax fetch please?

I probably should have asked this:

So can I just have a field option to turn on the filter link AND keep the filters in advanced search - but turn off the associated ajax fetch please?

Link only will do for now but as I asked before - Why does all that data have to be passed out to the client at all?

• just asking!

[While I'm here can I just take an off topic moment to say how pleased I am with cobalt. There's such a fantastic amount of functionality and potential included that as new user I'm still finding my way around it. But overall its really very impressive. Yea I know... best I do a jed review.... ok soon :) ]

So can I just have a field option to turn on the filter link AND keep the filters in advanced search - but turn off the associated ajax fetch please?

Ajax is made only when filter is autocomplete. If you use select or checkbox there is no ajax call.

Thank you for off topic

:D:D:D

Ajax is made only when filter is autocomplete.

yea I understand that. But 2 points:

1) if I use a select or checkbox I'm still pushing all that data out to client - just inline with page

(actually I forget what cobalt does here but I think thats correct)

2) I kinda thought the great thing about autocomplete was to use ajax to fetch only that which is required when it is required. eg: fetch options as the user types? 'load on demand' as Sackgesicht said...

Ajax is made only when filter is autocomplete.

When using the filters, I would even prefer a loading on demand and not to get them ahead of time (it might be useless if it is not requested by the user).

Also in support of Sackgesicht point about 'useless if it is not requested'

I could make a reasoned estimate that 99% of of the data is never going to be required for 99% of the time - so why send it all out to client with every page?

Anyway link only is ok for what I need for the moment, I'll come back to it later.

uhhh, its easy to get misunderstandings and I wondered if perhaps we are not on same page in this discussion.

So to be sure I offer some clarification and definition of 'autocomplete'

It seems that perhaps you are [quite correctly] talking about autocomplete like jQuery autocomplete widget which uses local array as data source like this:

http://jqueryui.com/autocomplete/

whereas I was hoping for use of autocomplete widget which fetches data from remote source via ajax like this:

http://jqueryui.com/autocomplete/#remote

anyway, maybe that helps, but sorry if its already obvious.

In england we have a saying: "I dont want to teach my granny to suck eggs" - but honestly I never understood why grannies have to learn how to suck eggs :D

Unfortunately autocomplete widget we are using loads all data once on widget load. No ability to load on type. But that is gonna change when we change that widget in Cobalt 9. Right now it is too painful as it is involved in lot of places.

ok no prob.

Right now it is too painful

pain is not good. dont do pain... I can live with links only for now :D