Preferred Design Pattern for Search Popdowns?
Posted: Sun Jan 11, 2009 1:39 pm
You know on a search page where you have several popdown listboxes such as counties, job sector, categories, etc.? Well, these must get populated, obviously, and then they must be reselected with "select" on an "option" tag in XHTML once someone does a post back to the page when they click Submit.
You've probably done this before a thousand times. Okay, a few questions...
1. I'm using a GET instead of a POST because on search pages you typically see this and it permits me to bookmark a particular query in a hyperlink in other parts of the application, such as, "Show me all the jobs related to a given company," and you click the link and it takes you to the search page and shows you the result -- all thanks to a GET instead of a POST. It's the only place in my site where I'm blowing the whole handsome URL thing (you know, with .htaccess). Okay, this is fine and all, but then I end up with a bunch of &jt=&ft=&ct= at the end for fields that are not filled in. Is there a way via jQuery to ensure that when they click submit, it only puts together the items that are actually filled out? This could shorten the URL.
[BTW, I know #1 isn't a design pattern question -- I just wanted to ask it because it was slightly related.]
2. So then I have a search.php (as a page controller) in my MVC, and I'm trying to figure out what model arrangement in my "models" subfolder to handle getting the values in the popdown listboxes, and reselecting an item by key. At first, I went with the Domain Object strategy. For instance, I had some popdown listboxes that dealt with Employers, Jobs, Counties, and Sectors. So, I created those domain objects and stuck a class method in like .Get___Options($sSelectedKey) where the ___ is the name of the thing I want, such as Job Sectors, Job Types, etc. The $sSelectedKey tells my class method which item was previously selected so that it can adjust the option list it returns.
Some more background.
- I'm building the OPTION tag stuff in my model, rather than building it in the view or the page controller. It's one of the few places in the site where I'm actually doing XHTML inside a non-view area. I guess the only other option would be to create a function that I call from my view, where I pass it an array of listbox data and a selected key, and the function does it on the fly for me inside the template, rather than setting that var in the page controller. Anyway, though, I stuck with just doing it in my model, passing the value as XHTML back to the page controller, and then letting the page controller assign a variable in the view for display on the page. This makes the template fairly lean, which I like.
- I've got a DB class to abstract all the database calls, and then an ORM class to abstract having to type that much SQL, although occasionally I go around it and send the query straight to the DB class. My model objects then talk to the ORM or the DB class (mostly the ORM class).
Okay, so the question is this. Did I pick a good pattern here with the Domain Object strategy, or should I have made a kind of toolbox strategy where I create a class like Search_Tools with all the listbox methods from it? Or, do you have a better pattern you would have chosen?
To me, the Domain Object strategy seems wrong. This is because a domain object strategy would normally have CRUD methods on it, right? I'm not doing CRUD per se here -- except the "R" in that equation, and where I'm returning a result in XHTML for a particular purpose.
I hope I haven't confused you guys on my question.
You've probably done this before a thousand times. Okay, a few questions...
1. I'm using a GET instead of a POST because on search pages you typically see this and it permits me to bookmark a particular query in a hyperlink in other parts of the application, such as, "Show me all the jobs related to a given company," and you click the link and it takes you to the search page and shows you the result -- all thanks to a GET instead of a POST. It's the only place in my site where I'm blowing the whole handsome URL thing (you know, with .htaccess). Okay, this is fine and all, but then I end up with a bunch of &jt=&ft=&ct= at the end for fields that are not filled in. Is there a way via jQuery to ensure that when they click submit, it only puts together the items that are actually filled out? This could shorten the URL.
[BTW, I know #1 isn't a design pattern question -- I just wanted to ask it because it was slightly related.]
2. So then I have a search.php (as a page controller) in my MVC, and I'm trying to figure out what model arrangement in my "models" subfolder to handle getting the values in the popdown listboxes, and reselecting an item by key. At first, I went with the Domain Object strategy. For instance, I had some popdown listboxes that dealt with Employers, Jobs, Counties, and Sectors. So, I created those domain objects and stuck a class method in like .Get___Options($sSelectedKey) where the ___ is the name of the thing I want, such as Job Sectors, Job Types, etc. The $sSelectedKey tells my class method which item was previously selected so that it can adjust the option list it returns.
Some more background.
- I'm building the OPTION tag stuff in my model, rather than building it in the view or the page controller. It's one of the few places in the site where I'm actually doing XHTML inside a non-view area. I guess the only other option would be to create a function that I call from my view, where I pass it an array of listbox data and a selected key, and the function does it on the fly for me inside the template, rather than setting that var in the page controller. Anyway, though, I stuck with just doing it in my model, passing the value as XHTML back to the page controller, and then letting the page controller assign a variable in the view for display on the page. This makes the template fairly lean, which I like.
- I've got a DB class to abstract all the database calls, and then an ORM class to abstract having to type that much SQL, although occasionally I go around it and send the query straight to the DB class. My model objects then talk to the ORM or the DB class (mostly the ORM class).
Okay, so the question is this. Did I pick a good pattern here with the Domain Object strategy, or should I have made a kind of toolbox strategy where I create a class like Search_Tools with all the listbox methods from it? Or, do you have a better pattern you would have chosen?
To me, the Domain Object strategy seems wrong. This is because a domain object strategy would normally have CRUD methods on it, right? I'm not doing CRUD per se here -- except the "R" in that equation, and where I'm returning a result in XHTML for a particular purpose.
I hope I haven't confused you guys on my question.