Search bar HTML/CSS only

[dragontheory]

[bob2517]

Possibly don't need the search submit button if this is going to be based on a keystroke event. A "clear" button might be useful though, to clear the search.

I'll do the functionality for the search, and it should be clearer to see what's needed then.

[dragontheory]

Possibly don't need the search submit button if this is going to be based on a keystroke event. A "clear" button might be useful though, to clear the search.

I'll do the functionality for the search, and it should be clearer to see what's needed then.

Ok. Thank you for answering my questions. Appreciate your patience and helping me understand.

[bob2517]

Cool. What do you want me to search on? I can search on any field or a combination of fields, or just the alias?

I'll set it up for just the alias and the real supe name at the moment, and you can let me know if you want me to extend it to include affiliations, or whatever you like.

[bob2517]

Almost done on this, pending a clear button or whatever gets added next. I've updated the API and got the search results returning the correct stuff. Just a bug fix to do, get the list to go back to default when the results are emptied, then a bunch of testing. Should have this done in the next hour or two, not accounting for dinner.

[bob2517]

You would think that the search would be complicated, but actually it's just this event:

	/* User search. Detect a key stroke in the search input field and decide what to do. */
	app-search > input:input {
		@if not-empty(self) && min-length(self 3) {
			/* Set the search value to a variable if the search string has at least 3 characters. */
			$srchValue: "{@@value}";
		} @else if empty(self) {
			/* Clear the search variable if there is nothing in the search box. */
			$srchValue: "";
		} @else {
			/* Don't do anything. */
			exit;
		}
		/* Set the page number to 1. */
		$viewPageNo: 1;
		/* Fetch the search results using the existing method of populating the list. */
		panel-list[data-search-results] {
			trigger: fetchRows;
		}
	}

Plus a change to the fetchRows ajax command to include the search string as one of the variables.

I've got something else to fix, but that's the basic code. It works really nicely because the UI is already set up to handle things.

It's cool that ACSS can handle the conditionals in the if statement, alongside regular JavaScript. That makes things a lot simpler to code. I did originally have 3 events, but I condensed it into one to re-factor it.

[bob2517]

I just committed what I've got so far, but there's still a bug I need to fix. The page number is not setting itself correctly yet. The rest is fully functional though and it's really cool to be able to search for specific supes.

[bob2517]

Also, it's not handling "no search results" yet. The pagination goes a bit crazy when that happens.

[bob2517]

Done another commit that fixes the page numbers. Just the "no search results" to sort out now, which is just a case of hiding the pagination, in terms of the expected result.

[bob2517]

Another thing that needs sorting out is when you hit refresh, the input field is remembering the search. It's probably worth change the url to involve the pagination parameters and getting the page refresh to grab the same list that was displayed before the refresh button was hit. That's quite easy to do - just store the variables in local storage and set them up on body init. The rest should take care of itself. I'll do that after I fix this last bug on the search.

[dragontheory]

Cool. What do you want me to search on? I can search on any field or a combination of fields, or just the alias?

I'll set it up for just the alias and the real supe name at the moment, and you can let me know if you want me to extend it to include affiliations, or whatever you like.

I think a combination of the fields, alias and affiliations.

[dragontheory]

Done another commit that fixes the page numbers. Just the "no search results" to sort out now, which is just a case of hiding the pagination, in terms of the expected result.

Thank you for that.

When I type in "Bom" the results reduce to 3, which is great! But the page numbers to the right of the "Search Results" don't change.

Also the second number should probably represent how many match the search text string, since the first number represents the number of visible results. For example, [ 5 / 10 ], would represent, showing 5 out of 10 possible or returned results.

[dragontheory]

Another thing that needs sorting out is when you hit refresh, the input field is remembering the search. It's probably worth change the url to involve the pagination parameters and getting the page refresh to grab the same list that was displayed before the refresh button was hit. That's quite easy to do - just store the variables in local storage and set them up on body init. The rest should take care of itself. I'll do that after I fix this last bug on the search.

Yes. Let's do that. That is phase one of a "preferences layer" that I would like to develop for all the various ways users will be able to customize the UI. Ultimately, not this time around unless it's easily doable, users will be able to customize the UI, save their customizations as a name (text string) of some sort, close out their browser, shut off their machine, and come back the next morning and bring up the app exactly where they left off. With everything exactly where they left off. Even what pagination page and if they had the right aside panel open or closed and if they had the form partially filled out. If they don't give a name to save, it auto-saves with today's date and time down to the second to make sure the name is always unique and in order. This would happen if the power was suddenly lost also. Is that overkill?