Preferred Design Pattern for Search Popdowns?

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

Post Reply
User avatar
volomike
Forum Regular
Posts: 633
Joined: Wed Jan 16, 2008 9:04 am
Location: Myrtle Beach, South Carolina, USA

Preferred Design Pattern for Search Popdowns?

Post by volomike »

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.
User avatar
Eran
DevNet Master
Posts: 3549
Joined: Fri Jan 18, 2008 12:36 am
Location: Israel, ME

Re: Preferred Design Pattern for Search Popdowns?

Post by Eran »

I usually retrieve a list an options from the model as an array, and then render it using a view helper. Rendering arrays into a list of options is not complicated, but even better for me since I'm using ZF most of the time, and it has nice helpers for rendering form inputs. The select helper takes:

Code: Select all

//Inside a view template
echo $this -> formSelect('nameOfSelect',$value,$attrib,$options);
$value is the value you want to start selected (can be null), $attrib is an array of html attributes/values, and options is the array of options I mentioned earlier. pretty simple
User avatar
volomike
Forum Regular
Posts: 633
Joined: Wed Jan 16, 2008 9:04 am
Location: Myrtle Beach, South Carolina, USA

Re: Preferred Design Pattern for Search Popdowns?

Post by volomike »

You know, that's probably how I need to steer this. Let the model come back with an array of keys and values for the listbox, and then create a helper class method in the view class to convert array values into OPTION tag XHTML that I can then use View::Assign() to stick into a constant in my template.

Now, as far as whether to put a class method to return this array of keys and values in the domain objects like Employers, Candidates, Jobs, and so on, versus creating a utility class like Search and putting all the class methods there, I'm still not certain what's the best approach. Perhaps you can suggest on this one with some reasoning, pytrin?
User avatar
Eran
DevNet Master
Posts: 3549
Joined: Fri Jan 18, 2008 12:36 am
Location: Israel, ME

Re: Preferred Design Pattern for Search Popdowns?

Post by Eran »

I would put the options retrieval method in the domain classes, since its their responsibility to know about the logic of returning their options (the logic differs between them). If the logic is similar between some of those, maybe add a base class with a getOptions method that they can inherit from.
Post Reply