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.