By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,472 Members | 1,270 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,472 IT Pros & Developers. It's quick & easy.

content manager without MySql

P: n/a
Hi folk

I would like to setup a website for someone where they can change some
content themselves (list of concerts).

The obvious choice is to use PHP and MySql, but is there a way to do it
without MySql. It will save me about US$15.00 per months, is it worth the
hassle?

Keen to hear your thoughts

- Nicolaas
Jul 17 '05 #1
Share this Question
Share on Google+
6 Replies


P: n/a
windandwaves wrote :
Hi folk

I would like to setup a website for someone where they can change some
content themselves (list of concerts).

The obvious choice is to use PHP and MySql, but is there a way to do it
without MySql. It will save me about US$15.00 per months, is it worth the
hassle?

Keen to hear your thoughts

- Nicolaas


You could use flat files for your content, and have some kind of
template mechanism that _marries_ these files with _placeholders_ in
your html templates.

eg....

aboutme.html contains somthing like this....

<body>
{PAGE_CONTENTS}
<div id="menu">
{STANDARD_MENU}
</div>
<div id="pagemenu">
{ABOUTME_MENU}
</div>
{STANDARD_FOOTER}
</body>
....and your flat file could be called...
aboutme.menu.inc
and
aboutme.contents.inc
....
you could then fopen() these files depending on the page name, eg
"aboutme", the simply write to these files when your done.

then the contents of these could simply replace the placeholders in
your html page at runtime.

then you could go several level of include stuf, eg the aboutme.men.inc
could include another file "standard.menu.inc", and this could contain
references to each page in a partticular folder, etc..

--
a beef jerky web site : http://www.choicebeefjerky.com.au
not a beef jerky web site : http://mycoolfish.com/vote.cmks
if you pay for your gym memebership, use it

Jul 17 '05 #2

P: n/a
Disco Octopus wrote :
windandwaves wrote :
Hi folk

I would like to setup a website for someone where they can change some
content themselves (list of concerts).

The obvious choice is to use PHP and MySql, but is there a way to do it
without MySql. It will save me about US$15.00 per months, is it worth the
hassle?

Keen to hear your thoughts

- Nicolaas

Oh. BTW. to answer your question "is mySql worht it?" I say yes.
however, you may be able to find a cheaper rate then $15 per month.

--
a beef jerky web site : http://www.choicebeefjerky.com.au
not a beef jerky web site : http://mycoolfish.com/vote.cmks
talk to the teacher now and then about something other than the subject

Jul 17 '05 #3

P: n/a
Disco Octopus wrote:
Disco Octopus wrote :
windandwaves wrote :
Hi folk

I would like to setup a website for someone where they can change some
content themselves (list of concerts).
<snip>
Keen to hear your thoughts

- Nicolaas

Oh. BTW. to answer your question "is mySql worht it?" I say yes.
however, you may be able to find a cheaper rate then $15 per month.


The most valuable static component of most websites is likely to be its
data. You need to a safe place to keep it. The next most valuable component
is the code. If I were you I'd consider writing the code to use the dbx_
functions. Then implement the site using SQLlite (i.e. DBMS-less data
access, but via SQL). If at a later date you think it's worth the $15, or
you find a better hosting deal ($15 extra JUST for MySQL????) then it
should be a lot less painful to switch.

HTH

C.
Jul 17 '05 #4

P: n/a
Colin McKinnon wrote:
Disco Octopus wrote:
Disco Octopus wrote :
windandwaves wrote :
Hi folk

I would like to setup a website for someone where they can change
some content themselves (list of concerts).
<snip>
Keen to hear your thoughts

- Nicolaas

Oh. BTW. to answer your question "is mySql worht it?" I say yes.
however, you may be able to find a cheaper rate then $15 per month.


The most valuable static component of most websites is likely to be
its data. You need to a safe place to keep it. The next most valuable
component is the code. If I were you I'd consider writing the code to
use the dbx_ functions. Then implement the site using SQLlite (i.e.
DBMS-less data access, but via SQL). If at a later date you think
it's worth the $15, or you find a better hosting deal ($15 extra JUST
for MySQL????) then it should be a lot less painful to switch.

HTH

C.


Thank all of you. I think I am going to stick with MySql, because it sounds
like PHP does not really have its own DB system and I can just imagine the
thing mushrooming....
Jul 17 '05 #5

P: n/a
why spend $180 / year if you don't have to to? Start simple and build
in the complexity when you have to. Sometimes you'lll be surprised how
far the simple and cheap solutions will take you. You're just wasting
your time and money if you start with a complex solution to a very
simple problem. these are just my words of advice. i am no expert, but
as an engineer I can't stand to see someone build the 1$ bridge for
$10.

for your problem of updating a list of concerts all you need is a
simple script that reads the concert list file and displays it on the
webpage. If the edit flag is turned on like

myscript.php?user_wants=edit

then you just display the concert list inside of a textarea field like
this perl code below:

open(F, $file_path) or die "could not open '$file_path' $!";
flock(F, 2); # lock file

print"<form action=/myscript.php method=POST>

<textarea name=message cols=75 rows=20>";

if ($password eq $pass & defined $user_wants){ print <F>;}

print"</textarea>";

Then some code like this to finish it off:

close(F);

echo '<CENTER><P><b> Enter Password:</b> <input type="password"
name="password">

<input type="radio" name="user_wants" value="display" checked>
Display/ Edit Page
<input type="radio" name="user_wants" value="edit"> Save Changes';

print"<input type=hidden name=file_path value=$in_file_path>";
print"<input type=hidden name=referer value=$referer>";
print"<input type=hidden name=passwords_list
value=$in_passwords_list>";

print'<p> <input type="submit" value="Submit/ Update"> <p> ';

Spend the $180 per year when the above is no longer a solution as your
files are several MB large AND you have customers ready with these
large files.

Jul 17 '05 #6

P: n/a
el*************@yahoo.com wrote:
why spend $180 / year if you don't have to to? Start simple and build
in the complexity when you have to. Sometimes you'lll be surprised how
far the simple and cheap solutions will take you. You're just wasting
your time and money if you start with a complex solution to a very
simple problem. these are just my words of advice. i am no expert, but
as an engineer I can't stand to see someone build the 1$ bridge for
$10.

for your problem of updating a list of concerts all you need is a
simple script that reads the concert list file and displays it on the
webpage. If the edit flag is turned on like

myscript.php?user_wants=edit

then you just display the concert list inside of a textarea field like
this perl code below:

open(F, $file_path) or die "could not open '$file_path' $!";
flock(F, 2); # lock file

print"<form action=/myscript.php method=POST>

<textarea name=message cols=75 rows=20>";

if ($password eq $pass & defined $user_wants){ print <F>;}

print"</textarea>";

Then some code like this to finish it off:

close(F);

echo '<CENTER><P><b> Enter Password:</b> <input type="password"
name="password">

<input type="radio" name="user_wants" value="display" checked>
Display/ Edit Page
<input type="radio" name="user_wants" value="edit"> Save Changes';

print"<input type=hidden name=file_path value=$in_file_path>";
print"<input type=hidden name=referer value=$referer>";
print"<input type=hidden name=passwords_list
value=$in_passwords_list>";

print'<p> <input type="submit" value="Submit/ Update"> <p> ';

Spend the $180 per year when the above is no longer a solution as your
files are several MB large AND you have customers ready with these
large files.

Thank you for this superhelpful reply. I totally agree with keeping it
simple is usually the best way.

Thanks again
Nicolaas
Jul 17 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.