JW wrote:[color=blue]
>
> Shawn Wilson <shawn@glassgiant.com> wrote:
>[color=green]
> >JW wrote:[color=darkred]
> >>[/color][/color]
> (snip)
>[color=green][color=darkred]
> >> 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.[/color]
> >
> >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.
> >[color=darkred]
> >> ===============================================
> >> Method 2 to display image using php:
> >>[/color][/color]
> (snip)[color=green][color=darkred]
> >>
> >> The second method is a bit easier to maintain for an end user, only because the
> >> data to modify is clearly delineated.[/color]
> >
> >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".
> >[color=darkred]
> >> 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.[/color]
> >
> >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.
> >[color=darkred]
> >> I'm probably overlooking something more obvious. Other suggestions appreciated![/color]
> >
> >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.
> >[/color]
>
> 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?[/color]
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
shawn@glassgiant.com http://www.glassgiant.com 
