new style search help? preserving results + auto-categorizer

[momijizukamori]

Not dead! Just busy with life. But Fu is in the process of converting the widgets on /customize to something less ridiculous, which gives me time to prod some of the problems that have been stumping me.

1) Preserving search results
The order of actions to generate a page of results from the advanced search, as I have it right now, goes like this:
User checks boxes to indicate choices -> user presses 'search' button -> button triggers POST actions -> a query is generated as one of these actions -> query goes to worker -> worker performs search -> worker sends back a list of theme ids

The problem is that POST data is lost on reload/page change, so when you click to see the second page of results (if there are more than one page), all of the query and the results vanish. Most of our other ways of grabbing a set of layouts (by base style, by designer, etc) append the query string to the URL, which is then hidden from the user via routing, but even just the list of search elements has the potential to get unwieldy fast (and the return list is worse)

2) The auto-categorizer
I don't have this working yet because it's not necessary for the new search, just... nice, given we have almost fifteen hundred themes (!!!). The script needs to pull hexcodes out of the style layers (which is all text to the perspective of anything not the S2 compiler). That seems to say 'regex' to me but I don't know if that's safe/the best way to do it.

Comments

[afuna]

Hrrm, quick and easy hack to do this:

Take each query filter and throw it into a hidden form input field. That way on subsequent POSTs, we'll stil be aware of the new query stuff.

2) We're pretty standardized on # + 3 digits or # + 6 digits, and no nesting, so I'd say that looking for set + anything with the above should be reasonable. Or even, just looking for "set (specific variablename)" because we probably only care about page background + page text + entry background + entry text (more or less!)

And then also compile a list of those with background images so you can manually mark those as a color range?




Thhhhhouuuuuugh well I'm thinking that we're not doing this live, right? You could hypothetically have your script go through each layer, load the values for the props you care about using: LJ::Customize->get_s2_prop_values

And then ... stuff. do stuff.

[momijizukamori]

Hmmmm I may need more explanation on how to work the hidden input field thing so they don't vanish, but that sounds like a doable solution

And my initial plan was to write something to hook into the S2 update script so that when new layers are added, they get categorized as well. Though get_s2_prop_value sounds like it might work if we've got enough standardization across layers in prop names.

[fu]

1) hidden input field == <input ... >, and if it matters only on page load, then we can populate the name/value based on the $POST stuff.

(If the theme nav were one big form element, you wouldn't need to do this, but IIRC the widget stuff is sufficiently complicated that it'd be more difficult to do it that way)

2) s2 update script -- that sounds good! by not live I only meant "when they're searching" :)

[momijizukamori]

Hmm. I wonder if we could repopulate the sidebar tickboxes, maybe? Right now those are lost on load too, so you don't see what terms the current search used.

(and ahaha no, stuff's getting calculated and shoved in a database. Tying it to the update script just seemed like the best way to ensure new themes are getting added to the database)

[fu]

Ahh yeah you could, that would be good. But also in this case would be so the user could see; because the next page button is in a separate form from the search, having the checkboxes selected in the search form would do nothing.

But yeah, set the checkbox value based on the POST value when generating the page on the server too!

[momijizukamori]

Oh! Okay, that makes sense. The structure of /customize is so weird XD