Creating Database Pages in MODX. Each product is own url, Sort of Vritual Page

Hello,

We have a website build in MODX. We also have a database with data
about a lot of products. We want to create a page for each product.
The product-page should be constructed according to a template consisting
of chunks, snippets, HTML and PHP code. So, a real MODx-template.
But the pages are not there, the information for each page is in a
database.
Since there are around 1200 products, we do not want to create real
MODX-documents for each product.
What we want is to have some sort of virtual-Document.
So, if a certain url is entered, like www.mysite.com/products/productXYZ.html
then MODX is triggered by the ’/product/’ to NOT look for a document
but to build the document according to a ’product’-template from
information from the database.

Is this possible in MODX?

The direction I was thinking is to route the url to one document
in the MODX-tree by the .htaccess file and there read form the request-url
which product was meant. Then that document gets all info from the database
and creates the page.
With this method we have the original URL (good for Google!!) and we
have one document servicing a lot of other documents.

Or is there a smarter solution?

We are using the latest 0.9 version of MODX.

Thanks,

Bert Catsburg

This is the correct way to do things IMO, and all you need to do is come up with rewrite rules to match the query string parameters you choose to drive the view of a specific product, OR, use a plugin OnPageNotFound to direct these custom URLs to the dynamic view you are creating.

we had a related discussion whilst commenting on a snippet "In Development".

If I can be allowed to re-post my thoughts:

<brainstorm>
on your last point about the database vs document approach.

Being relatively new to MODx development(slightly over a year) and still getting to grips with its power...

I think most module/snippet developers have a difficult time deciding on going the database route(i.e no referrence or linkage to MODx documents for snippet-data) OR the document route. Taking the document route would mean easier access to very powerful and useful tools like Ditto,Jot..etc. If one takes the database route, i.e. no linkage to documents, then it means you would have to code smart and probably hard to make your data entities accessible to Ditto and others...without overwhelming that document tree. (is this where concern also lies?)

I have thought about it too and thought maybe if one creates an unpublished document associated with a data item used by a snippet or module, then one can take full advantage of Ditto and others. But how would that affect viewing the items if they are unpublished documents?

I also thought we should have an extra field or enum in some future MODx version(s), that would allow a document to be either "normal" or "data item". Default would be normal. If it is a "data item", then snippets and modules can relate or link their data to the document, and perhaps it could also have an option to display or not display it in the document tree.
</brainstorm>

would any of this be wish-list-worthy?

ref: http://modxcms.com/forums/index.php/topic,38685.20.html

Take Ditto, etc. out of the equation. Those tools are for summarizing Resources (aka Documents), not custom database items. The whole point of externalizing database items is to create dynamic views (as Resources) including custom summarization views. Ditto would not apply, nor should it. IMO, Ditto is used way too much for solving problems beyond it’s intended purpose. And you can already link custom data to Resources via Template Variables and Plugins where necessary.

Using Resources to represent custom data is plausible if you have a limited quantity of data; otherwise, I’d create dynamic views of custom data tables.

Quote from: OpenGeek at Sep 02, 2009, 10:41 AM

Take Ditto, etc. out of the equation. Those tools are for summarizing Resources (aka Documents), not custom database items. The whole point of externalizing database items is to create dynamic views (as Resources) including custom summarization views. Ditto would not apply, nor should it. IMO, Ditto is used way too much for solving problems beyond it’s intended purpose. And you can already link custom data to Resources via Template Variables and Plugins where necessary.

Using Resources to represent custom data is plausible if you have a limited quantity of data; otherwise, I’d create dynamic views of custom data tables.

thanks for the feedback

the main reason I thought about it was that people do ask how to do use "Ditto etc" with a new snippet they review. For a relatively new person to MODx I was given the impression that having support for the likes of "Ditto etc" is desirable to seasoned users. So it did make me think about how to make that possible. One of the first pieces of code i read was TreasureChest. Well written or not, it made me wonder why product items were associated with documents. So I thought the best reason was being able to summarise and etc the products(through documents).

it was just a thought,anyways

I guess it releases us/me from that burden

(apologies to the OP if this is a digression )

Hello,

I implemented the idea I had as follows:

1) Changed the .htaccess file by adding the following
section just above the "The Frieldnly URLs part"

(There’s probably a better .htaccess construction, but this works and
is understandable)

2) Created a page called ’product’ with a "Document’s Alias" set to "product".
(This results in a product.html)

3) In that page called a snippet.
Snippet contents:




When I go to my site with the url


it goes to the product document and I see the full URL
in some of the $_SERVER vars. With that info I can go to the database
and ’do my thing’.

Bert,

Thanks for sharing.

With this method, you are not able to have several product listings or product summaries on one page, no? I imagine your code can be modified to achieve this though? Thx.

cheers/k

Hello Kogondo,

What do you mean with "several product listings" ?

The point is that I have the same MODX-Document for a whole range of URL’s.
In the snippet (in that Document) I can read out the URL and then do
what I want.

If the url is www.mysite.com/product/productlisting/lawnmowers.html I show a listing
of all lawnmowers.
If the url is www.mysite.com/product/productdetails/lawnmower/yamaha/xv13.html I show
the product details of that specific lawnmower.

It’s just a matter of detecting the second ’directory’ in the url, regarding that
as a ’keyword’ and based on that keyword make decisions.

It’s some sort of CMS within a CMS.

Bert,

Thats’ exactly what I meant and you have clarified it, i.e. how to list several "lawnmowers", etc. This is a very clever implementation that interests me. I hope you don’t mind me asking questions Something else I am wondering about, how do they get to those product urls. What I mean is that, I believe you have a products page with links that can be clicked to get you to lawnmowers, etc, etc. Since they are not real documents, are you using custom code to generate the links from your database (as opposed to Wayfinder doing the links)? Hope this one’s clear , thx.

cheers/k

Quote from: kongondo at Sep 03, 2009, 08:45 AM

Bert,

Thats’ exactly what I meant and you have clarified it, i.e. how to list several "lawnmowers", etc. This is a very clever implementation that interests me. I hope you don’t mind me asking questions Something else I am wondering about, how do they get to those product urls. What I mean is that, I believe you have a products page with links that can be clicked to get you to lawnmowers, etc, etc. Since they are not real documents, are you using custom code to generate the links from your database (as opposed to Wayfinder doing the links)? Hope this one’s clear , thx.

cheers/k

hi k

I think Bert does use links generated from the database. Not knowing how the URL is generated, typically, it could look something like this

www.mysite.nl/?product=lawnmower&type=yamaha&model=XV13

I would also be interested in a further explanation on the snippet part and where and how you make use of the server variables to generate a DB query. It would solve a problem i had with my dormant but alive shopping script...