473,322 Members | 1,510 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,322 software developers and data experts.

Coding suggestions for easy maintenance by non-coders

JW
I'm displaying product thumbnails with brief descriptions on web pages. Clicking
on the product does a javascript popup with larger image and detailed
description info passed to the javascript functions from the table data.

Products can change frequently, and I want to make the maintenance of this
info easier by non-techies (each product has an image name, image width
(currently not using getimagesize), a short description, and a long
description). Can't devote major time to this; using a MySQL database to store
the data is currently not feasible because of the time to create the
administrative interface.

There are two methods that I have been playing with, neither of which I'm crazy
about from the maintenance aspect.

===============================================
Method 1 to display image - hard coded info in table, no php:

<td width="25%" align="center">
<a href="javascript:popUp('prod1/12345.jpg','long product description
text','300');">
<img src="prod1/12345_t.jpg" width="75" border=0></a>
<br>
<div id="productdescription">
prodcode<br>product text
</div>
</td>

Problem is that it's too hard to find the pieces to modify and to easy to screw
up by Joe Noncoder.

===============================================
Method 2 to display image using php:

<?php
// section preceding each TD element has unique product info
$filename="12345";
$thumbline_1="prodcode";
$thumbline_2="product text";
$longdesc="long product description text";
$imgsize=300;
?>

<?php
// functions not shown for brevity
$popinfo = buildpopup($filename, $longdesc, $imgsize);
$thumbnail = buildthumbnail($filename);
?>

<td width="25%" align="center" valign="top">
<a href="javascript:popUp(<?php echo $popinfo; ?>);">
<img src=<?php echo $thumbnail; ?> width="75" border=0></a>
<br>
<div id="productdescription">
<?php echo $thumbline_1 . "<br>" . $thumbline_2; ?>
</div>
</td>

The second method is a bit easier to maintain for an end user, only because the
data to modify is clearly delineated.

===============================================

Another possibility is to have separate include files for each product, but it
could be more unwieldy to deal with 300 or so separate product files.

I'm probably overlooking something more obvious. Other suggestions appreciated!

jw
--
jd**@nospamforme.com
Jul 17 '05 #1
6 2182
JW wrote:

I'm probably overlooking something more obvious.
Other suggestions appreciated!


Use a database for the image metadata, with a simple, idiot-proof admin
page. It's a simple table, it should be a quick task and it'll save you
headaches later.

bblackmoor
2004-10-30
Jul 17 '05 #2
JW wrote:

I'm displaying product thumbnails with brief descriptions on web pages. Clicking
on the product does a javascript popup with larger image and detailed
description info passed to the javascript functions from the table data.

Products can change frequently, and I want to make the maintenance of this
info easier by non-techies (each product has an image name, image width
(currently not using getimagesize), a short description, and a long
description). Can't devote major time to this; using a MySQL database to store
the data is currently not feasible because of the time to create the
administrative interface.

There are two methods that I have been playing with, neither of which I'm crazy
about from the maintenance aspect.

===============================================
Method 1 to display image - hard coded info in table, no php:
Problem is that it's too hard to find the pieces to modify and to easy to screw
up by Joe Noncoder.
I agree 100%. It's also too easy to screw up for a seasoned programmer,
especially for the 300+ pages you mention below. And changing the format is a
real bitch. You always end up with missed files and broken links. A major pet
peeve of mine is working on other people's HTML mixed with my PHP, especially
when they use FrontPage or other WYSIWYG editor.
===============================================
Method 2 to display image using php:

<?php
// section preceding each TD element has unique product info
$filename="12345";
$thumbline_1="prodcode";
$thumbline_2="product text";
$longdesc="long product description text";
$imgsize=300;
?>

<?php
// functions not shown for brevity
$popinfo = buildpopup($filename, $longdesc, $imgsize);
$thumbnail = buildthumbnail($filename);
?>

<td width="25%" align="center" valign="top">
<a href="javascript:popUp(<?php echo $popinfo; ?>);">
<img src=<?php echo $thumbnail; ?> width="75" border=0></a>
<br>
<div id="productdescription">
<?php echo $thumbline_1 . "<br>" . $thumbline_2; ?>
</div>
</td>

The second method is a bit easier to maintain for an end user, only because the
data to modify is clearly delineated.
If you choose this route, you may want to consider arrays in an include file.
Code (HTML or PHP) is confusing enough for non-coders. I wouldn't make them
sift through all of it if they only need to deal with a small part. Give them
written instructions on how to deal with ' or ", whichever quote you use. And
I'd put 2 copies of the file - a live one and a dev one. Give them instructions
on how to update and FTP the dev file. Write a very quick script that includes
the dev file, and, if there are no errors, replace the live file. This could be
written very quickly. And you may also want to make an auto-archive feature
(copy old file to archive directory as "name-".time().".txt"), assuming there
won't be daily/hourly/ changes and you have room for dozens/hundreds of copies
of the "database".
Another possibility is to have separate include files for each product, but it
could be more unwieldy to deal with 300 or so separate product files.
Of course, if you wanted a product list, you'd have to open all 300 files, read
the product name, and close them (unless you used the filename to store product
name). But this does have the advantage that, if they screw something up, they
will only screw up one product.
I'm probably overlooking something more obvious. Other suggestions appreciated!


One thing I did years ago was let a client maintain an Excel (which they already
knew how to use) spreadsheet of their products. They exported as a delimited
file (tab or comma), uploaded to server and my Perl script took it from there.
If you choose to do this, you might want to make a quick script that does some
low-level checking (make sure images named in file actually exist on server,
make sure all required fields are filled out, etc.) and just print the errors to
an admin page -- nothing fancy, but would save client trouble of clicking
through 300 pages.

But basically, I think you'll find that there's no magic solution to avoiding
making an admin interface. Though I would love to be proved wrong on this
point...

There will always be concessions when allowing the client to edit their site
with no interface. The biggest one is the inevitable errors and the
corresponding panicked phone calls. But you also have to train them,
troubleshoot their mistakes and train them again, accept that they're not going
to be as happy with it as they would be with an interface (and your
word-of-mouth suffers).

Whatever system you go with, make sure the server has a very good backup
system. All the methods above enable the client to seriously mess things up.

Regards,
Shawn

--
Shawn Wilson
sh***@glassgiant.com
http://www.glassgiant.com
Jul 17 '05 #3
JW <jd**@nospamforme.com> wrote in message
news:<s5********************************@4ax.com>. ..

I'm displaying product thumbnails with brief descriptions on web pages.
Clicking on the product does a javascript popup with larger image and
detailed description info passed to the javascript functions from the
table data.

Products can change frequently, and I want to make the maintenance of
this info easier by non-techies


Then treat the maintainers accordingly. Wirte an administrative
interface and make sure every maintenance task can be done via
that interface and no manual fiddling with server-side files is
required.

Cheers,
NC
Jul 17 '05 #4
JW
Shawn Wilson <sh***@glassgiant.com> wrote:
JW wrote:
(snip)
Products can change frequently, and I want to make the maintenance of this
info easier by non-techies (each product has an image name, image width
(currently not using getimagesize), a short description, and a long
description). Can't devote major time to this; using a MySQL database to store
the data is currently not feasible because of the time to create the
administrative interface.

===============================================
Method 1 to display image - hard coded info in table, no php:
Problem is that it's too hard to find the pieces to modify and to easy to screw
up by Joe Noncoder.


I agree 100%. It's also too easy to screw up for a seasoned programmer,
especially for the 300+ pages you mention below. And changing the format is a
real bitch. You always end up with missed files and broken links. A major pet
peeve of mine is working on other people's HTML mixed with my PHP, especially
when they use FrontPage or other WYSIWYG editor.
===============================================
Method 2 to display image using php:
(snip)
The second method is a bit easier to maintain for an end user, only because the
data to modify is clearly delineated.


If you choose this route, you may want to consider arrays in an include file.
Code (HTML or PHP) is confusing enough for non-coders. I wouldn't make them
sift through all of it if they only need to deal with a small part. Give them
written instructions on how to deal with ' or ", whichever quote you use. And
I'd put 2 copies of the file - a live one and a dev one. Give them instructions
on how to update and FTP the dev file. Write a very quick script that includes
the dev file, and, if there are no errors, replace the live file. This could be
written very quickly. And you may also want to make an auto-archive feature
(copy old file to archive directory as "name-".time().".txt"), assuming there
won't be daily/hourly/ changes and you have room for dozens/hundreds of copies
of the "database".
Another possibility is to have separate include files for each product, but it
could be more unwieldy to deal with 300 or so separate product files.


Of course, if you wanted a product list, you'd have to open all 300 files, read
the product name, and close them (unless you used the filename to store product
name). But this does have the advantage that, if they screw something up, they
will only screw up one product.
I'm probably overlooking something more obvious. Other suggestions appreciated!


One thing I did years ago was let a client maintain an Excel (which they already
knew how to use) spreadsheet of their products. They exported as a delimited
file (tab or comma), uploaded to server and my Perl script took it from there.
If you choose to do this, you might want to make a quick script that does some
low-level checking (make sure images named in file actually exist on server,
make sure all required fields are filled out, etc.) and just print the errors to
an admin page -- nothing fancy, but would save client trouble of clicking
through 300 pages.

But basically, I think you'll find that there's no magic solution to avoiding
making an admin interface. Though I would love to be proved wrong on this
point...

There will always be concessions when allowing the client to edit their site
with no interface. The biggest one is the inevitable errors and the
corresponding panicked phone calls. But you also have to train them,
troubleshoot their mistakes and train them again, accept that they're not going
to be as happy with it as they would be with an interface (and your
word-of-mouth suffers).

Whatever system you go with, make sure the server has a very good backup
system. All the methods above enable the client to seriously mess things up.


Thanks for your comments. As mentioned in another reply, I'll focus on
separating data from code even though I can't spend time an admin interface.

Perhaps I wasn't explicit. There aren't 300 pages, but 300 products. These are
grouped into a dozen or so categories, with all products in a category displayed
on a page. Currently each category has its own separate subdirectory that
contains its images.

I'd like to strike a balance between performance and maintainability. Let's say
there are 20 products in a category. Would it be excessive overhead to read in
20 include files each the page loaded? Would be better to have a single include
file per category?

jw
--
jd**@nospamforme.com
Jul 17 '05 #5
JW
nc@iname.com (Nikolai Chuvakhin) wrote:
JW <jd**@nospamforme.com> wrote in message
news:<s5********************************@4ax.com>. ..

I'm displaying product thumbnails with brief descriptions on web pages.
Clicking on the product does a javascript popup with larger image and
detailed description info passed to the javascript functions from the
table data.

Products can change frequently, and I want to make the maintenance of
this info easier by non-techies


Then treat the maintainers accordingly. Wirte an administrative
interface and make sure every maintenance task can be done via
that interface and no manual fiddling with server-side files is
required.


I'm afraid that with this project I won't be able to devote time on creating an
admin interface. Unfortunately, it isn't always easy to convince folks that the
time spent in preventing problems saves time and money in the long run. Will
therefore focus on separating data from code.

jw
--
jd**@nospamforme.com
Jul 17 '05 #6


JW wrote:

Shawn Wilson <sh***@glassgiant.com> wrote:
JW wrote:
(snip)
Products can change frequently, and I want to make the maintenance of this
info easier by non-techies (each product has an image name, image width
(currently not using getimagesize), a short description, and a long
description). Can't devote major time to this; using a MySQL database to store
the data is currently not feasible because of the time to create the
administrative interface.

===============================================
Method 1 to display image - hard coded info in table, no php:
Problem is that it's too hard to find the pieces to modify and to easy to screw
up by Joe Noncoder.


I agree 100%. It's also too easy to screw up for a seasoned programmer,
especially for the 300+ pages you mention below. And changing the format is a
real bitch. You always end up with missed files and broken links. A major pet
peeve of mine is working on other people's HTML mixed with my PHP, especially
when they use FrontPage or other WYSIWYG editor.
===============================================
Method 2 to display image using php:
(snip)
The second method is a bit easier to maintain for an end user, only because the
data to modify is clearly delineated.


If you choose this route, you may want to consider arrays in an include file.
Code (HTML or PHP) is confusing enough for non-coders. I wouldn't make them
sift through all of it if they only need to deal with a small part. Give them
written instructions on how to deal with ' or ", whichever quote you use. And
I'd put 2 copies of the file - a live one and a dev one. Give them instructions
on how to update and FTP the dev file. Write a very quick script that includes
the dev file, and, if there are no errors, replace the live file. This could be
written very quickly. And you may also want to make an auto-archive feature
(copy old file to archive directory as "name-".time().".txt"), assuming there
won't be daily/hourly/ changes and you have room for dozens/hundreds of copies
of the "database".
Another possibility is to have separate include files for each product, but it
could be more unwieldy to deal with 300 or so separate product files.


Of course, if you wanted a product list, you'd have to open all 300 files, read
the product name, and close them (unless you used the filename to store product
name). But this does have the advantage that, if they screw something up, they
will only screw up one product.
I'm probably overlooking something more obvious. Other suggestions appreciated!


One thing I did years ago was let a client maintain an Excel (which they already
knew how to use) spreadsheet of their products. They exported as a delimited
file (tab or comma), uploaded to server and my Perl script took it from there.
If you choose to do this, you might want to make a quick script that does some
low-level checking (make sure images named in file actually exist on server,
make sure all required fields are filled out, etc.) and just print the errors to
an admin page -- nothing fancy, but would save client trouble of clicking
through 300 pages.

But basically, I think you'll find that there's no magic solution to avoiding
making an admin interface. Though I would love to be proved wrong on this
point...

There will always be concessions when allowing the client to edit their site
with no interface. The biggest one is the inevitable errors and the
corresponding panicked phone calls. But you also have to train them,
troubleshoot their mistakes and train them again, accept that they're not going
to be as happy with it as they would be with an interface (and your
word-of-mouth suffers).

Whatever system you go with, make sure the server has a very good backup
system. All the methods above enable the client to seriously mess things up.


Thanks for your comments. As mentioned in another reply, I'll focus on
separating data from code even though I can't spend time an admin interface.

Perhaps I wasn't explicit. There aren't 300 pages, but 300 products. These are
grouped into a dozen or so categories, with all products in a category displayed
on a page. Currently each category has its own separate subdirectory that
contains its images.

I'd like to strike a balance between performance and maintainability. Let's say
there are 20 products in a category. Would it be excessive overhead to read in
20 include files each the page loaded? Would be better to have a single include
file per category?


I have never tested a situation where I included that many files. I don't
really know. Maybe someone else here has done this and would be kind enough to
share results with you? But I'm guessing it'd be unique to your situation, so
you'd likely have to do it and test it to find out. If this is a small site and
likely to stay that way, I'd guess it'd be okay. If it's bigger, then likely
not. ("small" and "bigger" are purposely vague descriptors). Sorry I couldn't
be of more help.

Shawn

--
Shawn Wilson
sh***@glassgiant.com
http://www.glassgiant.com
Jul 17 '05 #7

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

9
by: Wm | last post by:
As an amateur wannabe-pro programmer, I am trying to learn not only how to use PHP but how to do it *efficiently*. (Trust me, you don't wanna see some of my stuff!!!) I'm noticing a number of my...
25
by: Lin Ma | last post by:
Hi, I am wondering if I am doing right. Please advise. I create a system with 8 major steps and each step can go different direction. General speaking, a lot of if statements and functions...
50
by: jbailo | last post by:
Subject: dotnet is a farce. You know, I was always impressed with the way one could write a http program with c# or java. To me, it showed how 'superior' these languages are because they made...
193
by: Michael B. | last post by:
I was just thinking about this, specifically wondering if there's any features that the C specification currently lacks, and which may be included in some future standardization. Of course, I...
144
by: Natt Serrasalmus | last post by:
After years of operating without any coding standards whatsoever, the company that I recently started working for has decided that it might be a good idea to have some. I'm involved in this...
2
by: lovecreatesbeauty | last post by:
Some of the coding guideline are mandatory, and even the format or layout of the text of the source code also should be followed. There's plenty of codes like the following snippet. Do you think...
1
by: R Reyes | last post by:
Hello All, I'm always looking for ways to improve my code. Most of the time (whenever I'm working on a project) I write a bunch of functions. Then after the project is finished, I put all the...
23
by: Simon Hengel | last post by:
Hello, we are hosting a python coding contest an we even managed to provide a price for the winner... http://pycontest.net/ The contest is coincidentally held during the 22c3 and we will be...
7
by: Robert Seacord | last post by:
The CERT/CC has just deployed a new web site dedicated to developing secure coding standards for the C programming language, C++, and eventually other programming language. We have already...
1
by: House817 | last post by:
I consistently get an overflow error at the "SOxBenefits =" (source code below), while coding in a macros from within Excel, Microsoft XP. I've tried the following: 1. setting a variable equal to...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.