Restaurant Guide (Filtering by...)

redbot · 2009-01-29 11:46:55

Unfortunately I’m in a hurry so I can’t elaborate now, but I dare to insist you shold use the smd_query plugin taking advantage of the new tag nesting capabilities of txp 4.08. You have to study it a little but if I’m not wrong it’s all you need.

Here’s a quick example (modified from the plugin’s help):

<txp:smd_query column="Title"
     table="textpattern"
     where="custom_1='<txp:custom_field name="location" />' AND custom_2='<txp:custom_field name="atmosphere" />'
     form="yourform" wraptag="ul" break="li" />

I hope I’m not missing something but I think you should at least have a look at this approach.

jakob · 2009-01-29 11:48:21

As far as I know there’s no way of showing only some of the categories on the back-end. In that case you might want to take a different tack:

make your 1,2,3,4, each a different section
make your price-range either using a custom-field and glz_custom_fields or as a series of price-range categories (20-30, 30-40, 50-70,70+)
make your type – 1,2,3,4 and a,b,c,d,e,f… – a category but still separate into parent and child, so that you can show only the child categories on each section. On the back-end you will still have the long category-list, though. On the front end output only the relevant child-categories for that section. You can then also use “type of [restaurant/entertainment/shop]” for the label of your search box.
make your location either as a category (depending on what you choose to do with price), or as a custom field and us glz_custom_fields
make a duplicate site for another entire region (Barcelona), either with an own-url or a subdomain.

You will need to test this carefully as you will need to make glz_custom_fields and categories work together.

You are right to investigate this carefully as textpattern is relatively limited regarding complex searching. If your client suddenly wants another search item added or a different url structure, you may find you can’t accommodate it. Again, it pays to investigate this in detail from the beginning as once you have a lot of data, it is a tedious job to update a new ‘factor/property’ that gets added as an afterthought. If you anticipate this happening (e.g. yo mentioned to keep up with competition and also added a new town to the equation in your last post), you may want to design your dataset to be able to cope with different search methods and for extensibility and then choose or design the realisation method afterwards. Txp may not be the most appropriate tool.

mlarino · 2009-01-29 12:10:44

Thanks Redbot
I was trying to read about smd_Query but I have no idea about SQL, so that would take me forever to learn… I will try to read more into it and see if I understand something.

Thanks for your help Jakob
This project is becoming a little crazy, there is no cash to hire a programer or someone to do all this, so I am in charge, all I know is HTML + CSS and how to use textpattern.
When you say textpattern may not be the most appropiate tool, what other tool would you suggest?

I will try all this Category/Section/Custome Fields mess and see if I am able to make a simple search for the user. (or at least as easy as posibble)

Thanks again!

redbot · 2009-01-29 12:38:30

Never post when you’re in a hurry.
Re-reading my post I realize I made it too easy and also my example is plain wrong.
I still think smd_query would be useful but you have to combine it with adi_gps and maybe some php to build the form so, sorry, maybe this was not the right solution in your case.

mlarino · 2009-01-29 12:45:11

No problem RedBot,
Can someone point me to a detailed explanation of the relationship of Sections/Categories/Childs with search?
Is there anything documented like that?
Thanks!

Bloke · 2009-01-29 12:49:09

redbot wrote:

smd_query would be useful but you have to combine it with adi_gps

Not strictly true, as smd_query can read directly from the URL now and has the filtering capability to weed out bogus input.

However — as jakob is saying — the biggest problem is not what to do with the data but how it is organised. Once that hurdle is crossed and the structure is nailed down, then I’m sure smd_query / adi_gps / smd_if / glz_custom_fields / txp:if_variable et al can slice the data and produce something meaningful.

Last edited by Bloke (2009-01-29 12:50:02)

mlarino · 2009-01-29 13:04:58

Thanks Bloke,
I will try to nail down the structure like you say.
Will create a couple of different aproaches to the problem and see how sections/categories/custom-fields end up.

I will post my options of structure and maybe you guys can point me to wich you think is correct.

Thanks again for all your help!

mlarino · 2009-01-29 17:39:44

I was searching around the forum and found smd_if
I think it was you Bloke that was responding to someone that wanted to create a multiple search form. exacly what I want to do.
Will smd_if work for this?

That way I can create a form that will search for the 4 custome fields I will create at the same time.
right?

Bloke · 2009-01-29 18:26:26

mlarino wrote:

Will smd_if work for this?

You mean like the thread I referenced in post #5? In which case, yes — with some cunning and ingenuity, it will work.

Be warned that it largely depends on how many articles you have, and whether you can pre-filter those articles (e.g. by section and/or category first). If you let smd_if romp through an entire site of a few hundred articles each time someone searches for a restaurant, then as your user base grows, you will:

a) annoy visitors because it will be slow
b) annoy TXP because it will have a lot of work to do
c) annoy your host and any other shared hosters, as you suck resources away from them

smd_query will more likely ease the load and get things back a lot quicker if you streamline the queries. People here can help design your queries for maximum efficiency, but you will have to have a reasonable idea of what you are going to store in which fields and how stuff is organised first.

How are your plans for that bit coming along? Got any more ideas that we can debate?

Last edited by Bloke (2009-01-29 18:28:33)

mlarino · 2009-01-29 19:23:41

Thanks Bloke,
I will try to refine the ideas for the organization of all the categories etc… and will post them soon.
Thanks again for helping!!!

mlarino · 2009-02-02 12:48:21

Hi Again!
I finally have an idea for the clasification of the articles.
I will try to write it as clear as I can.

Category:
MADRID with 23 Child categories (Centro, Salamanca, Chamberí, Latina, Ciudad Lineal, Barajas… etc…) – To Classify into zones of the city
—————————————————-

Sections:
RESTAURANTS
ENTERTAINMENT
SHOPPING
BEAUTY & HEALTH

Section: RESTAURANT (Custome Fileds: Type of Food / Atmosphere / Price range)
Section: ENTERTAINMENT (Custome Fileds: Type of Entertainment)
Section: SHOPPING (Custome Fileds: Type of shopping / Category)
Section: BEAUTY & HEALTH (Custome Fileds: Type of Beauty & Health / Category)
————————————————

Custome Fileds: __(using glz_custom_fields to create lists inside each one)
Type of Food (Mexican, Italian, Japanese, etc…)
Atmosphere (Romantic, Classic, Modern, etc…)
Price range (10€-20€, 20€-30€, 30€-40€, etc…)
Type of Entertainment (Movies, Theater, Music, Drinks, Art, Tours, Attractions, etc…)
Type of shopping (Fashion, Jewlewry, Flowers, Cosmetics, Toys, Decoration, Gourmet, Books, etc…)
Type of Beauty & Health (Hairdresser, Spa, Gyms, Medical Centers etc…)
Category (Middle, High, Deluxe, etc…)
————————————————

That is my idea on how to use the Cateries, sections and custome fields to clasify all the articles on the website.
What do you guys think?

mlarino · 2009-02-03 12:00:24

Do you guys understand my explanation?

Bloke · 2009-02-03 12:29:17

mlarino wrote:

Do you guys understand my explanation?

Yeah, looks like a plan to me. The good thing about using Category as a location is that you have the option to enhance it in future with an extra layer, e.g.

Spain
  -> Madrid
     -> Centro
     -> Salamanca
     -> ...
  -> Barcelona
     -> ...
Italy
  -> Rome
     -> ...

Filtering things across sections so visitors can look for specific types of “thing” in a particular region of the city is easy with article_custom. The custom fields are easily searchable and will help to narrow things down further. And you can reuse the custom fields across sections, which is great; perhaps using sed_section_fields to only show appropriate types as you listed above so that people can only enter the correct type of information when writing articles.

It seems like a logical way to approach it all.

I do echo jakob’s sentiment about the price ranges though. It’s fine now — and yes it’s nice to allow people to filter by an actual price — but to filter by a range of actual values is perhaps opening yourself up to a lot of work in future when the global economic climate shifts (of course you might want this for repeat business purposes!)

By employing ‘price’ as some subjective range of quality (like “cheap & cheerful”, “mid-price”, “expensive”, “luxury”) you might save yourself some work. But if the customer demands actual values, then that’s decided.

So if you enter some articles in this proposed schema does it seem to hang together ok? Do you get a good feeling that it’s extensible and can meet the (future) demands of the client? Can you display all the stuff you need from each article? If so, it’s a winner.

Then comes the fun part: the filtering!

mlarino · 2009-02-03 12:38:11

I am not sure id the fun part! hehe
I am a little scared what can happend when I start doing that :)

I have to show my plan to the client and show them how the back end will look so they can upload the content, It is pretty easy for them visually, thanks to glz_custom_fields and sed_section_fields.

When I get confirmation I will start posting some articles in categories etc… and see what I can do about the filtering
thanks!

Bloke · 2009-02-03 12:51:04

mlarino wrote:

I am not sure id the fun part! hehe I am a little scared what can happend when I start doing that :)

It sounds to my untrained eye — if I may mix metaphors — that your approach works. Others may see some issues I’ve not spotted, but it seems solid to me.

If you stick with that, I’m confident that the filtering will be relatively straight forward. I’ll help where I can.

Textpattern CMS

Textpattern CMS support forum

#16 2009-01-29 11:46:55

Re: Restaurant Guide (Filtering by...)

#17 2009-01-29 11:48:21

Re: Restaurant Guide (Filtering by...)

#18 2009-01-29 12:10:44

Re: Restaurant Guide (Filtering by...)

#19 2009-01-29 12:38:30

Re: Restaurant Guide (Filtering by...)

#20 2009-01-29 12:45:11

Re: Restaurant Guide (Filtering by...)

#21 2009-01-29 12:49:09

Re: Restaurant Guide (Filtering by...)

#22 2009-01-29 13:04:58

Re: Restaurant Guide (Filtering by...)

#23 2009-01-29 17:39:44

Re: Restaurant Guide (Filtering by...)

#24 2009-01-29 18:26:26

Re: Restaurant Guide (Filtering by...)

#25 2009-01-29 19:23:41

Re: Restaurant Guide (Filtering by...)

#26 2009-02-02 12:48:21

Re: Restaurant Guide (Filtering by...)

#27 2009-02-03 12:00:24

Re: Restaurant Guide (Filtering by...)

#28 2009-02-03 12:29:17

Re: Restaurant Guide (Filtering by...)

#29 2009-02-03 12:38:11

Re: Restaurant Guide (Filtering by...)

#30 2009-02-03 12:51:04

Re: Restaurant Guide (Filtering by...)

Board footer