Data Modeling Question
Permalink
Hello all,
I am new to Concrete5 and seeking advice on designing the data model for my website. The prototype for the site is currently built using hardcoded html/css, javascript and jquery. Before I started looking at Concrete5 I envisioned the system working off a set of related tables in MySQL with XML files storing GPS data.
After spending considerable time reading the Concrete5 documentation and forum entries I am now unsure of the best approach for storing the data, specifically whether I should utilize custom page attributes versus blocks with underlying MySQL tables.
The website application contains detail information on hiking trails by location. Locations will be defined by region and within each region by towns within driving distance to the trailhead. (Trails within easy driving distances of two towns will be cross listed in each location.)
Each trail includes basic overview information (distance, trailhead elevation gain, difficulty, nearest town(s), etc.), a detailed trail description and GPS information such as the longitude and latitude of the trailhead, gps coordinates for trail photos and gps tracks of the trail. The GPS information is used to create google maps.
(Detailed GPS data for trail tracks and photos markers are stored in xml files. The XML files for the photos include not only the gps coordinates but also photo descriptions and photo file names. The naming convention for the XML files includes the trail name to facilitate programmatic selection of the XML files. My current plan is to continue using the XML files for storing the GPS information.)
Users will be able to select trails from a page list for each location or by clicking markers on a google map. In the future I may incorporate search criteria based on distance and/or difficulty level.
There will be three pages for each trail:
1) A main trail page including a featured photo, trail overview information, a short description and a google map showing the trail.
2) A detailed trail description page
3) A photo gallery page (that works interactively with a google map that includes the trail track and markers for the photos).
While searching through the forums I have seen examples of several applications that store all the data required for a given page in the page’s custom attributes as opposed to blocks with underlying MySQL data structures.
Can someone please explain the advantages and/or disadvantages of storing/retrieving data using custom attributes as opposed to blcoks with underlying MySQL tables? Are there performance issues with regard to rendering the page? Is it easier (or smarter) to store data in custom attributes if the data is required for the processing (javascript) required to render the page (i.e a google map) or producing page lists?
Are there any downsides to storing all the data for a page in custom attributes (for example: is it more difficult/inefficient to search the data, etc.)? Any other considerations?
Please feel free to point me toward any documentation or forum postings on this topic I might have missed.
Any advice is sincerely appreciated.
Thank you.
I am new to Concrete5 and seeking advice on designing the data model for my website. The prototype for the site is currently built using hardcoded html/css, javascript and jquery. Before I started looking at Concrete5 I envisioned the system working off a set of related tables in MySQL with XML files storing GPS data.
After spending considerable time reading the Concrete5 documentation and forum entries I am now unsure of the best approach for storing the data, specifically whether I should utilize custom page attributes versus blocks with underlying MySQL tables.
The website application contains detail information on hiking trails by location. Locations will be defined by region and within each region by towns within driving distance to the trailhead. (Trails within easy driving distances of two towns will be cross listed in each location.)
Each trail includes basic overview information (distance, trailhead elevation gain, difficulty, nearest town(s), etc.), a detailed trail description and GPS information such as the longitude and latitude of the trailhead, gps coordinates for trail photos and gps tracks of the trail. The GPS information is used to create google maps.
(Detailed GPS data for trail tracks and photos markers are stored in xml files. The XML files for the photos include not only the gps coordinates but also photo descriptions and photo file names. The naming convention for the XML files includes the trail name to facilitate programmatic selection of the XML files. My current plan is to continue using the XML files for storing the GPS information.)
Users will be able to select trails from a page list for each location or by clicking markers on a google map. In the future I may incorporate search criteria based on distance and/or difficulty level.
There will be three pages for each trail:
1) A main trail page including a featured photo, trail overview information, a short description and a google map showing the trail.
2) A detailed trail description page
3) A photo gallery page (that works interactively with a google map that includes the trail track and markers for the photos).
While searching through the forums I have seen examples of several applications that store all the data required for a given page in the page’s custom attributes as opposed to blocks with underlying MySQL data structures.
Can someone please explain the advantages and/or disadvantages of storing/retrieving data using custom attributes as opposed to blcoks with underlying MySQL tables? Are there performance issues with regard to rendering the page? Is it easier (or smarter) to store data in custom attributes if the data is required for the processing (javascript) required to render the page (i.e a google map) or producing page lists?
Are there any downsides to storing all the data for a page in custom attributes (for example: is it more difficult/inefficient to search the data, etc.)? Any other considerations?
Please feel free to point me toward any documentation or forum postings on this topic I might have missed.
Any advice is sincerely appreciated.
Thank you.
John, thanks for your quick reply. I will start exploring collections in more detail.
Can you provide an example of a c5 addon that uses pages (collections) as a data store to share data between blocks? I find examples very helpful in extending my understanding Concrete5.
My mapping applications are already built in javascript and need to be ported to C5. My hope is that I can extend one of the existing google map block controllers instead of starting from scratch. (Before I begin that work I want to get my data structures set.)
Thanks for taking the time to answer my question.
Can you provide an example of a c5 addon that uses pages (collections) as a data store to share data between blocks? I find examples very helpful in extending my understanding Concrete5.
My mapping applications are already built in javascript and need to be ported to C5. My hope is that I can extend one of the existing google map block controllers instead of starting from scratch. (Before I begin that work I want to get my data structures set.)
Thanks for taking the time to answer my question.
The discussion forums addon definitely does. Pro blog and pro events may do so.
When adding your jQuery to map blocks, you may find this trick useful:
http://www.concrete5.org/documentation/how-tos/developers/improve-r...
(Most map blocks suffer from this, except for Formigo Directions which already has it built in. The Formigo code is very clean and may be a good starting point)
When adding your jQuery to map blocks, you may find this trick useful:
http://www.concrete5.org/documentation/how-tos/developers/improve-r...
(Most map blocks suffer from this, except for Formigo Directions which already has it built in. The Formigo code is very clean and may be a good starting point)
Blocks don't have attributes.
Where the relationship of some data within a block becomes 1:many or that block data is also used by other blocks, then you usually need to code a separate table, which then entails keeping it in track with block versions.
Many c5 addons use pages (collections) as a data store (often to share data between blocks), even when the page is never actually shown. This allows any data item to have flexible attributes attached to it and for page searching and listing to extract the information to where it is wanted.
For your application I would start by thinking of each trail as a page with an optional number of sub pages. Autonav blocks on the trail page will take care of the sub pages. Where you have duplicated trails, you can use a stack, or the Global Areas or Parent Area block, so you maintain it in one place, but show it (and index it) in many.
Above the trail pages, you can index, catalogue and navigate with page list blocks or search results blocks (or the many improved versions of such available). Use page attributes when you want to be able to filter on specific criteria.
There are already several maps based blocks with geolocation and distances. Or you could look at some of the higher level applications available and adapt them.