create html from flat file

[lxyone]

Using a flat file containing table names, fields, values whats the
best way of creating html pages?

I want control over the html pages ie
1. layout
2. what data to show
3. what controls to show - text boxes, input boxes, buttons,
hyperlinks ie the usual.

The data is not obtained directly from a database.

I was thinking maybe the flat file could use xml. And maybe this flat
file could be generated using :
1. the database data and
2. a template file to indicate the controls that should appear on each
html page.

Maybe there could be existing html pages that could be used in the
generation of the required final html pages ie maybe they could
contain static data - such as layout, headings and tags as to where
fields, controls need to be placed.

Searching on this is difficult as the key words are too common :
create, html, xml, dynamic, template etc results in million+ hits.

[Jerry Stuckle]

lx****@googlemail.com wrote:

Using a flat file containing table names, fields, values whats the
best way of creating html pages?

I want control over the html pages ie
1. layout
2. what data to show
3. what controls to show - text boxes, input boxes, buttons,
hyperlinks ie the usual.

The data is not obtained directly from a database.

I was thinking maybe the flat file could use xml. And maybe this flat
file could be generated using :
1. the database data and
2. a template file to indicate the controls that should appear on each
html page.

Maybe there could be existing html pages that could be used in the
generation of the required final html pages ie maybe they could
contain static data - such as layout, headings and tags as to where
fields, controls need to be placed.

Searching on this is difficult as the key words are too common :
create, html, xml, dynamic, template etc results in million+ hits.

If you're going to go to all that trouble, why not just create the html
page from the flat file and store it as a static page? Then when the
flat file changes, regenerate the html.

Much simpler (and server-friendly) than recreating the same page on
every request.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[lxy one]

On 6 Jun, 03:30, Jerry Stuckle <[e-mail]:

[e-mail] wrote:

Using a flat file containing table names, fields, values whats the
best way of creating html pages?

I want control over the html pages ie
1. layout
2. what data to show
3. what controls to show - text boxes, input boxes, buttons,
hyperlinks ie the usual.

The data is not obtained directly from a database.

I was thinking maybe the flat file could use xml. And maybe this flat
file could be generated using :
1. the database data and
2. a template file to indicate the controls that should appear on each
html page.

Maybe there could be existing html pages that could be used in the
generation of the required final html pages ie maybe they could
contain static data - such as layout, headings and tags as to where
fields, controls need to be placed.

Searching on this is difficult as the key words are too common :
create, html, xml, dynamic, template etc results in million+ hits.

If you're going to go to all that trouble, why not just create the html
page from the flat file and store it as a static page? Then when the
flat file changes, regenerate the html.

Much simpler (and server-friendly) than recreating the same page on
every request.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================

Hi Jerry,

But thats exactly what I want to do.
1. Create a flat file that will contain
-a) tables/fields+data values
-b) web page(form) details ie the fields/controls to appear on each
web page.
2. Generate the (static) web pages from the flat file.
3. If flat file is updated then update web pages.

So the issues are :
1. flat file - what format should this be in - xml ?
2. How to generate the (static) web pages (forms) from the flat file
bearing in mind that I would like to control over what web pages +
tables/fields/data + controls are created.

But maybe this is to difficult. Maybe it would be easier to have the
static web pages I want already created. The pages could have tags to
indicate where fields + controls (if available in the flat file)
should go.

I would have thought something flexible like this : generating static
web pages using data/controls from a flat file : had already been done
but I've not found anything yet.

[Jerry Stuckle]

lxy one wrote:

On 6 Jun, 03:30, Jerry Stuckle <[e-mail]:

>[e-mail] wrote:

>>Using a flat file containing table names, fields, values whats the
best way of creating html pages?
I want control over the html pages ie
1. layout
2. what data to show
3. what controls to show - text boxes, input boxes, buttons,
hyperlinks ie the usual.
The data is not obtained directly from a database.
I was thinking maybe the flat file could use xml. And maybe this flat
file could be generated using :
1. the database data and
2. a template file to indicate the controls that should appear on each
html page.
Maybe there could be existing html pages that could be used in the
generation of the required final html pages ie maybe they could
contain static data - such as layout, headings and tags as to where
fields, controls need to be placed.
Searching on this is difficult as the key words are too common :
create, html, xml, dynamic, template etc results in million+ hits.

If you're going to go to all that trouble, why not just create the html
page from the flat file and store it as a static page? Then when the
flat file changes, regenerate the html.

Much simpler (and server-friendly) than recreating the same page on
every request.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================

Hi Jerry,

But thats exactly what I want to do.
1. Create a flat file that will contain
-a) tables/fields+data values
-b) web page(form) details ie the fields/controls to appear on each
web page.
2. Generate the (static) web pages from the flat file.
3. If flat file is updated then update web pages.

OK, I understand better now.

So the issues are :
1. flat file - what format should this be in - xml ?

The simple answer is - whatever form suits you best. I've seen xml
files, csv files, php code and even just plain text. It all depends on
the data and what's easiest for you.

I would think that since your file needs to contain tables/fields and
data, xml might be easiest to parse and maintain. But that's probably
because I've worked with xml a fair amount. But if you haven't, another
form (such as csv) might be easier.

2. How to generate the (static) web pages (forms) from the flat file
bearing in mind that I would like to control over what web pages +
tables/fields/data + controls are created.

Well, you'll have to read the file then display all of the information
on a web page. Then select the information you wish to display.
Finally, generate the page.

But maybe this is to difficult. Maybe it would be easier to have the
static web pages I want already created. The pages could have tags to
indicate where fields + controls (if available in the flat file)
should go.

You're now talking about a templating system, which is very popular.
The nice thing about it is it takes a lot of the "grunt work" out of the
code required to generate the page. It also separates the rest of the
page from the actual data being displayed, making it easier to maintain.

I would have thought something flexible like this : generating static
web pages using data/controls from a flat file : had already been done
but I've not found anything yet.

I've used it before, when the data doesn't change very often. It can be
very effective on high usage sites. For lower usage sites and data
which changes fairly regularly, I just generate the pages dynamically on
request.

And I think you'll find most of the systems use a database instead of a
flat file. It makes things a lot easier - the database manages the data
for you, so you don't have to do as much in your code. Simple SQL
requests are not that hard to learn, and if you're going to be serious
about web development, they're pretty much a requirement nowadays. SQL
is just too powerful to ignore.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[lxy one]

On 6 Jun, 11:39, Jerry Stuckle <[e-mail]:

lxy one wrote:

On 6 Jun, 03:30, Jerry Stuckle <[e-mail]:

[e-mail] wrote:
Using a flat file containing table names, fields, values whats the
best way of creating html pages?
I want control over the html pages ie
1. layout
2. what data to show
3. what controls to show - text boxes, input boxes, buttons,
hyperlinks ie the usual.
The data is not obtained directly from a database.
I was thinking maybe the flat file could use xml. And maybe this flat
file could be generated using :
1. the database data and
2. a template file to indicate the controls that should appear on each
html page.
Maybe there could be existing html pages that could be used in the
generation of the required final html pages ie maybe they could
contain static data - such as layout, headings and tags as to where
fields, controls need to be placed.
Searching on this is difficult as the key words are too common :
create, html, xml, dynamic, template etc results in million+ hits.
If you're going to go to all that trouble, why not just create the html
page from the flat file and store it as a static page? Then when the
flat file changes, regenerate the html.

Much simpler (and server-friendly) than recreating the same page on
every request.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================

Hi Jerry,

But thats exactly what I want to do.
1. Create a flat file that will contain
-a) tables/fields+data values
-b) web page(form) details ie the fields/controls to appear on each
web page.
2. Generate the (static) web pages from the flat file.
3. If flat file is updated then update web pages.

OK, I understand better now.

So the issues are :
1. flat file - what format should this be in - xml ?

The simple answer is - whatever form suits you best. I've seen xml
files, csv files, php code and even just plain text. It all depends on
the data and what's easiest for you.

I would think that since your file needs to contain tables/fields and
data, xml might be easiest to parse and maintain. But that's probably
because I've worked with xml a fair amount. But if you haven't, another
form (such as csv) might be easier.

2. How to generate the (static) web pages (forms) from the flat file
bearing in mind that I would like to control over what web pages +
tables/fields/data + controls are created.

Well, you'll have to read the file then display all of the information
on a web page. Then select the information you wish to display.
Finally, generate the page.

But maybe this is to difficult. Maybe it would be easier to have the
static web pages I want already created. The pages could have tags to
indicate where fields + controls (if available in the flat file)
should go.

You're now talking about a templating system, which is very popular.
The nice thing about it is it takes a lot of the "grunt work" out of the
code required to generate the page. It also separates the rest of the
page from the actual data being displayed, making it easier to maintain.

I would have thought something flexible like this : generating static
web pages using data/controls from a flat file : had already been done
but I've not found anything yet.

I've used it before, when the data doesn't change very often. It can be
very effective on high usage sites. For lower usage sites and data
which changes fairly regularly, I just generate the pages dynamically on
request.

And I think you'll find most of the systems use a database instead of a
flat file. It makes things a lot easier - the database manages the data
for you, so you don't have to do as much in your code. Simple SQL
requests are not that hard to learn, and if you're going to be serious
about web development, they're pretty much a requirement nowadays. SQL
is just too powerful to ignore.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================

Hi Jerry,

Can you point me code examples please as I'm new to this.

As to why a flat file instead of a DB - the idea for the flat file was
that it would combine both table data and form data to allow the
generation of each web page.

[David Pyles]

On 6/6/2008 7:48 AM, lxy one wrote:

On 6 Jun, 11:39, Jerry Stuckle <[e-mail]:

>lxy one wrote:

>>On 6 Jun, 03:30, Jerry Stuckle <[e-mail]:
[e-mail] wrote:
Using a flat file containing table names, fields, values whats the
best way of creating html pages?
I want control over the html pages ie
1. layout
2. what data to show
3. what controls to show - text boxes, input boxes, buttons,
hyperlinks ie the usual.
The data is not obtained directly from a database.
I was thinking maybe the flat file could use xml. And maybe this flat
file could be generated using :
1. the database data and
2. a template file to indicate the controls that should appear on each
html page.
Maybe there could be existing html pages that could be used in the
generation of the required final html pages ie maybe they could
contain static data - such as layout, headings and tags as to where
fields, controls need to be placed.
Searching on this is difficult as the key words are too common :
create, html, xml, dynamic, template etc results in million+ hits.
If you're going to go to all that trouble, why not just create the html
page from the flat file and store it as a static page? Then when the
flat file changes, regenerate the html.
Much simpler (and server-friendly) than recreating the same page on
every request.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================
Hi Jerry,
But thats exactly what I want to do.
1. Create a flat file that will contain
-a) tables/fields+data values
-b) web page(form) details ie the fields/controls to appear on each
web page.
2. Generate the (static) web pages from the flat file.
3. If flat file is updated then update web pages.

OK, I understand better now.

>>So the issues are :
1. flat file - what format should this be in - xml ?

The simple answer is - whatever form suits you best. I've seen xml
files, csv files, php code and even just plain text. It all depends on
the data and what's easiest for you.

I would think that since your file needs to contain tables/fields and
data, xml might be easiest to parse and maintain. But that's probably
because I've worked with xml a fair amount. But if you haven't, another
form (such as csv) might be easier.

>>2. How to generate the (static) web pages (forms) from the flat file
bearing in mind that I would like to control over what web pages +
tables/fields/data + controls are created.

Well, you'll have to read the file then display all of the information
on a web page. Then select the information you wish to display.
Finally, generate the page.

>>But maybe this is to difficult. Maybe it would be easier to have the
static web pages I want already created. The pages could have tags to
indicate where fields + controls (if available in the flat file)
should go.

You're now talking about a templating system, which is very popular.
The nice thing about it is it takes a lot of the "grunt work" out of the
code required to generate the page. It also separates the rest of the
page from the actual data being displayed, making it easier to maintain.

>>I would have thought something flexible like this : generating static
web pages using data/controls from a flat file : had already been done
but I've not found anything yet.

I've used it before, when the data doesn't change very often. It can be
very effective on high usage sites. For lower usage sites and data
which changes fairly regularly, I just generate the pages dynamically on
request.

And I think you'll find most of the systems use a database instead of a
flat file. It makes things a lot easier - the database manages the data
for you, so you don't have to do as much in your code. Simple SQL
requests are not that hard to learn, and if you're going to be serious
about web development, they're pretty much a requirement nowadays. SQL
is just too powerful to ignore.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================

Hi Jerry,

Can you point me code examples please as I'm new to this.

As to why a flat file instead of a DB - the idea for the flat file was
that it would combine both table data and form data to allow the
generation of each web page.

I do something similar with MS Access. I have a database with thousands
of records that changes often and I want to create a new static html
page weekly with the updated data. I keep all of the pertinent
information in the database and make changes to it as necessary, then I
create a report from the database which generates the html page. I put
all of the static information as html in the header and the footer, and
all of the changing information goes between as database fields
surrounded by html tags. I use filter criteria in the report to keep
the unwanted information from appearing. You should be able to do
something similar with any database with reporting functions.

Dave Pyles

[Jerry Stuckle]

lxy one wrote:

On 6 Jun, 11:39, Jerry Stuckle <[e-mail]:

>lxy one wrote:

>>On 6 Jun, 03:30, Jerry Stuckle <[e-mail]:
[e-mail] wrote:
Using a flat file containing table names, fields, values whats the
best way of creating html pages?
I want control over the html pages ie
1. layout
2. what data to show
3. what controls to show - text boxes, input boxes, buttons,
hyperlinks ie the usual.
The data is not obtained directly from a database.
I was thinking maybe the flat file could use xml. And maybe this flat
file could be generated using :
1. the database data and
2. a template file to indicate the controls that should appear on each
html page.
Maybe there could be existing html pages that could be used in the
generation of the required final html pages ie maybe they could
contain static data - such as layout, headings and tags as to where
fields, controls need to be placed.
Searching on this is difficult as the key words are too common :
create, html, xml, dynamic, template etc results in million+ hits.
If you're going to go to all that trouble, why not just create the html
page from the flat file and store it as a static page? Then when the
flat file changes, regenerate the html.
Much simpler (and server-friendly) than recreating the same page on
every request.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================
Hi Jerry,
But thats exactly what I want to do.
1. Create a flat file that will contain
-a) tables/fields+data values
-b) web page(form) details ie the fields/controls to appear on each
web page.
2. Generate the (static) web pages from the flat file.
3. If flat file is updated then update web pages.

OK, I understand better now.

>>So the issues are :
1. flat file - what format should this be in - xml ?

The simple answer is - whatever form suits you best. I've seen xml
files, csv files, php code and even just plain text. It all depends on
the data and what's easiest for you.

I would think that since your file needs to contain tables/fields and
data, xml might be easiest to parse and maintain. But that's probably
because I've worked with xml a fair amount. But if you haven't, another
form (such as csv) might be easier.

>>2. How to generate the (static) web pages (forms) from the flat file
bearing in mind that I would like to control over what web pages +
tables/fields/data + controls are created.

Well, you'll have to read the file then display all of the information
on a web page. Then select the information you wish to display.
Finally, generate the page.

>>But maybe this is to difficult. Maybe it would be easier to have the
static web pages I want already created. The pages could have tags to
indicate where fields + controls (if available in the flat file)
should go.

You're now talking about a templating system, which is very popular.
The nice thing about it is it takes a lot of the "grunt work" out of the
code required to generate the page. It also separates the rest of the
page from the actual data being displayed, making it easier to maintain.

>>I would have thought something flexible like this : generating static
web pages using data/controls from a flat file : had already been done
but I've not found anything yet.

I've used it before, when the data doesn't change very often. It can be
very effective on high usage sites. For lower usage sites and data
which changes fairly regularly, I just generate the pages dynamically on
request.

And I think you'll find most of the systems use a database instead of a
flat file. It makes things a lot easier - the database manages the data
for you, so you don't have to do as much in your code. Simple SQL
requests are not that hard to learn, and if you're going to be serious
about web development, they're pretty much a requirement nowadays. SQL
is just too powerful to ignore.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================

Hi Jerry,

Can you point me code examples please as I'm new to this.

As to why a flat file instead of a DB - the idea for the flat file was
that it would combine both table data and form data to allow the
generation of each web page.

Unfortunately, that's very difficult. Every system I've done like this
has been a custom system - with widely varying differences in amount of
code and difficulty. Every database has been different, also.

My suggestion would be to use google to find some simple templating
systems and see how they do it. There are a bunch out there.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[lxy one]

On 6 Jun, 18:06, Jerry Stuckle <[e-mail]:

lxy one wrote:

On 6 Jun, 11:39, Jerry Stuckle <[e-mail]:

lxy one wrote:
On 6 Jun, 03:30, Jerry Stuckle <[e-mail]:
[e-mail] wrote:
Using a flat file containing table names, fields, values whats the
best way of creating html pages?
I want control over the html pages ie
1. layout
2. what data to show
3. what controls to show - text boxes, input boxes, buttons,
hyperlinks ie the usual.
The data is not obtained directly from a database.
I was thinking maybe the flat file could use xml. And maybe this flat
file could be generated using :
1. the database data and
2. a template file to indicate the controls that should appear on each
html page.
Maybe there could be existing html pages that could be used in the
generation of the required final html pages ie maybe they could
contain static data - such as layout, headings and tags as to where
fields, controls need to be placed.
Searching on this is difficult as the key words are too common :
create, html, xml, dynamic, template etc results in million+ hits.
If you're going to go to all that trouble, why not just create the html
page from the flat file and store it as a static page? Then when the
flat file changes, regenerate the html.
Much simpler (and server-friendly) than recreating the same page on
every request.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================
Hi Jerry,
But thats exactly what I want to do.
1. Create a flat file that will contain
-a) tables/fields+data values
-b) web page(form) details ie the fields/controls to appear on each
web page.
2. Generate the (static) web pages from the flat file.
3. If flat file is updated then update web pages.
OK, I understand better now.

>So the issues are :
1. flat file - what format should this be in - xml ?
The simple answer is - whatever form suits you best. I've seen xml
files, csv files, php code and even just plain text. It all depends on
the data and what's easiest for you.

I would think that since your file needs to contain tables/fields and
data, xml might be easiest to parse and maintain. But that's probably
because I've worked with xml a fair amount. But if you haven't, another
form (such as csv) might be easier.

>2. How to generate the (static) web pages (forms) from the flat file
bearing in mind that I would like to control over what web pages +
tables/fields/data + controls are created.
Well, you'll have to read the file then display all of the information
on a web page. Then select the information you wish to display.
Finally, generate the page.

>But maybe this is to difficult. Maybe it would be easier to have the
static web pages I want already created. The pages could have tags to
indicate where fields + controls (if available in the flat file)
should go.
You're now talking about a templating system, which is very popular.
The nice thing about it is it takes a lot of the "grunt work" out of the
code required to generate the page. It also separates the rest of the
page from the actual data being displayed, making it easier to maintain.

>I would have thought something flexible like this : generating static
web pages using data/controls from a flat file : had already been done
but I've not found anything yet.
I've used it before, when the data doesn't change very often. It can be
very effective on high usage sites. For lower usage sites and data
which changes fairly regularly, I just generate the pages dynamically on
request.

And I think you'll find most of the systems use a database instead of a
flat file. It makes things a lot easier - the database manages the data
for you, so you don't have to do as much in your code. Simple SQL
requests are not that hard to learn, and if you're going to be serious
about web development, they're pretty much a requirement nowadays. SQL
is just too powerful to ignore.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================

Hi Jerry,

Can you point me code examples please as I'm new to this.

As to why a flat file instead of a DB - the idea for the flat file was
that it would combine both table data and form data to allow the
generation of each web page.

Unfortunately, that's very difficult. Every system I've done like this
has been a custom system - with widely varying differences in amount of
code and difficulty. Every database has been different, also.

My suggestion would be to use google to find some simple templating
systems and see how they do it. There are a bunch out there.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================

Jerry, David,

I think I've not been clear on what I'm after and I guess that's
because I'm still pondering the problem.

1. Although tables/fields may vary, the creation of the static web
pages would be a one off ie once up and running no changes would be
expected. The reason for working this way, generating web pages, is to
cater for having different tables/fields and web page specifications.
So instead of having sets of static web pages to create/maintain you
can just create a new set by modifying a flat file. I cannot help
thinking that this must have been done.
2. Also misleadingly in a subsequently post I made a boo-boo in
indicating data values would be included in the flat file - not true,
the form would request this.
3. I thought the tricky bit would be creating the flat file ie
retrieving DB tables/fields and combining these with web page
specifications (optional/mandatory fields, controls, images etc). This
really is the crux. You would have to know what tables/fields to
expect. If a web page has a mandatory field specified and the field is
not one of those retrieved from the DB then maybe that's an abort.
Whereas if it's optional then we can go ahead and create the flat
file.

As for 1. above I will search on : simple templating systems. Thanks.

[Jerry Stuckle]

lxy one wrote:

On 6 Jun, 18:06, Jerry Stuckle <[e-mail]:

>lxy one wrote:

>>On 6 Jun, 11:39, Jerry Stuckle <[e-mail]:
lxy one wrote:
On 6 Jun, 03:30, Jerry Stuckle <[e-mail]:
>[e-mail] wrote:
>>Using a flat file containing table names, fields, values whats the
>>best way of creating html pages?
>>I want control over the html pages ie
>>1. layout
>>2. what data to show
>>3. what controls to show - text boxes, input boxes, buttons,
>>hyperlinks ie the usual.
>>The data is not obtained directly from a database.
>>I was thinking maybe the flat file could use xml. And maybe this flat
>>file could be generated using :
>>1. the database data and
>>2. a template file to indicate the controls that should appear on each
>>html page.
>>Maybe there could be existing html pages that could be used in the
>>generation of the required final html pages ie maybe they could
>>contain static data - such as layout, headings and tags as to where
>>fields, controls need to be placed.
>>Searching on this is difficult as the key words are too common :
>>create, html, xml, dynamic, template etc results in million+ hits.
>If you're going to go to all that trouble, why not just create the html
>page from the flat file and store it as a static page? Then when the
>flat file changes, regenerate the html.
>Much simpler (and server-friendly) than recreating the same page on
>every request.
>--
>==================
>Remove the "x" from my email address
>Jerry Stuckle
>JDS Computer Training Corp.
>[e-mail]
>==================
Hi Jerry,
But thats exactly what I want to do.
1. Create a flat file that will contain
-a) tables/fields+data values
-b) web page(form) details ie the fields/controls to appear on each
web page.
2. Generate the (static) web pages from the flat file.
3. If flat file is updated then update web pages.
OK, I understand better now.
So the issues are :
1. flat file - what format should this be in - xml ?
The simple answer is - whatever form suits you best. I've seen xml
files, csv files, php code and even just plain text. It all depends on
the data and what's easiest for you.
I would think that since your file needs to contain tables/fields and
data, xml might be easiest to parse and maintain. But that's probably
because I've worked with xml a fair amount. But if you haven't, another
form (such as csv) might be easier.
2. How to generate the (static) web pages (forms) from the flat file
bearing in mind that I would like to control over what web pages +
tables/fields/data + controls are created.
Well, you'll have to read the file then display all of the information
on a web page. Then select the information you wish to display.
Finally, generate the page.
But maybe this is to difficult. Maybe it would be easier to have the
static web pages I want already created. The pages could have tags to
indicate where fields + controls (if available in the flat file)
should go.
You're now talking about a templating system, which is very popular.
The nice thing about it is it takes a lot of the "grunt work" out of the
code required to generate the page. It also separates the rest of the
page from the actual data being displayed, making it easier to maintain.
I would have thought something flexible like this : generating static
web pages using data/controls from a flat file : had already been done
but I've not found anything yet.
I've used it before, when the data doesn't change very often. It can be
very effective on high usage sites. For lower usage sites and data
which changes fairly regularly, I just generate the pages dynamically on
request.
And I think you'll find most of the systems use a database instead of a
flat file. It makes things a lot easier - the database manages the data
for you, so you don't have to do as much in your code. Simple SQL
requests are not that hard to learn, and if you're going to be serious
about web development, they're pretty much a requirement nowadays. SQL
is just too powerful to ignore.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================
Hi Jerry,
Can you point me code examples please as I'm new to this.
As to why a flat file instead of a DB - the idea for the flat file was
that it would combine both table data and form data to allow the
generation of each web page.

Unfortunately, that's very difficult. Every system I've done like this
has been a custom system - with widely varying differences in amount of
code and difficulty. Every database has been different, also.

My suggestion would be to use google to find some simple templating
systems and see how they do it. There are a bunch out there.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================

Jerry, David,

I think I've not been clear on what I'm after and I guess that's
because I'm still pondering the problem.

1. Although tables/fields may vary, the creation of the static web
pages would be a one off ie once up and running no changes would be
expected. The reason for working this way, generating web pages, is to
cater for having different tables/fields and web page specifications.
So instead of having sets of static web pages to create/maintain you
can just create a new set by modifying a flat file. I cannot help
thinking that this must have been done.

This really can't be done. You can create templates for common stuff
like headers and footers. But the main content of each page is
typically different and requires different HTML. Otherwise every page
on the web would look the same.

As I said before - there are a bunch of templating systems out there -
but even with the best, you still need to create the content for each page.

For instance - your home page should describe your company/organization,
what you do, etc. It probably won't have any tables in it. But a page
from your catalog will have to list one or more products and will look
different. And a page comparing similar products will look different yet.

2. Also misleadingly in a subsequently post I made a boo-boo in
indicating data values would be included in the flat file - not true,
the form would request this.

OK, so you're talking about a template based on text files. But the
same rules above apply.

3. I thought the tricky bit would be creating the flat file ie
retrieving DB tables/fields and combining these with web page
specifications (optional/mandatory fields, controls, images etc). This
really is the crux. You would have to know what tables/fields to
expect. If a web page has a mandatory field specified and the field is
not one of those retrieved from the DB then maybe that's an abort.
Whereas if it's optional then we can go ahead and create the flat
file.

Yes, and that will be different for each page. Additionally, how you
display that data will often be different for each page, as noted above.

As for 1. above I will search on : simple templating systems. Thanks.

There are ways to make things easier. But there is no way to make
everything the same, unless all of the pages look the same.

You could create a templating system where you have an admin page and
fill in the blanks with the database information. But it still really
restricts you on how that data is going to be displayed. The other
option would be to store the HTML in the database also - but that means
your data is only good for the website itself. If later you wanted to
do something like create an RSS feed of your catalog, the data in the
database would be virtually worthless unless you did some really
complicated cleaning of it.

I'm not saying it's not a good idea. But not all good ideas can be
translated into workable ones.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[lxy one]

On 6 Jun, 22:30, Jerry Stuckle <[e-mail]:

lxy one wrote:

On 6 Jun, 18:06, Jerry Stuckle <[e-mail]:

lxy one wrote:
On 6 Jun, 11:39, Jerry Stuckle <[e-mail]:
lxy one wrote:
On 6 Jun, 03:30, Jerry Stuckle <[e-mail]:
[e-mail] wrote:
>Using a flat file containing table names, fields, values whats the
>best way of creating html pages?
>I want control over the html pages ie
>1. layout
>2. what data to show
>3. what controls to show - text boxes, input boxes, buttons,
>hyperlinks ie the usual.
>The data is not obtained directly from a database.
>I was thinking maybe the flat file could use xml. And maybe this flat
>file could be generated using :
>1. the database data and
>2. a template file to indicate the controls that should appear on each
>html page.
>Maybe there could be existing html pages that could be used in the
>generation of the required final html pages ie maybe they could
>contain static data - such as layout, headings and tags as to where
>fields, controls need to be placed.
>Searching on this is difficult as the key words are too common :
>create, html, xml, dynamic, template etc results in million+ hits.
If you're going to go to all that trouble, why not just create the html
page from the flat file and store it as a static page? Then when the
flat file changes, regenerate the html.
Much simpler (and server-friendly) than recreating the same page on
every request.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================
Hi Jerry,
But thats exactly what I want to do.
1. Create a flat file that will contain
-a) tables/fields+data values
-b) web page(form) details ie the fields/controls to appear on each
web page.
2. Generate the (static) web pages from the flat file.
3. If flat file is updated then update web pages.
OK, I understand better now.
So the issues are :
1. flat file - what format should this be in - xml ?
The simple answer is - whatever form suits you best. I've seen xml
files, csv files, php code and even just plain text. It all depends on
the data and what's easiest for you.
I would think that since your file needs to contain tables/fields and
data, xml might be easiest to parse and maintain. But that's probably
because I've worked with xml a fair amount. But if you haven't, another
form (such as csv) might be easier.
2. How to generate the (static) web pages (forms) from the flat file
bearing in mind that I would like to control over what web pages +
tables/fields/data + controls are created.
Well, you'll have to read the file then display all of the information
on a web page. Then select the information you wish to display.
Finally, generate the page.
But maybe this is to difficult. Maybe it would be easier to have the
static web pages I want already created. The pages could have tags to
indicate where fields + controls (if available in the flat file)
should go.
You're now talking about a templating system, which is very popular.
The nice thing about it is it takes a lot of the "grunt work" out of the
code required to generate the page. It also separates the rest of the
page from the actual data being displayed, making it easier to maintain.
I would have thought something flexible like this : generating static
web pages using data/controls from a flat file : had already been done
but I've not found anything yet.
I've used it before, when the data doesn't change very often. It can be
very effective on high usage sites. For lower usage sites and data
which changes fairly regularly, I just generate the pages dynamically on
request.
And I think you'll find most of the systems use a database instead of a
flat file. It makes things a lot easier - the database manages the data
for you, so you don't have to do as much in your code. Simple SQL
requests are not that hard to learn, and if you're going to be serious
about web development, they're pretty much a requirement nowadays. SQL
is just too powerful to ignore.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================
Hi Jerry,
Can you point me code examples please as I'm new to this.
As to why a flat file instead of a DB - the idea for the flat file was
that it would combine both table data and form data to allow the
generation of each web page.
Unfortunately, that's very difficult. Every system I've done like this
has been a custom system - with widely varying differences in amount of
code and difficulty. Every database has been different, also.

My suggestion would be to use google to find some simple templating
systems and see how they do it. There are a bunch out there.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================

Jerry, David,

I think I've not been clear on what I'm after and I guess that's
because I'm still pondering the problem.

1. Although tables/fields may vary, the creation of the static web
pages would be a one off ie once up and running no changes would be
expected. The reason for working this way, generating web pages, is to
cater for having different tables/fields and web page specifications.
So instead of having sets of static web pages to create/maintain you
can just create a new set by modifying a flat file. I cannot help
thinking that this must have been done.

This really can't be done. You can create templates for common stuff
like headers and footers. But the main content of each page is
typically different and requires different HTML. Otherwise every page
on the web would look the same.

As I said before - there are a bunch of templating systems out there -
but even with the best, you still need to create the content for each page.

For instance - your home page should describe your company/organization,
what you do, etc. It probably won't have any tables in it. But a page
from your catalog will have to list one or more products and will look
different. And a page comparing similar products will look different yet.

2. Also misleadingly in a subsequently post I made a boo-boo in
indicating data values would be included in the flat file - not true,
the form would request this.

OK, so you're talking about a template based on text files. But the
same rules above apply.

3. I thought the tricky bit would be creating the flat file ie
retrieving DB tables/fields and combining these with web page
specifications (optional/mandatory fields, controls, images etc). This
really is the crux. You would have to know what tables/fields to
expect. If a web page has a mandatory field specified and the field is
not one of those retrieved from the DB then maybe that's an abort.
Whereas if it's optional then we can go ahead and create the flat
file.

Yes, and that will be different for each page. Additionally, how you
display that data will often be different for each page, as noted above.

As for 1. above I will search on : simple templating systems. Thanks.

There are ways to make things easier. But there is no way to make
everything the same, unless all of the pages look the same.

You could create a templating system where you have an admin page and
fill in the blanks with the database information. But it still really
restricts you on how that data is going to be displayed. The other
option would be to store the HTML in the database also - but that means
your data is only good for the website itself. If later you wanted to
do something like create an RSS feed of your catalog, the data in the
database would be virtually worthless unless you did some really
complicated cleaning of it.

I'm not saying it's not a good idea. But not all good ideas can be
translated into workable ones.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================

I understand what you are saying here :

This really can't be done. You can create templates for common stuff
like headers and footers. But the main content of each page is
typically different and requires different HTML. Otherwise every page
on the web would look the same.

but why can't you specify content? For the look and layout a dynamic
web template could be used and for page content the flat file could
have something like :
---------------
web page 1
<content>
input box + properties eg page centered
submit button + properties
web page 2
<content>
table + properties
field1 and so on
---------------

[Jerry Stuckle]

lxy one wrote:

On 6 Jun, 22:30, Jerry Stuckle <[e-mail]:

>lxy one wrote:

>>On 6 Jun, 18:06, Jerry Stuckle <[e-mail]:
lxy one wrote:
On 6 Jun, 11:39, Jerry Stuckle <[e-mail]:
>lxy one wrote:
>>On 6 Jun, 03:30, Jerry Stuckle <[e-mail]:
>>>[e-mail] wrote:
>>>>Using a flat file containing table names, fields, values whats the
>>>>best way of creating html pages?
>>>>I want control over the html pages ie
>>>>1. layout
>>>>2. what data to show
>>>>3. what controls to show - text boxes, input boxes, buttons,
>>>>hyperlinks ie the usual.
>>>>The data is not obtained directly from a database.
>>>>I was thinking maybe the flat file could use xml. And maybe this flat
>>>>file could be generated using :
>>>>1. the database data and
>>>>2. a template file to indicate the controls that should appear on each
>>>>html page.
>>>>Maybe there could be existing html pages that could be used in the
>>>>generation of the required final html pages ie maybe they could
>>>>contain static data - such as layout, headings and tags as to where
>>>>fields, controls need to be placed.
>>>>Searching on this is difficult as the key words are too common :
>>>>create, html, xml, dynamic, template etc results in million+ hits.
>>>If you're going to go to all that trouble, why not just create the html
>>>page from the flat file and store it as a static page? Then when the
>>>flat file changes, regenerate the html.
>>>Much simpler (and server-friendly) than recreating the same page on
>>>every request.
>>>--
>>>==================
>>>Remove the "x" from my email address
>>>Jerry Stuckle
>>>JDS Computer Training Corp.
>>>[e-mail]
>>>==================
>>Hi Jerry,
>>But thats exactly what I want to do.
>>1. Create a flat file that will contain
>>-a) tables/fields+data values
>>-b) web page(form) details ie the fields/controls to appear on each
>>web page.
>>2. Generate the (static) web pages from the flat file.
>>3. If flat file is updated then update web pages.
>OK, I understand better now.
>>So the issues are :
>>1. flat file - what format should this be in - xml ?
>The simple answer is - whatever form suits you best. I've seen xml
>files, csv files, php code and even just plain text. It all depends on
>the data and what's easiest for you.
>I would think that since your file needs to contain tables/fields and
>data, xml might be easiest to parse and maintain. But that's probably
>because I've worked with xml a fair amount. But if you haven't, another
>form (such as csv) might be easier.
>>2. How to generate the (static) web pages (forms) from the flat file
>>bearing in mind that I would like to control over what web pages +
>>tables/fields/data + controls are created.
>Well, you'll have to read the file then display all of the information
>on a web page. Then select the information you wish to display.
>Finally, generate the page.
>>But maybe this is to difficult. Maybe it would be easier to have the
>>static web pages I want already created. The pages could have tags to
>>indicate where fields + controls (if available in the flat file)
>>should go.
>You're now talking about a templating system, which is very popular.
>The nice thing about it is it takes a lot of the "grunt work" out of the
>code required to generate the page. It also separates the rest of the
>page from the actual data being displayed, making it easier to maintain.
>>I would have thought something flexible like this : generating static
>>web pages using data/controls from a flat file : had already been done
>>but I've not found anything yet.
>I've used it before, when the data doesn't change very often. It can be
>very effective on high usage sites. For lower usage sites and data
>which changes fairly regularly, I just generate the pages dynamically on
>request.
>And I think you'll find most of the systems use a database instead of a
>flat file. It makes things a lot easier - the database manages the data
>for you, so you don't have to do as much in your code. Simple SQL
>requests are not that hard to learn, and if you're going to be serious
>about web development, they're pretty much a requirement nowadays. SQL
>is just too powerful to ignore.
>--
>==================
>Remove the "x" from my email address
>Jerry Stuckle
>JDS Computer Training Corp.
>[e-mail]
>==================
Hi Jerry,
Can you point me code examples please as I'm new to this.
As to why a flat file instead of a DB - the idea for the flat file was
that it would combine both table data and form data to allow the
generation of each web page.
Unfortunately, that's very difficult. Every system I've done like this
has been a custom system - with widely varying differences in amount of
code and difficulty. Every database has been different, also.
My suggestion would be to use google to find some simple templating
systems and see how they do it. There are a bunch out there.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================
Jerry, David,
I think I've not been clear on what I'm after and I guess that's
because I'm still pondering the problem.
1. Although tables/fields may vary, the creation of the static web
pages would be a one off ie once up and running no changes would be
expected. The reason for working this way, generating web pages, is to
cater for having different tables/fields and web page specifications.
So instead of having sets of static web pages to create/maintain you
can just create a new set by modifying a flat file. I cannot help
thinking that this must have been done.

This really can't be done. You can create templates for common stuff
like headers and footers. But the main content of each page is
typically different and requires different HTML. Otherwise every page
on the web would look the same.

As I said before - there are a bunch of templating systems out there -
but even with the best, you still need to create the content for each page.

For instance - your home page should describe your company/organization,
what you do, etc. It probably won't have any tables in it. But a page
from your catalog will have to list one or more products and will look
different. And a page comparing similar products will look different yet.

>>2. Also misleadingly in a subsequently post I made a boo-boo in
indicating data values would be included in the flat file - not true,
the form would request this.

OK, so you're talking about a template based on text files. But the
same rules above apply.

>>3. I thought the tricky bit would be creating the flat file ie
retrieving DB tables/fields and combining these with web page
specifications (optional/mandatory fields, controls, images etc). This
really is the crux. You would have to know what tables/fields to
expect. If a web page has a mandatory field specified and the field is
not one of those retrieved from the DB then maybe that's an abort.
Whereas if it's optional then we can go ahead and create the flat
file.

Yes, and that will be different for each page. Additionally, how you
display that data will often be different for each page, as noted above.

>>As for 1. above I will search on : simple templating systems. Thanks.

There are ways to make things easier. But there is no way to make
everything the same, unless all of the pages look the same.

You could create a templating system where you have an admin page and
fill in the blanks with the database information. But it still really
restricts you on how that data is going to be displayed. The other
option would be to store the HTML in the database also - but that means
your data is only good for the website itself. If later you wanted to
do something like create an RSS feed of your catalog, the data in the
database would be virtually worthless unless you did some really
complicated cleaning of it.

I'm not saying it's not a good idea. But not all good ideas can be
translated into workable ones.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================

I understand what you are saying here :

>This really can't be done. You can create templates for common stuff
like headers and footers. But the main content of each page is
typically different and requires different HTML. Otherwise every page
on the web would look the same.

but why can't you specify content? For the look and layout a dynamic
web template could be used and for page content the flat file could
have something like :
---------------
web page 1
<content>
input box + properties eg page centered
submit button + properties
web page 2
<content>
table + properties
field1 and so on
---------------

You can - in the content section of the page itself. As I said before -
you don't want the HTML itself in your database (or whatever), because
then it because unusable for anything else without a lot of parsing.

You should always separate the data being displayed from the display of
the data (html). Mixing the two just makes things a lot more complicated.

So what templating systems do is:

Template:
header
<content>
footer

Each page then has its own content.

Alternatively, you could have a header file and a footer file, and
include those in each page before and after the content section.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[lxy one]

On 7 Jun, 11:27, Jerry Stuckle <[e-mail]:

lxy one wrote:

On 6 Jun, 22:30, Jerry Stuckle <[e-mail]:

lxy one wrote:
On 6 Jun, 18:06, Jerry Stuckle <[e-mail]:
lxy one wrote:
On 6 Jun, 11:39, Jerry Stuckle <[e-mail]:
lxy one wrote:
>On 6 Jun, 03:30, Jerry Stuckle <[e-mail]:
>>[e-mail] wrote:
>>>Using a flat file containing table names, fields, values whats the
>>>best way of creating html pages?
>>>I want control over the html pages ie
>>>1. layout
>>>2. what data to show
>>>3. what controls to show - text boxes, input boxes, buttons,
>>>hyperlinks ie the usual.
>>>The data is not obtained directly from a database.
>>>I was thinking maybe the flat file could use xml. And maybe this flat
>>>file could be generated using :
>>>1. the database data and
>>>2. a template file to indicate the controls that should appear on each
>>>html page.
>>>Maybe there could be existing html pages that could be used in the
>>>generation of the required final html pages ie maybe they could
>>>contain static data - such as layout, headings and tags as to where
>>>fields, controls need to be placed.
>>>Searching on this is difficult as the key words are too common :
>>>create, html, xml, dynamic, template etc results in million+ hits.
>>If you're going to go to all that trouble, why not just create the html
>>page from the flat file and store it as a static page? Then when the
>>flat file changes, regenerate the html.
>>Much simpler (and server-friendly) than recreating the same page on
>>every request.
>>--
>>==================
>>Remove the "x" from my email address
>>Jerry Stuckle
>>JDS Computer Training Corp.
>>[e-mail]
>>==================
>Hi Jerry,
>But thats exactly what I want to do.
>1. Create a flat file that will contain
>-a) tables/fields+data values
>-b) web page(form) details ie the fields/controls to appear on each
>web page.
>2. Generate the (static) web pages from the flat file.
>3. If flat file is updated then update web pages.
OK, I understand better now.
>So the issues are :
>1. flat file - what format should this be in - xml ?
The simple answer is - whatever form suits you best. I've seen xml
files, csv files, php code and even just plain text. It all depends on
the data and what's easiest for you.
I would think that since your file needs to contain tables/fields and
data, xml might be easiest to parse and maintain. But that's probably
because I've worked with xml a fair amount. But if you haven't, another
form (such as csv) might be easier.
>2. How to generate the (static) web pages (forms) from the flat file
>bearing in mind that I would like to control over what web pages +
>tables/fields/data + controls are created.
Well, you'll have to read the file then display all of the information
on a web page. Then select the information you wish to display.
Finally, generate the page.
>But maybe this is to difficult. Maybe it would be easier to have the
>static web pages I want already created. The pages could have tags to
>indicate where fields + controls (if available in the flat file)
>should go.
You're now talking about a templating system, which is very popular.
The nice thing about it is it takes a lot of the "grunt work" out of the
code required to generate the page. It also separates the rest of the
page from the actual data being displayed, making it easier to maintain.
>I would have thought something flexible like this : generating static
>web pages using data/controls from a flat file : had already been done
>but I've not found anything yet.
I've used it before, when the data doesn't change very often. It can be
very effective on high usage sites. For lower usage sites and data
which changes fairly regularly, I just generate the pages dynamically on
request.
And I think you'll find most of the systems use a database instead of a
flat file. It makes things a lot easier - the database manages the data
for you, so you don't have to do as much in your code. Simple SQL
requests are not that hard to learn, and if you're going to be serious
about web development, they're pretty much a requirement nowadays. SQL
is just too powerful to ignore.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================
Hi Jerry,
Can you point me code examples please as I'm new to this.
As to why a flat file instead of a DB - the idea for the flat file was
that it would combine both table data and form data to allow the
generation of each web page.
Unfortunately, that's very difficult. Every system I've done like this
has been a custom system - with widely varying differences in amount of
code and difficulty. Every database has been different, also.
My suggestion would be to use google to find some simple templating
systems and see how they do it. There are a bunch out there.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================
Jerry, David,
I think I've not been clear on what I'm after and I guess that's
because I'm still pondering the problem.
1. Although tables/fields may vary, the creation of the static web
pages would be a one off ie once up and running no changes would be
expected. The reason for working this way, generating web pages, is to
cater for having different tables/fields and web page specifications.
So instead of having sets of static web pages to create/maintain you
can just create a new set by modifying a flat file. I cannot help
thinking that this must have been done.
This really can't be done. You can create templates for common stuff
like headers and footers. But the main content of each page is
typically different and requires different HTML. Otherwise every page
on the web would look the same.

As I said before - there are a bunch of templating systems out there -
but even with the best, you still need to create the content for each page.

For instance - your home page should describe your company/organization,
what you do, etc. It probably won't have any tables in it. But a page
from your catalog will have to list one or more products and will look
different. And a page comparing similar products will look different yet.

>2. Also misleadingly in a subsequently post I made a boo-boo in
indicating data values would be included in the flat file - not true,
the form would request this.
OK, so you're talking about a template based on text files. But the
same rules above apply.

>3. I thought the tricky bit would be creating the flat file ie
retrieving DB tables/fields and combining these with web page
specifications (optional/mandatory fields, controls, images etc). This
really is the crux. You would have to know what tables/fields to
expect. If a web page has a mandatory field specified and the field is
not one of those retrieved from the DB then maybe that's an abort.
Whereas if it's optional then we can go ahead and create the flat
file.
Yes, and that will be different for each page. Additionally, how you
display that data will often be different for each page, as noted above.

>As for 1. above I will search on : simple templating systems. Thanks.
There are ways to make things easier. But there is no way to make
everything the same, unless all of the pages look the same.

You could create a templating system where you have an admin page and
fill in the blanks with the database information. But it still really
restricts you on how that data is going to be displayed. The other
option would be to store the HTML in the database also - but that means
your data is only good for the website itself. If later you wanted to
do something like create an RSS feed of your catalog, the data in the
database would be virtually worthless unless you did some really
complicated cleaning of it.

I'm not saying it's not a good idea. But not all good ideas can be
translated into workable ones.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================

I understand what you are saying here :

This really can't be done. You can create templates for common stuff
like headers and footers. But the main content of each page is
typically different and requires different HTML. Otherwise every page
on the web would look the same.

but why can't you specify content? For the look and layout a dynamic
web template could be used and for page content the flat file could
have something like :
---------------
web page 1
<content>
input box + properties eg page centered
submit button + properties
web page 2
<content>
table + properties
field1 and so on
---------------

You can - in the content section of the page itself. As I said before -
you don't want the HTML itself in your database (or whatever), because
then it because unusable for anything else without a lot of parsing.

You should always separate the data being displayed from the display of
the data (html). Mixing the two just makes things a lot more complicated.

So what templating systems do is:

Template:
header
<content>
footer

Each page then has its own content.

Alternatively, you could have a header file and a footer file, and
include those in each page before and after the content section.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================

Hi Jerry,

Having a DB seems an extra to me.
I would have thought the flat file (web page content - fields
+controls) would be sufficient to generate the web pages.
I think the first operation would be to determine if the tables/fields
in the file really exit.
If they do not and are mandatory then thats a problem, if optional
they are not included in generation of web pages.
Second operation is generation of the pages.
Wy go the trouble of inserting the flat file details into a DB?

[Satya]

On Jun 8, 3:59*pm, lxy one <[e-mail]:

On 7 Jun, 11:27, Jerry Stuckle <[e-mail]:

lxy one wrote:

On 6 Jun, 22:30, Jerry Stuckle <[e-mail]:
>lxy one wrote:
>>On 6 Jun, 18:06, Jerry Stuckle <[e-mail]:
>>>lxy one wrote:
>>>>On 6 Jun, 11:39, Jerry Stuckle <[e-mail]:
>>>>>lxy one wrote:
>>>>>>On 6 Jun, 03:30, Jerry Stuckle <[e-mail]:
>>>>>>>[e-mail] wrote:
>>>>>>>>Using a flat file containing table names, fields, values whatsthe
>>>>>>>>best way of creating html pages?
>>>>>>>>I want control over the html pages ie
>>>>>>>>1. layout
>>>>>>>>2. what data to show
>>>>>>>>3. what controls to show *- text boxes, input boxes, buttons,
>>>>>>>>hyperlinks ie the usual.
>>>>>>>>The data is not obtained directly from a database.
>>>>>>>>I was thinking maybe the flat file could use xml. And maybe this flat
>>>>>>>>file could be generated using *:
>>>>>>>>1. *the database data and
>>>>>>>>2. a template file to indicate the controls that should appearon each
>>>>>>>>html page.
>>>>>>>>Maybe there could be existing html pages that could be used inthe
>>>>>>>>generation of the required final html pages ie maybe they could
>>>>>>>>contain static data - such as layout, headings and tags as to where
>>>>>>>>fields, controls need to be placed.
>>>>>>>>Searching on this is difficult as the key words are too common:
>>>>>>>>create, html, xml, dynamic, template etc results in million+ hits.
>>>>>>>If you're going to go to all that trouble, why not just create the html
>>>>>>>page from the flat file and store it as a static page? *Then when the
>>>>>>>flat file changes, regenerate the html.
>>>>>>>Much simpler (and server-friendly) than recreating the same page on
>>>>>>>every request.
>>>>>>>--
>>>>>>>==================
>>>>>>>Remove the "x" from my email address
>>>>>>>Jerry Stuckle
>>>>>>>JDS Computer Training Corp.
>>>>>>>[e-mail]
>>>>>>>==================
>>>>>>Hi Jerry,
>>>>>>But thats exactly what I want to do.
>>>>>>1. Create a flat file that will contain
>>>>>>-a) tables/fields+data values
>>>>>>-b) web page(form) details ie the fields/controls to appear on each
>>>>>>web page.
>>>>>>2. Generate the (static) web pages from the flat file.
>>>>>>3. If flat file is updated then update web pages.
>>>>>OK, I understand better now.
>>>>>>So the issues are :
>>>>>>1. flat file - what format should this be in - xml ?
>>>>>The simple answer is - whatever form suits you best. *I've seenxml
>>>>>files, csv files, php code and even just plain text. *It all depends on
>>>>>the data and what's easiest for you.
>>>>>I would think that since your file needs to contain tables/fieldsand
>>>>>data, xml might be easiest to parse and maintain. *But that's probably
>>>>>because I've worked with xml a fair amount. *But if you haven't, another
>>>>>form (such as csv) might be easier.
>>>>>>2. How to generate the (static) web pages (forms) from the flat file
>>>>>>bearing in mind that I would like to control over what web pages+
>>>>>>tables/fields/data + controls are created.
>>>>>Well, you'll have to read the file then display all of the information
>>>>>on a web page. *Then select the information you wish to display..
>>>>>Finally, generate the page.
>>>>>>But maybe this is to difficult. Maybe it would be easier to havethe
>>>>>>static web pages I want already created. The pages could have tags to
>>>>>>indicate where fields + controls (if available in the flat file)
>>>>>>should go.
>>>>>You're now talking about a templating system, which is very popular.
>>>>>The nice thing about it is it takes a lot of the "grunt work" outof the
>>>>>code required to generate the page. *It also separates the restof the
>>>>>page from the actual data being displayed, making it easier to maintain.
>>>>>>I would have thought something flexible like this : generating static
>>>>>>web pages using data/controls from a flat file : had already been done
>>>>>>but I've not found anything yet.
>>>>>I've used it before, when the data doesn't change very often. *It can be
>>>>>very effective on high usage sites. *For lower usage sites and data
>>>>>which changes fairly regularly, I just generate the pages dynamically on
>>>>>request.
>>>>>And I think you'll find most of the systems use a database instead of a
>>>>>flat file. *It makes things a lot easier - the database managesthe data
>>>>>for you, so you don't have to do as much in your code. *Simple SQL
>>>>>requests are not that hard to learn, and if you're going to be serious
>>>>>about web development, they're pretty much a requirement nowadays.. *SQL
>>>>>is just too powerful to ignore.
>>>>>--
>>>>>==================
>>>>>Remove the "x" from my email address
>>>>>Jerry Stuckle
>>>>>JDS Computer Training Corp.
>>>>>[e-mail]
>>>>>==================
>>>>Hi Jerry,
>>>>Can you point me code examples please as I'm new to this.
>>>>As to why a flat file instead of a DB - the idea for the flat filewas
>>>>that it would combine both table data and form data to allow the
>>>>generation of each web page.
>>>Unfortunately, that's very difficult. *Every system I've done like this
>>>has been a custom system - with widely varying differences in amount of
>>>code and difficulty. *Every database has been different, also.
>>>My suggestion would be to use google to find some simple templating
>>>systems and see how they do it. *There are a bunch out there.
>>>--
>>>==================
>>>Remove the "x" from my email address
>>>Jerry Stuckle
>>>JDS Computer Training Corp.
>>>[e-mail]
>>>==================
>>Jerry, David,
>>I think I've not been clear on what I'm after and I guess that's
>>because I'm still pondering the problem.
>>1. Although tables/fields may vary, the creation of the static web
>>pages would be a one off ie *once up and running no changes would be
>>expected. The reason for working this way, generating web pages, is to
>>cater for having different tables/fields and web page specifications..
>>So instead of having sets of static web pages to create/maintain you
>>can just create a new set by modifying a flat file. I cannot help
>>thinking that this must have been done.
>This really can't be done. *You can create templates for common stuff
>like headers and footers. *But the main content of each page is
>typically different and requires different HTML. *Otherwise every page
>on the web would look the same.

>As I said before - there are a bunch of templating systems out there -
>but even with the best, you still need to create the content for eachpage.

>For instance - your home page should describe your company/organization,
>what you do, etc. *It probably won't have any tables in it. *But a page
>from your catalog will have to list one or more products and will look
>different. *And a page comparing similar products will look different yet.

>>2. Also misleadingly in a subsequently post I made a boo-boo in
>>indicating data values would be included in the flat file - not true,
>>the form would request this.
>OK, so you're talking about a template based on text files. *But the
>same rules above apply.

>>3. I thought the tricky bit would be creating the flat file ie
>>retrieving DB tables/fields and combining these with web page
>>specifications (optional/mandatory fields, controls, images etc). This
>>really is the crux. You would have to know what tables/fields to
>>expect. If a web page has a mandatory field specified and the field is
>>not one of those retrieved from the DB then maybe that's an abort.
>>Whereas if it's optional then we can go ahead and create the flat
>>file.
>Yes, and that will be different for each page. *Additionally, how you
>display that data will often be different for each page, as noted above.

>>As for 1. above I will search on : simple templating systems. Thanks..
>There are ways to make things easier. *But there is no way to make
>everything the same, unless all of the pages look the same.

>You could create a templating system where you have an admin page and
>fill in the blanks with the database information. *But it still really
>restricts you on how that data is going to be displayed. *The other
>option would be to store the HTML in the database also - but that means
>your data is only good for the website itself. *If later you wantedto
>do something like create an RSS feed of your catalog, the data in the
>database would be virtually worthless unless you did some really
>complicated cleaning of it.

>I'm not saying it's not a good idea. *But not all good ideas can be
>translated into workable ones.

>--
>==================
>Remove the "x" from my email address
>Jerry Stuckle
>JDS Computer Training Corp.
>[e-mail]
>==================

I understand what you are saying here :

>This really can't be done. *You can create templates for common stuff
>like headers and footers. *But the main content of each page is
>typically different and requires different HTML. *Otherwise every page
>on the web would look the same.

but why can't you specify content? For the look and layout a dynamic
web template could be used and for page content the flat file could
have something like :
---------------
web page 1
<content>
input box + properties eg page- Hide quoted text -

- Show quoted text -...

read more »

What about you just create a php page (basically html page) like this:
testPage.php
<?php
ob_start();
// Now read the data from whereever you like
$name = '';
$age = '';

?>
<html>
<head.... </head>
<body>

...
<table><tr<td>

Name: <?php echo $name ?>
</td>
...
</table>

<!--and now take the html output : -->
<?php
$content = ob_get_contents();
ob_end_clean();
//echo $content; // save this content to any new file with html name
(as you wanted) in the web directory.
// and your html is ready and this template is preserved depending on
the data from other file or database comes.
?>
========

I think you are looking for content/data caching solution also. I do
not like smarty template. PHP itself is template lang.
Just i like their content caching functionality. I thing you can
search for something like that. or check smarty allow using caching
tech. without using their template lang. you can allow the php script
in template anyway.

[lxy one]

On 9 Jun, 05:24, Satya <[e-mail]:

On Jun 8, 3:59 pm, lxy one <[e-mail]:

On 7 Jun, 11:27, Jerry Stuckle <[e-mail]:

lxy one wrote:
On 6 Jun, 22:30, Jerry Stuckle <[e-mail]:
lxy one wrote:
>On 6 Jun, 18:06, Jerry Stuckle <[e-mail]:
>>lxy one wrote:
>>>On 6 Jun, 11:39, Jerry Stuckle <[e-mail]:
>>>>lxy one wrote:
>>>>>On 6 Jun, 03:30, Jerry Stuckle <[e-mail]:
>>>>>>[e-mail] wrote:
>>>>>>>Using a flat file containing table names, fields, values whats the
>>>>>>>best way of creating html pages?
>>>>>>>I want control over the html pages ie
>>>>>>>1. layout
>>>>>>>2. what data to show
>>>>>>>3. what controls to show - text boxes, input boxes, buttons,
>>>>>>>hyperlinks ie the usual.
>>>>>>>The data is not obtained directly from a database.
>>>>>>>I was thinking maybe the flat file could use xml. And maybe this flat
>>>>>>>file could be generated using :
>>>>>>>1. the database data and
>>>>>>>2. a template file to indicate the controls that should appear on each
>>>>>>>html page.
>>>>>>>Maybe there could be existing html pages that could be used in the
>>>>>>>generation of the required final html pages ie maybe they could
>>>>>>>contain static data - such as layout, headings and tags as to where
>>>>>>>fields, controls need to be placed.
>>>>>>>Searching on this is difficult as the key words are too common :
>>>>>>>create, html, xml, dynamic, template etc results in million+hits.
>>>>>>If you're going to go to all that trouble, why not just create the html
>>>>>>page from the flat file and store it as a static page? Then when the
>>>>>>flat file changes, regenerate the html.
>>>>>>Much simpler (and server-friendly) than recreating the same page on
>>>>>>every request.
>>>>>>--
>>>>>>==================
>>>>>>Remove the "x" from my email address
>>>>>>Jerry Stuckle
>>>>>>JDS Computer Training Corp.
>>>>>>[e-mail]
>>>>>>==================
>>>>>Hi Jerry,
>>>>>But thats exactly what I want to do.
>>>>>1. Create a flat file that will contain
>>>>>-a) tables/fields+data values
>>>>>-b) web page(form) details ie the fields/controls to appear oneach
>>>>>web page.
>>>>>2. Generate the (static) web pages from the flat file.
>>>>>3. If flat file is updated then update web pages.
>>>>OK, I understand better now.
>>>>>So the issues are :
>>>>>1. flat file - what format should this be in - xml ?
>>>>The simple answer is - whatever form suits you best. I've seenxml
>>>>files, csv files, php code and even just plain text. It all depends on
>>>>the data and what's easiest for you.
>>>>I would think that since your file needs to contain tables/fields and
>>>>data, xml might be easiest to parse and maintain. But that's probably
>>>>because I've worked with xml a fair amount. But if you haven't, another
>>>>form (such as csv) might be easier.
>>>>>2. How to generate the (static) web pages (forms) from the flat file
>>>>>bearing in mind that I would like to control over what web pages +
>>>>>tables/fields/data + controls are created.
>>>>Well, you'll have to read the file then display all of the information
>>>>on a web page. Then select the information you wish to display..
>>>>Finally, generate the page.
>>>>>But maybe this is to difficult. Maybe it would be easier to have the
>>>>>static web pages I want already created. The pages could have tags to
>>>>>indicate where fields + controls (if available in the flat file)
>>>>>should go.
>>>>You're now talking about a templating system, which is very popular.
>>>>The nice thing about it is it takes a lot of the "grunt work" out of the
>>>>code required to generate the page. It also separates the restof the
>>>>page from the actual data being displayed, making it easier to maintain.
>>>>>I would have thought something flexible like this : generatingstatic
>>>>>web pages using data/controls from a flat file : had already been done
>>>>>but I've not found anything yet.
>>>>I've used it before, when the data doesn't change very often. It can be
>>>>very effective on high usage sites. For lower usage sites and data
>>>>which changes fairly regularly, I just generate the pages dynamically on
>>>>request.
>>>>And I think you'll find most of the systems use a database instead of a
>>>>flat file. It makes things a lot easier - the database managesthe data
>>>>for you, so you don't have to do as much in your code. Simple SQL
>>>>requests are not that hard to learn, and if you're going to be serious
>>>>about web development, they're pretty much a requirement nowadays. SQL
>>>>is just too powerful to ignore.
>>>>--
>>>>==================
>>>>Remove the "x" from my email address
>>>>Jerry Stuckle
>>>>JDS Computer Training Corp.
>>>>[e-mail]
>>>>==================
>>>Hi Jerry,
>>>Can you point me code examples please as I'm new to this.
>>>As to why a flat file instead of a DB - the idea for the flat file was
>>>that it would combine both table data and form data to allow the
>>>generation of each web page.
>>Unfortunately, that's very difficult. Every system I've done like this
>>has been a custom system - with widely varying differences in amount of
>>code and difficulty. Every database has been different, also.
>>My suggestion would be to use google to find some simple templating
>>systems and see how they do it. There are a bunch out there.
>>--
>>==================
>>Remove the "x" from my email address
>>Jerry Stuckle
>>JDS Computer Training Corp.
>>[e-mail]
>>==================
>Jerry, David,
>I think I've not been clear on what I'm after and I guess that's
>because I'm still pondering the problem.
>1. Although tables/fields may vary, the creation of the static web
>pages would be a one off ie once up and running no changes would be
>expected. The reason for working this way, generating web pages, is to
>cater for having different tables/fields and web page specifications.
>So instead of having sets of static web pages to create/maintain you
>can just create a new set by modifying a flat file. I cannot help
>thinking that this must have been done.
This really can't be done. You can create templates for common stuff
like headers and footers. But the main content of each page is
typically different and requires different HTML. Otherwise every page
on the web would look the same.

As I said before - there are a bunch of templating systems out there -
but even with the best, you still need to create the content for each page.

For instance - your home page should describe your company/organization,
what you do, etc. It probably won't have any tables in it. But a page
from your catalog will have to list one or more products and will look
different. And a page comparing similar products will look different yet.

>2. Also misleadingly in a subsequently post I made a boo-boo in
>indicating data values would be included in the flat file - not true,
>the form would request this.
OK, so you're talking about a template based on text files. But the
same rules above apply.

>3. I thought the tricky bit would be creating the flat file ie
>retrieving DB tables/fields and combining these with web page
>specifications (optional/mandatory fields, controls, images etc). This
>really is the crux. You would have to know what tables/fields to
>expect. If a web page has a mandatory field specified and the field is
>not one of those retrieved from the DB then maybe that's an abort.
>Whereas if it's optional then we can go ahead and create the flat
>file.
Yes, and that will be different for each page. Additionally, how you
display that data will often be different for each page, as noted above.

>As for 1. above I will search on : simple templating systems. Thanks.
There are ways to make things easier. But there is no way to make
everything the same, unless all of the pages look the same.

You could create a templating system where you have an admin page and
fill in the blanks with the database information. But it still really
restricts you on how that data is going to be displayed. The other
option would be to store the HTML in the database also - but that means
your data is only good for the website itself. If later you wantedto
do something like create an RSS feed of your catalog, the data in the
database would be virtually worthless unless you did some really
complicated cleaning of it.

I'm not saying it's not a good idea. But not all good ideas can be
translated into workable ones.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================

I understand what you are saying here :

This really can't be done. You can create templates for common stuff
like headers and footers. But the main content of each page is
typically different and requires different HTML. Otherwise every page
on the web would look the same.

but why can't you specify content? For the look and layout a dynamic
web template could be used and for page content the flat file could
have something like :
---------------
web page 1
<content>
input box + properties eg page- Hide quoted text -

- Show quoted text -...

read more »

What about you just create a php page (basically html page) like this:
testPage.php
<?php
ob_start();
// Now read the data from whereever you like
$name = '';
$age = '';

?>
<html>
<head.... </head>
<body>

...
<table><tr<td>

Name: <?php echo $name ?>
</td>
...
</table>

<!--and now take the html output : -->
<?php
$content = ob_get_contents();
ob_end_clean();
//echo $content; // save this content to any new file with html name
(as you wanted) in the web directory.
// and your html is ready and this template is preserved depending on
the data from other file or database comes.

?>
========

I think you are looking for content/data caching solution also. I do
not like smarty template. PHP itself is template lang.
Just i like their content caching functionality. I thing you can
search for something like that. or check smarty allow using caching
tech. without using their template lang. you can allow the php script
in template anyway.

This is more like it Jerry thank you. I've not used php much and not
seen ob_start before - buffering looks very interesting. And I hadn't
thought of each web page populating itself.

I've had a rethink. What I am after is flexibility along the lines :
do you require a new control/field? then just add it to the flat file,
and regenerate the web page. However the more I look the more I think
I'm expecting too much.

Maybe this flexibility can be had but only so long as we are adding to
already existing control/fields ie that are inside a block where the
layout is already established. In the web page there could be a marker
tag for the start of where the control/fields are to (in your example
replace name and age with eg <mtagperson>. And the control/field
information is held in the flat file.

In this scenario the marker tag in the web page is replaced with the
control(s)/field(s) found in the flat file. This mechanism allows us
to add a new control/field to the end of a column or row. And of
course the flat file could be used to modify/delete an existing
control/field.

Two key problems are :
1. how the control/field information is held in the flat file.
2. how to do replace the marker tags in the html field with the flat
file's controls/fields.

Maybe the controls/fields can be straight html. Maybe the whole block
can be read in as per your example ie at the top, instead of retrieve
data the flat file is read.

(The data values would come from a user action. Prior to this the
fields need to be validated against a DB.)

[Jerry Stuckle]

lxy one wrote:

On 9 Jun, 05:24, Satya <[e-mail]:

>On Jun 8, 3:59 pm, lxy one <[e-mail]:

>>On 7 Jun, 11:27, Jerry Stuckle <[e-mail]:
lxy one wrote:
On 6 Jun, 22:30, Jerry Stuckle <[e-mail]:
>lxy one wrote:
>>On 6 Jun, 18:06, Jerry Stuckle <[e-mail]:
>>>lxy one wrote:
>>>>On 6 Jun, 11:39, Jerry Stuckle <[e-mail]:
>>>>>lxy one wrote:
>>>>>>On 6 Jun, 03:30, Jerry Stuckle <[e-mail]:
>>>>>>>[e-mail] wrote:
>>>>>>>>Using a flat file containing table names, fields, values whats the
>>>>>>>>best way of creating html pages?
>>>>>>>>I want control over the html pages ie
>>>>>>>>1. layout
>>>>>>>>2. what data to show
>>>>>>>>3. what controls to show - text boxes, input boxes, buttons,
>>>>>>>>hyperlinks ie the usual.
>>>>>>>>The data is not obtained directly from a database.
>>>>>>>>I was thinking maybe the flat file could use xml. And maybe this flat
>>>>>>>>file could be generated using :
>>>>>>>>1. the database data and
>>>>>>>>2. a template file to indicate the controls that should appear on each
>>>>>>>>html page.
>>>>>>>>Maybe there could be existing html pages that could be used in the
>>>>>>>>generation of the required final html pages ie maybe they could
>>>>>>>>contain static data - such as layout, headings and tags as to where
>>>>>>>>fields, controls need to be placed.
>>>>>>>>Searching on this is difficult as the key words are too common :
>>>>>>>>create, html, xml, dynamic, template etc results in million+ hits.
>>>>>>>If you're going to go to all that trouble, why not just create the html
>>>>>>>page from the flat file and store it as a static page? Then when the
>>>>>>>flat file changes, regenerate the html.
>>>>>>>Much simpler (and server-friendly) than recreating the same page on
>>>>>>>every request.
>>>>>>>--
>>>>>>>==================
>>>>>>>Remove the "x" from my email address
>>>>>>>Jerry Stuckle
>>>>>>>JDS Computer Training Corp.
>>>>>>>[e-mail]
>>>>>>>==================
>>>>>>Hi Jerry,
>>>>>>But thats exactly what I want to do.
>>>>>>1. Create a flat file that will contain
>>>>>>-a) tables/fields+data values
>>>>>>-b) web page(form) details ie the fields/controls to appear on each
>>>>>>web page.
>>>>>>2. Generate the (static) web pages from the flat file.
>>>>>>3. If flat file is updated then update web pages.
>>>>>OK, I understand better now.
>>>>>>So the issues are :
>>>>>>1. flat file - what format should this be in - xml ?
>>>>>The simple answer is - whatever form suits you best. I've seen xml
>>>>>files, csv files, php code and even just plain text. It all depends on
>>>>>the data and what's easiest for you.
>>>>>I would think that since your file needs to contain tables/fields and
>>>>>data, xml might be easiest to parse and maintain. But that's probably
>>>>>because I've worked with xml a fair amount. But if you haven't, another
>>>>>form (such as csv) might be easier.
>>>>>>2. How to generate the (static) web pages (forms) from the flat file
>>>>>>bearing in mind that I would like to control over what web pages +
>>>>>>tables/fields/data + controls are created.
>>>>>Well, you'll have to read the file then display all of the information
>>>>>on a web page. Then select the information you wish to display.
>>>>>Finally, generate the page.
>>>>>>But maybe this is to difficult. Maybe it would be easier to have the
>>>>>>static web pages I want already created. The pages could have tags to
>>>>>>indicate where fields + controls (if available in the flat file)
>>>>>>should go.
>>>>>You're now talking about a templating system, which is very popular.
>>>>>The nice thing about it is it takes a lot of the "grunt work" out of the
>>>>>code required to generate the page. It also separates the rest of the
>>>>>page from the actual data being displayed, making it easier to maintain.
>>>>>>I would have thought something flexible like this : generating static
>>>>>>web pages using data/controls from a flat file : had already been done
>>>>>>but I've not found anything yet.
>>>>>I've used it before, when the data doesn't change very often. It can be
>>>>>very effective on high usage sites. For lower usage sites and data
>>>>>which changes fairly regularly, I just generate the pages dynamically on
>>>>>request.
>>>>>And I think you'll find most of the systems use a database instead of a
>>>>>flat file. It makes things a lot easier - the database manages the data
>>>>>for you, so you don't have to do as much in your code. Simple SQL
>>>>>requests are not that hard to learn, and if you're going to be serious
>>>>>about web development, they're pretty much a requirement nowadays. SQL
>>>>>is just too powerful to ignore.
>>>>>--
>>>>>==================
>>>>>Remove the "x" from my email address
>>>>>Jerry Stuckle
>>>>>JDS Computer Training Corp.
>>>>>[e-mail]
>>>>>==================
>>>>Hi Jerry,
>>>>Can you point me code examples please as I'm new to this.
>>>>As to why a flat file instead of a DB - the idea for the flat file was
>>>>that it would combine both table data and form data to allow the
>>>>generation of each web page.
>>>Unfortunately, that's very difficult. Every system I've done like this
>>>has been a custom system - with widely varying differences in amount of
>>>code and difficulty. Every database has been different, also.
>>>My suggestion would be to use google to find some simple templating
>>>systems and see how they do it. There are a bunch out there.
>>>--
>>>==================
>>>Remove the "x" from my email address
>>>Jerry Stuckle
>>>JDS Computer Training Corp.
>>>[e-mail]
>>>==================
>>Jerry, David,
>>I think I've not been clear on what I'm after and I guess that's
>>because I'm still pondering the problem.
>>1. Although tables/fields may vary, the creation of the static web
>>pages would be a one off ie once up and running no changes would be
>>expected. The reason for working this way, generating web pages, is to
>>cater for having different tables/fields and web page specifications.
>>So instead of having sets of static web pages to create/maintain you
>>can just create a new set by modifying a flat file. I cannot help
>>thinking that this must have been done.
>This really can't be done. You can create templates for common stuff
>like headers and footers. But the main content of each page is
>typically different and requires different HTML. Otherwise every page
>on the web would look the same.
>As I said before - there are a bunch of templating systems out there -
>but even with the best, you still need to create the content for each page.
>For instance - your home page should describe your company/organization,
>what you do, etc. It probably won't have any tables in it. But a page
>from your catalog will have to list one or more products and will look
>different. And a page comparing similar products will look different yet.
>>2. Also misleadingly in a subsequently post I made a boo-boo in
>>indicating data values would be included in the flat file - not true,
>>the form would request this.
>OK, so you're talking about a template based on text files. But the
>same rules above apply.
>>3. I thought the tricky bit would be creating the flat file ie
>>retrieving DB tables/fields and combining these with web page
>>specifications (optional/mandatory fields, controls, images etc). This
>>really is the crux. You would have to know what tables/fields to
>>expect. If a web page has a mandatory field specified and the field is
>>not one of those retrieved from the DB then maybe that's an abort.
>>Whereas if it's optional then we can go ahead and create the flat
>>file.
>Yes, and that will be different for each page. Additionally, how you
>display that data will often be different for each page, as noted above.
>>As for 1. above I will search on : simple templating systems. Thanks.
>There are ways to make things easier. But there is no way to make
>everything the same, unless all of the pages look the same.
>You could create a templating system where you have an admin page and
>fill in the blanks with the database information. But it still really
>restricts you on how that data is going to be displayed. The other
>option would be to store the HTML in the database also - but that means
>your data is only good for the website itself. If later you wanted to
>do something like create an RSS feed of your catalog, the data in the
>database would be virtually worthless unless you did some really
>complicated cleaning of it.
>I'm not saying it's not a good idea. But not all good ideas can be
>translated into workable ones.
>--
>==================
>Remove the "x" from my email address
>Jerry Stuckle
>JDS Computer Training Corp.
>[e-mail]
>==================
I understand what you are saying here :
>This really can't be done. You can create templates for common stuff
>like headers and footers. But the main content of each page is
>typically different and requires different HTML. Otherwise every page
>on the web would look the same.
but why can't you specify content? For the look and layout a dynamic
web template could be used and for page content the flat file could
have something like :
---------------
web page 1
<content>
input box + properties eg page- Hide quoted text -
- Show quoted text -...
read more »

What about you just create a php page (basically html page) like this:
testPage.php
<?php
ob_start();
// Now read the data from whereever you like
$name = '';
$age = '';

?>
<html>
<head.... </head>
<body>

...
<table><tr<td>

Name: <?php echo $name ?>
</td>
...
</table>

<!--and now take the html output : -->
<?php
$content = ob_get_contents();
ob_end_clean();
//echo $content; // save this content to any new file with html name
(as you wanted) in the web directory.
// and your html is ready and this template is preserved depending on
the data from other file or database comes.

?>
========

I think you are looking for content/data caching solution also. I do
not like smarty template. PHP itself is template lang.
Just i like their content caching functionality. I thing you can
search for something like that. or check smarty allow using caching
tech. without using their template lang. you can allow the php script
in template anyway.

This is more like it Jerry thank you. I've not used php much and not
seen ob_start before - buffering looks very interesting. And I hadn't
thought of each web page populating itself.

I've had a rethink. What I am after is flexibility along the lines :
do you require a new control/field? then just add it to the flat file,
and regenerate the web page. However the more I look the more I think
I'm expecting too much.

Maybe this flexibility can be had but only so long as we are adding to
already existing control/fields ie that are inside a block where the
layout is already established. In the web page there could be a marker
tag for the start of where the control/fields are to (in your example
replace name and age with eg <mtagperson>. And the control/field
information is held in the flat file.

In this scenario the marker tag in the web page is replaced with the
control(s)/field(s) found in the flat file. This mechanism allows us
to add a new control/field to the end of a column or row. And of
course the flat file could be used to modify/delete an existing
control/field.

Two key problems are :
1. how the control/field information is held in the flat file.
2. how to do replace the marker tags in the html field with the flat
file's controls/fields.

Maybe the controls/fields can be straight html. Maybe the whole block
can be read in as per your example ie at the top, instead of retrieve
data the flat file is read.

(The data values would come from a user action. Prior to this the
fields need to be validated against a DB.)

As I've said several times - you're asking for a templating system.

Sure, you can tell them to add a control to the flat file. Then you can
parse the flat file and insert the control(s) as necessary.

But if you code in straight HTML, you have to add the control. The
difference is you have all of the HTML attributes available to you. If
you do that in the templating system, you've just redefined HTML - in a
non-standard way. So your users will have to learn your non-standard
way of doing things.

Either that, or you lose functionality - and you'll constantly have
people wanting you to add such-and-such an attribute/whatever.

HTML is NOT all that hard to do!

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[lxy one]

On 9 Jun, 22:25, Jerry Stuckle <[e-mail]:

lxy one wrote:

On 9 Jun, 05:24, Satya <[e-mail]:

On Jun 8, 3:59 pm, lxy one <[e-mail]:

>On 7 Jun, 11:27, Jerry Stuckle <[e-mail]:
lxy one wrote:
On 6 Jun, 22:30, Jerry Stuckle <[e-mail]:
lxy one wrote:
>On 6 Jun, 18:06, Jerry Stuckle <[e-mail]:
>>lxy one wrote:
>>>On 6 Jun, 11:39, Jerry Stuckle <[e-mail]:
>>>>lxy one wrote:
>>>>>On 6 Jun, 03:30, Jerry Stuckle <[e-mail]:
>>>>>>[e-mail] wrote:
>>>>>>>Using a flat file containing table names, fields, values whats the
>>>>>>>best way of creating html pages?
>>>>>>>I want control over the html pages ie
>>>>>>>1. layout
>>>>>>>2. what data to show
>>>>>>>3. what controls to show - text boxes, input boxes, buttons,
>>>>>>>hyperlinks ie the usual.
>>>>>>>The data is not obtained directly from a database.
>>>>>>>I was thinking maybe the flat file could use xml. And maybe this flat
>>>>>>>file could be generated using :
>>>>>>>1. the database data and
>>>>>>>2. a template file to indicate the controls that should appear on each
>>>>>>>html page.
>>>>>>>Maybe there could be existing html pages that could be used in the
>>>>>>>generation of the required final html pages ie maybe they could
>>>>>>>contain static data - such as layout, headings and tags as to where
>>>>>>>fields, controls need to be placed.
>>>>>>>Searching on this is difficult as the key words are too common :
>>>>>>>create, html, xml, dynamic, template etc results in million+hits.
>>>>>>If you're going to go to all that trouble, why not just create the html
>>>>>>page from the flat file and store it as a static page? Then when the
>>>>>>flat file changes, regenerate the html.
>>>>>>Much simpler (and server-friendly) than recreating the same page on
>>>>>>every request.
>>>>>>--
>>>>>>==================
>>>>>>Remove the "x" from my email address
>>>>>>Jerry Stuckle
>>>>>>JDS Computer Training Corp.
>>>>>>[e-mail]
>>>>>>==================
>>>>>Hi Jerry,
>>>>>But thats exactly what I want to do.
>>>>>1. Create a flat file that will contain
>>>>>-a) tables/fields+data values
>>>>>-b) web page(form) details ie the fields/controls to appear oneach
>>>>>web page.
>>>>>2. Generate the (static) web pages from the flat file.
>>>>>3. If flat file is updated then update web pages.
>>>>OK, I understand better now.
>>>>>So the issues are :
>>>>>1. flat file - what format should this be in - xml ?
>>>>The simple answer is - whatever form suits you best. I've seenxml
>>>>files, csv files, php code and even just plain text. It all depends on
>>>>the data and what's easiest for you.
>>>>I would think that since your file needs to contain tables/fields and
>>>>data, xml might be easiest to parse and maintain. But that's probably
>>>>because I've worked with xml a fair amount. But if you haven't, another
>>>>form (such as csv) might be easier.
>>>>>2. How to generate the (static) web pages (forms) from the flat file
>>>>>bearing in mind that I would like to control over what web pages +
>>>>>tables/fields/data + controls are created.
>>>>Well, you'll have to read the file then display all of the information
>>>>on a web page. Then select the information you wish to display..
>>>>Finally, generate the page.
>>>>>But maybe this is to difficult. Maybe it would be easier to have the
>>>>>static web pages I want already created. The pages could have tags to
>>>>>indicate where fields + controls (if available in the flat file)
>>>>>should go.
>>>>You're now talking about a templating system, which is very popular.
>>>>The nice thing about it is it takes a lot of the "grunt work" out of the
>>>>code required to generate the page. It also separates the restof the
>>>>page from the actual data being displayed, making it easier to maintain.
>>>>>I would have thought something flexible like this : generatingstatic
>>>>>web pages using data/controls from a flat file : had already been done
>>>>>but I've not found anything yet.
>>>>I've used it before, when the data doesn't change very often. It can be
>>>>very effective on high usage sites. For lower usage sites and data
>>>>which changes fairly regularly, I just generate the pages dynamically on
>>>>request.
>>>>And I think you'll find most of the systems use a database instead of a
>>>>flat file. It makes things a lot easier - the database managesthe data
>>>>for you, so you don't have to do as much in your code. Simple SQL
>>>>requests are not that hard to learn, and if you're going to be serious
>>>>about web development, they're pretty much a requirement nowadays. SQL
>>>>is just too powerful to ignore.
>>>>--
>>>>==================
>>>>Remove the "x" from my email address
>>>>Jerry Stuckle
>>>>JDS Computer Training Corp.
>>>>[e-mail]
>>>>==================
>>>Hi Jerry,
>>>Can you point me code examples please as I'm new to this.
>>>As to why a flat file instead of a DB - the idea for the flat file was
>>>that it would combine both table data and form data to allow the
>>>generation of each web page.
>>Unfortunately, that's very difficult. Every system I've done like this
>>has been a custom system - with widely varying differences in amount of
>>code and difficulty. Every database has been different, also.
>>My suggestion would be to use google to find some simple templating
>>systems and see how they do it. There are a bunch out there.
>>--
>>==================
>>Remove the "x" from my email address
>>Jerry Stuckle
>>JDS Computer Training Corp.
>>[e-mail]
>>==================
>Jerry, David,
>I think I've not been clear on what I'm after and I guess that's
>because I'm still pondering the problem.
>1. Although tables/fields may vary, the creation of the static web
>pages would be a one off ie once up and running no changes would be
>expected. The reason for working this way, generating web pages, is to
>cater for having different tables/fields and web page specifications.
>So instead of having sets of static web pages to create/maintain you
>can just create a new set by modifying a flat file. I cannot help
>thinking that this must have been done.
This really can't be done. You can create templates for common stuff
like headers and footers. But the main content of each page is
typically different and requires different HTML. Otherwise every page
on the web would look the same.
As I said before - there are a bunch of templating systems out there -
but even with the best, you still need to create the content for each page.
For instance - your home page should describe your company/organization,
what you do, etc. It probably won't have any tables in it. But a page
from your catalog will have to list one or more products and will look
different. And a page comparing similar products will look different yet.
>2. Also misleadingly in a subsequently post I made a boo-boo in
>indicating data values would be included in the flat file - not true,
>the form would request this.
OK, so you're talking about a template based on text files. But the
same rules above apply.
>3. I thought the tricky bit would be creating the flat file ie
>retrieving DB tables/fields and combining these with web page
>specifications (optional/mandatory fields, controls, images etc). This
>really is the crux. You would have to know what tables/fields to
>expect. If a web page has a mandatory field specified and the field is
>not one of those retrieved from the DB then maybe that's an abort.
>Whereas if it's optional then we can go ahead and create the flat
>file.
Yes, and that will be different for each page. Additionally, how you
display that data will often be different for each page, as noted above.
>As for 1. above I will search on : simple templating systems. Thanks.
There are ways to make things easier. But there is no way to make
everything the same, unless all of the pages look the same.
You could create a templating system where you have an admin page and
fill in the blanks with the database information. But it still really
restricts you on how that data is going to be displayed. The other
option would be to store the HTML in the database also - but that means
your data is only good for the website itself. If later you wantedto
do something like create an RSS feed of your catalog, the data in the
database would be virtually worthless unless you did some really
complicated cleaning of it.
I'm not saying it's not a good idea. But not all good ideas can be
translated into workable ones.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================
I understand what you are saying here :
This really can't be done. You can create templates for common stuff
like headers and footers. But the main content of each page is
typically different and requires different HTML. Otherwise every page
on the web would look the same.
but why can't you specify content? For the look and layout a dynamic
web template could be used and for page content the flat file could
have something like :
---------------
web page 1
<content>
input box + properties eg page- Hide quoted text -
- Show quoted text -...
read more »
What about you just create a php page (basically html page) like this:
testPage.php
<?php
ob_start();
// Now read the data from whereever you like
$name = '';
$age = '';

?>
<html>
<head.... </head>
<body>

...
<table><tr<td>

Name: <?php echo $name ?>
</td>
...
</table>

<!--and now take the html output : -->
<?php
$content = ob_get_contents();
ob_end_clean();
//echo $content; // save this content to any new file with html name
(as you wanted) in the web directory.
// and your html is ready and this template is preserved depending on
the data from other file or database comes.

?>
========

I think you are looking for content/data caching solution also. I do
not like smarty template. PHP itself is template lang.
Just i like their content caching functionality. I thing you can
search for something like that. or check smarty allow using caching
tech. without using their template lang. you can allow the php script
in template anyway.

This is more like it Jerry thank you. I've not used php much and not
seen ob_start before - buffering looks very interesting. And I hadn't
thought of each web page populating itself.

I've had a rethink. What I am after is flexibility along the lines :
do you require a new control/field? then just add it to the flat file,
and regenerate the web page. However the more I look the more I think
I'm expecting too much.

Maybe this flexibility can be had but only so long as we are adding to
already existing control/fields ie that are inside a block where the
layout is already established. In the web page there could be a marker
tag for the start of where the control/fields are to (in your example
replace name and age with eg <mtagperson>. And the control/field
information is held in the flat file.

In this scenario the marker tag in the web page is replaced with the
control(s)/field(s) found in the flat file. This mechanism allows us
to add a new control/field to the end of a column or row. And of
course the flat file could be used to modify/delete an existing
control/field.

Two key problems are :
1. how the control/field information is held in the flat file.
2. how to do replace the marker tags in the html field with the flat
file's controls/fields.

Maybe the controls/fields can be straight html. Maybe the whole block
can be read in as per your example ie at the top, instead of retrieve
data the flat file is read.

(The data values would come from a user action. Prior to this the
fields need to be validated against a DB.)

As I've said several times - you're asking for a templating system.

Sure, you can tell them to add a control to the flat file. Then you can
parse the flat file and insert the control(s) as necessary.

But if you code in straight HTML, you have to add the control. The
difference is you have all of the HTML attributes available to you. If
you do that in the templating system, you've just redefined HTML - in a
non-standard way. So your users will have to learn your non-standard
way of doing things.

Either that, or you lose functionality - and you'll constantly have
people wanting you to add such-and-such an attribute/whatever.

HTML is NOT all that hard to do!

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
[e-mail]
==================

Again thanks for the info : I've now played with smarty and
html_quickform. I'm impressed but it seems overkill for what I want.
I'd prefer to use an IDE to design the web pages to take care of
layout and styling and then just have some code parse the resultant
html files and replace designated control/button (could be given a
specific name in the IDE) with control(s)/field(s) from the flat file.
I'm still looking for code for this.
So more of a surgical incision than a whole body thing. Having said
that I suppose I could take the IDE web pages and turn them into
templates but that doesn't feel right.

BTW I read good comments about smarty and html_quickform but then also
read the reverse : I came across an advocate who now repents and says
they should never be used together (too complicated) and agrees with
you that PHP itself is just fine for templating; that MVC and serious
frameworks like Zend should be used instead.