For those that hand code...

M

Mike Barnard

Hi.

What sort of system do you have in place to reduce the amount of
repeat coding you do in a single site when creating new pages?

What do I mean? Well, Dreamweaver etc will keep a template for you I
understand, so if you want a new page in your site just call it up and
add your data. But if hand coding what do *you* do? Design a template,
keep a content free copy I suppose and copy a renamed version then add
the new content. BUT, then you have to update the menus on all of the
already created pages to match. Again and again maybe if the site is
growing.

I suppose the easiest way for that is to cut n paste the menu, but in
my case it will still need tweaking on each page to have the current
page showing by use of the 'name the page body' system. (That doesn't
read right, but work with me.)

Is there an easier system, or is that just it? (Or am I being blind
again?)
 
B

Beauregard T. Shagnasty

Mike said:
What sort of system do you have in place to reduce the amount of
repeat coding you do in a single site when creating new pages?

Look into writing with server-side includes. PHP is rather easy for
this, and (most?) all Linux web servers support it.
What do I mean? Well, Dreamweaver etc will keep a template for you I
understand, so if you want a new page in your site just call it up
and add your data. But if hand coding what do *you* do? Design a
template, keep a content free copy I suppose and copy a renamed
version then add the new content.

Keeping a content-free template is a great idea.
<div id="content">
"<!-- add content here -->
</div>

Open it, and resave with the name of the new file.
BUT, then you have to update the menus on all of the already created
pages to match. Again and again maybe if the site is growing.

Not if your menu is a separate, single file you "include". Same goes for
the banner file, the footer file, and so forth. Even the doctype and
I suppose the easiest way for that is to cut n paste the menu, but in
my case it will still need tweaking on each page

...only if you don't "include" the common parts.
to have the current page showing by use of the 'name the page body'
system. (That doesn't read right, but work with me.)

You're right .. hard to parse that.
Is there an easier system, or is that just it? (Or am I being blind
again?)

You're a Windows user? Look at the Crimson Editor. Besides being an
excellent color-coded editor, it's a great project manager. Don't worry
about its age.
http://crimsoneditor.com/

And if you don't have a development web server installed yet, see:
http://www.wampserver.com/en/ .. the Winders version of LAMP.
 
A

Adrienne Boswell

Gazing into my crystal ball I observed Mike Barnard
Hi.

What sort of system do you have in place to reduce the amount of
repeat coding you do in a single site when creating new pages?

What do I mean? Well, Dreamweaver etc will keep a template for you I
understand, so if you want a new page in your site just call it up and
add your data. But if hand coding what do *you* do? Design a template,
keep a content free copy I suppose and copy a renamed version then add
the new content. BUT, then you have to update the menus on all of the
already created pages to match. Again and again maybe if the site is
growing.

I suppose the easiest way for that is to cut n paste the menu, but in
my case it will still need tweaking on each page to have the current
page showing by use of the 'name the page body' system. (That doesn't
read right, but work with me.)

Is there an easier system, or is that just it? (Or am I being blind
again?)

1. Server side includes make making templates a breeze
2. I use HTML-Kit that can let you save content as a template or
snippet, eg:
<?php
$thispage = ""; //page name to be used in the header
$thisurl = ""; //the url goes in a function to activate thispage
class on the menu.

include "linkrel.php";
// linkrel.php has the doctype, external stylesheet, external
//javascript, connection to the db, and also a separate page with
//funtions.
?>
</head>
<body>
<?php include "h1_inc.php";?>
<?php include "nav_inc.php";?>
<div id="content">
</div>
<?php include "footer_inc.php";?>

I also have a lot of snippets that I use all the time, and I reuse
server side code as much as possible. I am a big fan of arrays.
 
B

Blinky the Shark

Mike said:
Hi.

What sort of system do you have in place to reduce the amount of
repeat coding you do in a single site when creating new pages?

What do I mean? Well, Dreamweaver etc will keep a template for you I
understand, so if you want a new page in your site just call it up and
add your data. But if hand coding what do *you* do? Design a template,
keep a content free copy I suppose and copy a renamed version then add
the new content. BUT, then you have to update the menus on all of the
already created pages to match. Again and again maybe if the site is
growing.

When I want a new page, I just pull up a current page and save it with a
new name. My headers and footers, containing navigation and other
stuff, and my <head> elements and doctype declaration are the same on
all pages -- they're served by PHP. So all I have to do is change the
<title> and replace the old content (everything between the
top-of-document and bottom-of-document calls to PHP).

For an extemely simple example:

http://blinkynet.net/sharks/monstroso.html

Everything above the first <hr> and below the "Back to Sharks" link is the
same on every page (again, provided by PHP), so all I had to do do make
this page was pull up another, save with new name, and change the <title>,
the <h1>, the image and the caption.
 
J

Jeff

Mike said:
Hi.

What sort of system do you have in place to reduce the amount of
repeat coding you do in a single site when creating new pages?

What do I mean? Well, Dreamweaver etc will keep a template for you I
understand, so if you want a new page in your site just call it up and
add your data. But if hand coding what do *you* do? Design a template,
keep a content free copy I suppose and copy a renamed version then add
the new content. BUT, then you have to update the menus on all of the
already created pages to match. Again and again maybe if the site is
growing.

I suppose the easiest way for that is to cut n paste the menu, but in
my case it will still need tweaking on each page to have the current
page showing by use of the 'name the page body' system. (That doesn't
read right, but work with me.)

Well templating is a big step toward this. Most in this group like to do
the editing client side and upload the new page.

There's also a sizeable (not exclusive to the above) group that use
includes or PHP. My preference is to have pages that are static,
actually be just that, plain .html pages.

No matter.

Maintaining navigation is important, very important. Some of the
techniques can be similar if you use a CMS, as I do, or if you use some
kind of include.

Now, just about every site I work on has a different navigation
system. Many even have top nav *and* context/location driven side
navigation. Obviously if you add a page in the site you want it to
appear, where appropriate, in the navigation elsewhere in the site.

Now, if you are using includes, I don't know how you would go about
this, other than to either hand edit the includes (or page) or have some
database that has the site structure.

If you have some kind of CMS, you already have the site structure
stored. When you save a page, your CMS knows where the page is in the
site architecture. It knows what section or sub section it is in,
whether you want it in the navigation and how you want the pages
ordered. Obviously it also knows the current page and it can use that
for marking where you are. That particular technique also works with
includes as the calling page is one of the environment variables the
script knows.

*Some* of the client side editors have some system of managing
navigation. I believe Crimson Editor has been mentioned and Adobe has
Contribute.

Jeff
 
C

C A Upsdell

Mike said:
Hi.

What sort of system do you have in place to reduce the amount of
repeat coding you do in a single site when creating new pages?

What do I mean? Well, Dreamweaver etc will keep a template for you I
understand, so if you want a new page in your site just call it up and
add your data. But if hand coding what do *you* do? Design a template,
keep a content free copy I suppose and copy a renamed version then add
the new content. BUT, then you have to update the menus on all of the
already created pages to match. Again and again maybe if the site is
growing.

I hand code. The answer is: global search and replace.
 
N

Neredbojias

No matter.

Maintaining navigation is important, very important. Some of the
techniques can be similar if you use a CMS, as I do, or if you use some
kind of include.

A web page is like a lover. If you treat it as "one of the crowd", you're
not likely to get as many warm fuzzies as you'd get by employing "that
special touch".
 
B

Bergamot

Mike said:
What sort of system do you have in place to reduce the amount of
repeat coding you do in a single site when creating new pages?

Custom scripts, a preprocessor, and Homesite, which has fantastic search
and replace capabilities.
I suppose the easiest way for that is to cut n paste the menu,

A preprocessor is easier.
 
D

dorayme

Bergamot said:
Custom scripts, a preprocessor, and Homesite, which has fantastic search
and replace capabilities.


A preprocessor is easier.

If you have a good Search and Replace, if you don't want to get a
home server or preprocessor, if you use includes, you can
quickly get a "full-code" set of hml pages by the following
method:


First duplicate the whole website folder and call it
whatever_fullcode. This folders html files are the ones you will
convert.

Suppose the includes have this style:

<?php include
($_SERVER['DOCUMENT_ROOT'].'/domain/includes/banner.inc'); ?>


You cut and paste this into the Find field of your Search and
Replace box of your text editor.

You then copy the mark up you have for the banner in your
includes file and paste this in the Replace field.

Then you order your S & R to replace all instances of the first
with the second.

Having done the banner, the nav include is maybe next. Easy. You
just replace the word banner from the first field with nav
(assuming that the navigation markup is called "nav.inc"). And
paste in the navigation markup from your includes file.

And so on.

You can have a full code (no includes) website set of htmls in no
time.

Quicker still is to make your own grep pattern and do the whole
show in one hit of the Find and Replace. You would have to be
careful on tooling up for this. But once done, you would have the
pattern forever.
 
B

Beauregard T. Shagnasty

dorayme said:
You can have a full code (no includes) website set of htmls in no
time.

That'll all work, but then you have to upload your entire site to the
host for one new page and a menu update. <g>
 
D

dorayme

"Beauregard T. Shagnasty said:
That'll all work, but then you have to upload your entire site to the
host for one new page and a menu update. <g>

I was assuming - don't ask me why, I just assume things, I am
like that, bold and dashing - that OP had no personal offline
server with PHP, but did have the facilities, as is almost
universal, with a remote commercial one. There then does arise
the issue for some people of how to look at their own work in
browsers when offline. And I was proposing a way to do this, a
way that is very satisfying when you get the hang of it because
it is so stupid it is amazing when it works quickly.

I have been doing more or less exactly this for the last week in
the following situation. I have a winbox and my offline
connection to *it* is bust because I have still not got around to
following Jonathan's advice to me to open the thing, pull the
modem out and refit it and then restart (thread of 20 years ago),
and there are issues with the server on it at the moment. So what
to do to see my efforts made on a Mac? I do exactly what I said
in my last post. Then USB stick it over to the winbox to be
appalled at what I see of my hard work on a new site in IE6.

The OP should do two things, get a server with PHP going on his
machine, and get an external host (assuming he does not host his
own website) with PHP too. Then there is no need to fiddle about.
The includes will be all the things you have previously mentioned
and so on...

My post was a little foray into the ways of fiddling about... <g>
 
B

Bergamot

Beauregard said:
That'll all work, but then you have to upload your entire site to the
host for one new page and a menu update. <g>

When the whole site is less than 10 pages, it's no big deal.
 
J

Jeff

Beauregard said:
That'll all work, but then you have to upload your entire site to the
host for one new page and a menu update. <g>

And, of course, it does not answer the more typical situation when
the navigation is not the same in all sections of the site as Dorayme's
fix makes the nav the same everywhere. If you are in the widgets section
you won't want the foobar subnav. That is, after all, what the op was
asking. That and the OP asked about marking the current page in the nav.
That (page marking), BTW, is possible with a little javascript. It won't
work, of course, if js is off, but so what.

If you have a site beyond a handful of pages, *I* think some
automation, whether a CMS or a preprocessor, but *something* to keep
track and automate maintenance. That, of course, is the beauty of a CMS
in that you can add and move pages around without having to remember (or
do) all the changes you need to make. I think you guys take pride (and
like to charge) in doing that though!

Jeff
 
D

dorayme

Jeff said:
And, of course, it does not answer the more typical situation when
the navigation is not the same in all sections of the site as Dorayme's
fix makes the nav the same everywhere.

You are right Jeff, it is a bit of PITA when it gets more
complex.

But, you know, sometimes, in a big site, it is better to be very
simple in the navigation system. To keep one main navigation
pretty constant throughout. (You can always add little flourishes
and highlightings via php, eg. for current page).

And you can have local menus for some sections. All these things
(not the php highlight aids) are easy to use S&R for.

I'll say it again: best is get a home server with PHP, host with
a good host server with PHP. Bob and Carol, Ted and Alice would
then easily be your uncles and aunts.
 
J

Jeff

dorayme said:
You are right Jeff, it is a bit of PITA when it gets more
complex.

But, you know, sometimes, in a big site, it is better to be very
simple in the navigation system. To keep one main navigation
pretty constant throughout. (You can always add little flourishes
and highlightings via php, eg. for current page).

And you can have local menus for some sections.

That is really common. And you would search and replace only those pages
in that section. How would you do that? It looks to me that you would in
effect edit each page individually as you still have to mark the current
page. Or you would need a lot of PHP includes.

I'm not saying that's wrong, just curious how you manage a site in the
25 page range. Personally I've found that managing a site that size and
larger requires keeping careful track of many things, and for the work I
see that is about a median size site. (Actually, I'm not sure what my
median size is, I just checked what I thought was a small site and it
had 37 pages!) Now, I've gone the CMS route and I'm just wondering how
you do this. I consider myself to be a very small player.

All these things
(not the php highlight aids) are easy to use S&R for.

I'll say it again: best is get a home server with PHP,


I'm mixed up here. Why do you need a home server with PHP?

Jeff

host with
 
B

Beauregard T. Shagnasty

Jeff said:
I'm mixed up here. Why do you need a home server with PHP?

For the same reason you have a development environment for any kind of
software you write. You create and test, fix bugs, and test again,
before you upload/distribute to the public.

Of course, if you write only in plain, pure HTML, a browser alone is all
that is necessary.

Look up LAMP and/or WAMP (depending on your operating system).
 
J

Jeff

Beauregard said:
For the same reason you have a development environment for any kind of
software you write. You create and test, fix bugs, and test again,
before you upload/distribute to the public.

This has always seemed like a duplication of effort with the added
inconvenience that I develop largely on a windows box for a target LAMP
box. The environment variables are different and windows often needs
some of these explicitly set while the *nix box won't. That means I
would need two slightly different sets of files, one for local and one
for the web.

Now, lets say you have a database, that's very common... Now you have
to sync up the data online with that on the local box.

I don't see any real problems with just putting it on the web. Every
time someone posts a problem the first thing requested is a URL!
Certainly the client will need to see it on the web and not on your
local box. If the domain is already under use, just put it under an IP.

It seems to me that many readers here take pride in expending more
effort than is needed. There's a whole thread trashing me when I
suggested using a CMS to maintain a site, everyone preferred to download
the files, edit them, and reupload.

Jeff
 
B

Beauregard T. Shagnasty

Jeff said:
This has always seemed like a duplication of effort with the added
inconvenience that I develop largely on a windows box for a target
LAMP box. The environment variables are different and windows often
needs some of these explicitly set while the *nix box won't. That
means I would need two slightly different sets of files, one for
local and one for the web.

There is very little different between LAMP and WAMP. MySQL login is
one, so I use a bit of PHP (if/else) in my common functions to handle
that.
Now, lets say you have a database, that's very common... Now you have
to sync up the data online with that on the local box.

Quite common; I use databases with all my sites. I either have a test
suite of data on the development PC, or I backup and load the web
version occasionally. It's no biggie, as I backup the web host data
regularly in any case.
I don't see any real problems with just putting it on the web. Every
time someone posts a problem the first thing requested is a URL!
Certainly the client will need to see it on the web and not on your
local box. If the domain is already under use, just put it under an
IP.

Those ways will of course work, but I would rather test before
deployment.
It seems to me that many readers here take pride in expending more
effort than is needed. There's a whole thread trashing me when I
suggested using a CMS to maintain a site, everyone preferred to
download the files, edit them, and reupload.

Download/edit/reupload? Don't you keep a copy of the current source on
your machine? What do you do if your host goes belly-up?

<snipped the rest you didn't reply to>
 
B

Bergamot

Jeff said:
This has always seemed like a duplication of effort with the added
inconvenience that I develop largely on a windows box for a target LAMP

That's irrelevant. I develop on Windows for a target LAMP and can't
imagine *not* having a local server. I've been running WAMP for years.
The environment variables are different and windows often needs
some of these explicitly set while the *nix box won't.

I rarely have any trouble setting up the local server to mimic the
remote server. Sometimes there is some kind of config file that is
server specific, but most times the same settings can be used on both,
including database usernames and passwords. I'm curious - what are you
doing that uses different env variables?
Now, lets say you have a database, that's very common... Now you have
to sync up the data online with that on the local box.

Why? If the user is maintaining the remote data, which appears to be
true in your case, all you need locally is sufficient sampling of the
data to do adequate testing. If you really do need to mirror the data,
too, export the whole database from one and import it into the other.
Unless it's a huge site, this only takes a few seconds on either server.

I've only ever had to do that when the site is first set up, either
setting it up locally from an existing remote site, or setting up the
initial remote site from my local test site. After that, there's never
been a need for full database mirroring.
I don't see any real problems with just putting it on the web.

I see the potential for huge problems. YMMV, and I guess it does.
There's a whole thread trashing me when I
suggested using a CMS to maintain a site, everyone preferred to download
the files, edit them, and reupload.

You assume the user always maintains a site themselves? Believe me, that
is not the case.

Very few of my clients take any of that responsibility. Most are small
businesses that don't have either the time, desire, or adequate skill to
do it themselves. They are happy to pay me to do it for them. All of
their site's files are maintained on my local server and changes are
uploaded whenever needed.

A handful do run CMS's, but there's no need to mirror their databases
locally. Those clients do their own database backups, so there's no need
for me to do it. I've got all the scripts locally, so between the 2 of
us we can restore the site on any LAMP server if need be.

It's easy peasy, really. And it's a lot less risky than messing with a
live client site.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,754
Messages
2,569,522
Members
44,995
Latest member
PinupduzSap

Latest Threads

Top