Thanks guys...I'm doing a

newperson — Tue, 10 Mar 2009 18:20:13 +0000

Thanks guys...I'm doing a lot of reading and I'm sure I'll have questions in the near future!

The links Decibel gave are

greg — Mon, 09 Mar 2009 11:56:20 +0000

The links Decibel gave are good for you to start with, I would also like to mention www.tizag.com. It's "as good as" w3schools, but using both simultaneously can help as the slight difference can be enough for you to grasp something difficult.

____

decibel.places wrote:

where are you getting this Drupal argument, from drupal.org?

http://drupal.org/node/21809

decibel.places wrote:

don't worry, greg and I disagree about lots of stuff about which we are usually both right :P

Hmm, I don't think so, probably have to disagree with you on that one....

@newperson, don't worry,

decibel.places — Sun, 08 Mar 2009 22:42:36 +0000

@newperson,

don't worry, greg and I disagree about lots of stuff about which we are usually both right

there are lots of Drupal books (but I cannot recommend any in particular), good video tutorials on lynda.com and more on drupal.org http://drupal.org/handbook/customization/videocasts

there is also a Drupal Cookbook for Beginners, a good place to start http://drupal.org/handbook/customization/tutorials/beginners-cookbook

Don't forget to look at Drupal Taxonomy (Categories) http://www.w3schools.com/php/php_mysql_intro.asp

and The Power of Drupal Categories http://digitalsolutions.ph/couchkamotereviews/power_drupal_categories

Regarding learning databases and MySQL, take a look at W3Schools SQL tutorial http://www.w3schools.com/sql/default.asp and PHP/MySQL http://www.w3schools.com/php/php_mysql_intro.asp

If anything comes up, come back and ask!

greg and decibel.places,

newperson — Sun, 08 Mar 2009 19:22:54 +0000

greg and decibel.places, thank you for your responses!

As I've never built a database or dealt with Drupal, I will have to take some time to study up on both. I take it if I choose to create a database that I could use MySQL? I'll have to get a book on that then.

Also, on a separate tangent: I have dealt with Simple Machines Forum (SMF) software in the past, along with using TinyPortal as the portal. So, my idea was to have a message board (with its own search capabilities just within the board as SMF does), and use TinyPortal to create these other pages around the SMF software, and then have a search functionality for these other pages... Is this even possible? And if it is, what should I start with? I guess with SMF and creating search funtionality within the site, I would have two separate databases? And somehow integrate this second database...?

Any book recommendations where I can begin to digest this stuff?

Again, thank you for the replies.

-newperson

greg wrote: decibel.places

decibel.places — Sun, 08 Mar 2009 17:43:46 +0000

greg wrote:

decibel.places wrote:

Instead of worrying about database architecture, use Drupal's Taxonomy feature

You say that as if Drupal makes everything easy, arguably "easier" perhaps, but not easy.

Which is easier, configuring a CMS like Drupal or learning to run custom queries on a custom database?

Yes, there are some situations where I might roll my own site, but that requires a steeper learning curve than using Drupal.

I did not recommend Drupal automatically - but rather as a quite specific solution for this question.

greg wrote:

Drupal.org - "Rolling your own system wrote:

Drupal.org - "Rolling your own system vs. using Drupal wrote:

...it is fairly easy to roll your own modules. This is typically done by making a file with some functions implementing certain hooks in addition to other functions.

How is making files and functions and hooks "EASY" to someone who doesn't code?
It's not really a point and click then is it?

where are you getting this Drupal argument, from drupal.org?

I do not think any custom hooks and functions are required for a straightforward taxonomy structure - just a little logic.

Drupal.org - "Rolling your

greg — Sun, 08 Mar 2009 16:07:00 +0000

Drupal.org - "Rolling your own system vs. using Drupal" wrote:

A reason for rolling your own system might be to have it fit your needs exactly. However, Drupal is designed to fit a range of needs...

Which just cries out - "Code installed that you wont ever use".
So it might have loads of stuff built in, but in its own argument it's not as good as hard coding.

decibel.places wrote:

Instead of worrying about database architecture, use Drupal's Taxonomy feature

You say that as if Drupal makes everything easy, arguably "easier" perhaps, but not easy.

People keep piping that Drupal/Wordpress etc can save you the hassle of coding a site, but it's not just as simple as "it's an alternative to those who can't and don't want to code".
Out-the-box it's not an alternative if you have specific requirements, or have to add modules, or style templates. There is still a large learning curve for its usage.

Styling is still to be hard coded, yes there are templates available and easy to install, but then your site looks like someone else's site.

It's not as flexible out-the-box as hard coding your own site.
It can be, but you then have to code your own modules which have to be tested and security checked, and then not only do you need the ability to hard code as well as learn Drupal, but you have to apply your code to work correctly WITH Drupal....

Drupal.org - "Rolling your own system vs. using Drupal" wrote:

...it is fairly easy to roll your own modules. This is typically done by making a file with some functions implementing certain hooks in addition to other functions.

How is making files and functions and hooks "EASY" to someone who doesn't code?
It's not really a point and click then is it?

I know there are pre-coded modules, but they might not fit your exact requirements, even if they do, they have to be installed, and modules and Drupal itself have to be updated and managed.

Don't forget, it might be easy for you, and you could install Drupal modules and make sites with Drupal in your sleep, but to someone else it's not that simple.

I do agree that Drupal is great, and I don't want to put you off it newperson. I truly am not biased against Drupal and it can make life easier, and out-the-box it will serve the purpose for most people.
I just wanted to explain the reality of using Drupal, any CMS for that matter.

You certainly should consider it and investigate the option.

al ... Drupal ... Drupal ...

decibel.places — Sun, 08 Mar 2009 14:31:35 +0000

al ... Drupal ... Drupal ... Drupal ... Drupal ... Drup

This would be a good situation to use Drupal

Instead of worrying about database architecture, use Drupal's Taxonomy feature (for tree-like category structures) http://drupal.org/handbook/modules/taxonomy

Faceted search provides great filtering http://drupal.org/project/faceted_search

Google Custom Search is pretty good too http://drupal.org/project/google_cse

It would really depend very

greg — Sun, 08 Mar 2009 13:01:22 +0000

It would really depend very much on your site structure and content.
Here is a basic idea and usage of a database with all your content data in it, and how it allows users to search for that data...

There could be anomalies/flaws in the following structure/advice, but as you are asking the basics, I've just quickly written some examples to give you a basic idea of the way it's all done.
You will need to plan more carefully the layout of the database and tables.
(I state quickly written..but it's turned out more like a huge tutorial..)

Say we make a Database with THREE tables.
____________________

TABLES:

Table - ACTORS/ACTRESSES
In there you would have things like: ACTOR_REF - NAME - AGE - TOTAL_FILMS - AWARDS - DETAILS
"DETAILS" would be a text field, with things like "This actor started his career in 1978, in a film called.." etc

Table - FILMS
In there you would have things like: FILM_REF - FILM_NAME - FILM_TYPE - RELEASE_DATE - AWARDS - DIRECTOR - DETAILS

Table - FILMS_ACTORS
This would be a list of all ACTORS/ACTRESSES and the films they have been in
ACTOR_NAME - ACTOR_REF - FILM_NAME - FILM_REF

the xx_REF in each table allows you to match certain things from one table to another.
So getting ACTOR_REF from ACTORS/ACTRESSES table, you can use the ACTOR_REF to search the FILMS_ACTORS table for all films that actor/actresses has done.
Same with FILM_REF. Searching the FILMS_ACTORS table with that ref gets all the ACTORS in that FILM.
____________________

SEARCHING:

Immediately you have searchable fields:
Search the FILMS table:
- list all where FILM_TYPE = "action".
- list all where AWARDS = "BAFTA".

You can allow users to choose from multiple search criteria:
list all where FILM_TYPE = "action" AND AWARDS = "BAFTA"
Results - All action films that won a BAFTA award

Another useful one:
Search the FILMS_ACTORS table:
list all where NAME = "harrison ford"
All films he's been in.
Would access the FILMS_ACTORS table, get all rows that matched "harrison ford" and list each film he has been in.

____________________

SHOWING RESULTS AND LINKS TO AND FROM FILMS AND ACTORS

You can have two pages, one that shows FILM details, and one that shows ACTOR details.
ACTOR: actor_data.php
FILM: film_data.php

When a user searches, for example all films with harrison ford in, it would search the FILMS_ACTORS table and get all data.
The result would be: NAME - HARRISON FORD, and a list of all films found in the table.

Each of his films listed would be a link to the page (film_data.php) that would show data for that film.

Say the FILM_REF obtained from the FILMS_ACTORS table search was XYZ, clicking that film (link) would go to film_data.php and send the "XYZ" in the URL.
(link would look like film_data.php?film_ref=XYZ. Of course XYZ would be a variable as it could be any ref from any film)

film_data.php would get the "XYZ" from the URL, search the FILMS table, match XYZ to the film row and list all data for that film.

On that page (film_data.php) the page would show all actors, and all actors names for that film. Each name would be a link to actor_data.php page to show details for that actor.

The actor links would work the same as the film links -
The link would be the ACTOR_REF from the DB search,the URL data (ABC). Then the actor_data.php would get the URL data, search the ACTORS_ACTRESSES table, match ABC and display all data for that actor/actress.

And AGAIN, all films listed would be links to the page to show film data for that link.
Linking ALL data together and all accessible, clickable and searchable!

____________________

Sounds complicated, but once you get rolling it really all falls into place.

So from that you can see the sort of thing you need to do.
REALLY plan and design it on paper first though, it's a pain changing tables, field etc each time you think of an improvement or addition.

Also, view other similar sites to see what they provide

Think about questions like the following and make a list for each of them.
- What data / content will you provide? - film name, film plot, etc
- What do you want to allow users to search by? - actor name, film type, etc
- What options in the search do you want to provide? - search by all/any, list by order of date, alphabetical first/last name, etc

Once you have on paper what information you will provide for each film and actor, then you can design a database to house it all. Designing the DB with the search options in mind of course.