database-generated dynamic content with c5?

Permalink
I'm an experienced software developer but a concrete5 newbie.
I just inherited responsibility for the website of a nonprofit,
built/maintained in c5. I can modify the existing website, no problem.
I'm moving the nonprofit's print archive to digital form,
using PHP pages I wrote to maintain a MySQL database (outside of c5).
I'd like to have the c5-based website access the archive database
to generate dynamic content. Is there a reasonably clean way to do so,
or do I just kludge something together with duct tape and bailing wire?

 
JohntheFish replied on at Permalink Reply
JohntheFish
I am about to close down for the night, but to get you started read up on single pages. Create a single page that takes care of a whole branch of the external content beneath it
mesuva replied on at Permalink Reply
mesuva
You can access other databases using concrete5's database library:
http://www.concrete5.org/documentation/developers/system/database-c...

You'd probably want to set up one more 'single pages' in your system, this gives you the ability to use a MVC pattern.
http://www.concrete5.org/documentation/how-tos/developers/build-a-s...
(Scroll down to the heading 'Creating the single page')

The other option is you create some custom blocks that pull in the data manually.

This might be a good starting point:http://www.concrete5.org/documentation/introduction/model-view-cont...

Once you dig into it, the concrete5 API is very strong and there is a huge amount of functionality built in.
mkly replied on at Permalink Reply
mkly
Excuse my slowness, but by "print archive" you are talking about photographs or art print I'm guessing. Not like print articles.

If that's the case you have some options. I'm guessing your database is already created and you want to keep that? If so you would be happy to know that Concrete5 is MVC based. You can create a Print Model(in the models directory) and do all of you database sets and gets from that abstracting your additional database away from kludgetopia.

Then you would be happy to know that concrete5 has this concept of what are known as "single pages" These are pretty much anything goes pages that essentially get wrapped in the theme(typically a header a footer and maybe a sidebar). You would probably end up making one or more of these to be the main search and display of your photographs. On that note you probably look into the DatabaseItemList class as opposed to raw sql, but the choice is yours.

You could also create additional "Blocks" for displaying certain pictures in other parts of the site, like the landing page or other clever spots you might think of. Blocks are also somewhat MVC-ish and you can use your Print Model you created up above for those as well.

I see you have already gotten a couple good links and suggestions, so I'm sure you'll have some questions later on. No cms is kludge free but concrete5 certainly has quite a few anti-kludge powers.
benhecht replied on at Permalink Reply
Thanks much for the extremely quick replies (three within an hour of my posting).
I'll dig into single pages and follow up on the other posted links and let you know
of my progress.

The organization I'm doing this for has been around for 27 years.
We have hard-copy binders with interesting info dating back to the beginning,
computer-based files dating back a decade or so, and 20+ years of audio
in various formats. The website currently describes the present adequately,
but I'm looking to incorporate the past in a structured fashion.
jordanlev replied on at Permalink Reply
jordanlev
I think single_pages are *probably* the way to go here because you have so much legacy data and I assume you already have functioning code to pull it out of its database and transform/display it.
But since you're new to C5 I want to suggest that if it's possible to put your archived content into the C5 site itself and make them actual pages and part of the sitemap, that will be a better situation because it then fits in with the rest of the system. C5 revolves around pages and the more you can make things individual pages, the better. For example, if you have them as their own pages of content, you get this automatic functionality out of the box without having to code anything:
* search functionality
* version history (which may not apply if nobody is ever changing this historical content)
* security/permissions (again, maybe doesn't apply to your situation)
...and probably some others I'm not thinking of.

I don't know the specifics of your situation, so I'm not suggesting you go this route, but I did want to explain the benefits of it so you can make a more informed decision. If you do want your legacy content to be imported as actual C5 pages, then your task changes from creating a page to query the database and display content (which is what you'd do with a single_page) to a one-time import script that programmatically generates C5 pages and puts content blocks in their areas.

Let me know if you need some more pointers about either of these approaches.

PS: Congratulations -- you've managed to get the 4 smartest and best-looking people in the C5 community to respond to your question :)
benhecht replied on at Permalink Reply
[jordanlev writes:]
> PS: Congratulations -- you've managed to get the 4 smartest and best-looking people in the C5 community to respond to your question :)

Plus me makes 5.

I see your point re single pages vs. actual pages for underlying content, but I'm skeptical.
One part of my project involves an audio archive, currently ca. 10G in a few hundred
.m4a files, some of them large (>64M), reasonably well organized. I can upload
these outside of c5 with a single scp -p command and end up with the tree-structured
archive I want, albeit outside of c5's purview. Can the c5 File Manager do that
without considerable effort on my part? More power to it if it can, and I'll be glad
to use it. But I see a "64M max size" limitation, for starters...
jordanlev replied on at Permalink Reply
jordanlev
You're absolutely correct -- it *will* require considerable effort on your part. I don't know the detail of your operation so I can't judge if it's worth it, but based on what you're saying it's probably not. So single_pages are still probably the best way to go, but I just wanted to mention the other option since you're new to C5 (in my opinion it's an important concept to understand about the system, even if you then choose to bypass it -- at least it's an informed decision in that case).
mkly replied on at Permalink Reply
mkly
If you really really really want to control everything, a CMS in general is a terrible path to go on.

Attaching a file to a "page" isn't really a big deal. If you really want to spend time thinking about how cool it is to know about scp then you are probably better off building this part with something like code igniter/zend (Zend is easier to hook into in c5) than to attempt to work within any CMS type situation. Then just spending your time hooking them together.

CMS's are not at all designed for developers to do whatever they want. They are designed for end users to do as much as possible with very little knowledge. To use them as a developer you have to work with them not against them.

Concrete5 has ways to do all of what you want, but it feels like you are already upset about having to deal with it in the first place which will inevitably lead to frustration and failure.
JohntheFish replied on at Permalink Reply
JohntheFish
Even to upload them using php outside of C5 you you will need to do some reconfiguring of php to upload them. As you say, maybe copy the big files of your archive to a structure to the server outside of C5.

Then have a think around importing a description with all the metadata for each into C5, either as a content block or as a text file via the file manager. That would give you the search functionality. Then you need to tie a link from that to a player (the single page? or are the files compatible with one of the existing player blocks and addodns?)
JohntheFish replied on at Permalink Reply
JohntheFish
My personal preference is to create a package with the single page. Packages need a bit more work to install, but overall I find packages easier to manage than root level overrides, even if I only use them once.