I actually really understand the need for multiple table joins - I needed that for the site that I developed this component for. However, try as I might, I could not think of a SIMPLE way to do this that would be flexible enough for all situations - especially not when the "extra column and makeUrl" strategy is so much simpler and more flexible. The configuration for it alone would add way too much complexity, and I would probably need to add some sort of caching. And CustomUrls can also generate, auto-detect, and redirect to schema urls, all of which will need to be modified to work with joins.
This means that I (or someone else) might add joined tables to the component in the future, or at least a dedicated alias table, but in the meantime it will have to stay one table only. If anyone wants to contribute, feel free to do so on GitHub
.
So everything went flawlessly while working with one table. I’m stuck when it comes to deal with multiple tables. Should i generate multiple settings or should i use the child_schemas setting ? I guess my case is almost the same as Lucas, i have only one schema with multiple tables
To set up child schemas, you have to set them up as independent schemas, then list their names (and optionally an array of setting overrides) under their parent’s "child_schemas" setting. It can be a simple array of schema names or an array of "name" => "setting_overrides_array" pairs - here’s an example: [tt]..,"child_schemas": {"child1":{"url_prefix":""},"child2":{"url_prefix":""},},...[/tt]. If you list multiple children for one parent, they will be checked in sequence until a match is found. To CHAIN children, you will need to add children to the child (grandchildren). You also can set the "run_without_parent" setting to false if a schema only exists as a child of another schema. Please also get the latest GitHub source, since I made a few fixes to children and actions in particular.
Right now, child schemas work completely independently of each other. In other words, they are designed to have multiple custom URL schemas working together (e.g. /author/topic/, /location/topic/, etc...). You can use them for something like /category/child, but the child would have to have a UNIQUE alias across all categories, and you would need to validate it somehow to make sure that the child matches the category. Right now this plugin is really only designed to work with UNIQUE aliases, not those dependent on joins.
To illustrate with an example:
You have a table of articles, each categorized to a topic, author, country, state, and city. You would use TWO schemas (parent and child) when you are displaying a list of articles filtered by BOTH topic and author:
http://site.com/author/topic/. The REQUEST parameters ’author_id’ and ’topic_id’ will be set on the page, and it is up to you to figure out if any articles match and what to do if they don’t. Similarly, you would use THREE schemas (parent, child, grandchild) if you need
http://site.com/country/author/topic/.
However, if you try to do this with
http://site.com/country/state/city/topic/, you must use only TWO schemas (city and topic), because the same city name is present in different states. Otherwise, if your country is United States and your state is New York, you might get Small Town, AZ instead of Small Town, NY. You will need to GENERATE an alias for Small Town as follows: "united-states/new-york/small-town" and use the CITY table for the parent schema, and the TOPIC table as the child schema, to get something like
http://site.com/united-states/new-york/small-town/some-topic/ and the following REQUEST parameters set: ’city_id’ and ’topic_id’.
Finally, to display the individual article (whether or not you use topics, locations, or authors in the URL), make sure each article has a UNIQUE alias, even if you have to generate a "country/state/city/topic/author/article-name" alias every time your article is edited. Alternatively, you can just make sure the article alias is unique in some other way (such as by appending the createdon date or article id) and proceed to use child schemas for the complex URL, although that would not be very efficient.
Does that answer your question?
☆ A M B ☆
☆ A M B ☆
