Hello,
I have a php include command in my website and the script shows up.
However, I need for the script to show up on the right side of page
(there is enough room there)... but for some reason it shows up at the
bottom. I placed the include command in the correct part of my html
file. Is there any way to give some sort of command on where you want
it to show up on the webpage?
22  1831 
..oO(John)
>I have a php include command in my website and the script shows up.
However, I need for the script to show up on the right side of page
(there is enough room there)... but for some reason it shows up at the
bottom. I placed the include command in the correct part of my html
file. Is there any way to give some sort of command on where you want
it to show up on the webpage?
Sure, but that's a HTML/CSS issue and has nothing to do with PHP itself.
Micha
John;83532 Wrote:
Hello,
I have a php include command in my website and the script shows up.
However, I need for the script to show up on the right side of page
(there is enough room there)... but for some reason it shows up at the
bottom. I placed the include command in the correct part of my html
file. Is there any way to give some sort of command on where you want
it to show up on the webpage?
I don't think it has anything to do with PHP really.
It probably has more to do with the HTML/CSS code.
But without seeing any code it is impossible to even guess what the
problem could be.
You will need to post the code, (HTML not the PHP), so we can tell as
to why the display is the way it is.
FFMG
--
'webmaster forum' ( http://www.httppoint.com) | 'webmaster Directory'
( http://www.webhostshunter.com/) | 'Recreation Vehicle insurance'
( http://www.insurance-owl.com/other/car_rec.php)
'Free URL redirection service' ( http://urlkick.com/)
------------------------------------------------------------------------
FFMG's Profile: http://www.httppoint.com/member.php?userid=580
View this thread: http://www.httppoint.com/showthread.php?t=18816
Message Posted via the webmaster forum http://www.httppoint.com, (Ad revenue sharing).
On 27 Jul, 06:10, John <John_nos...@nnnnnnnnn.nowherewrote:
Hello,
I have a php include command in my website and the script shows up.
However, I need for the script to show up on the right side of page
(there is enough room there)... but for some reason it shows up at the
bottom. I placed the include command in the correct part of my html
file. Is there any way to give some sort of command on where you want
it to show up on the webpage?
A php include has to go in a php file.
HTML includes are normally done using SSI.
If you are using HTL includes then you are asking in totally the wrong
place.
On Fri, 27 Jul 2007 02:02:52 -0700, Captain Paralytic
<pa**********@yahoo.comwrote:
>
A php include has to go in a php file.
HTML includes are normally done using SSI.
If you are using HTL includes then you are asking in totally the wrong
place.
That is incorrect.
You can have php includes in a html file.
On 27 Jul, 15:58, John <John_nos...@nnnnnnnnn.nowherewrote:
On Fri, 27 Jul 2007 02:02:52 -0700, Captain Paralytic
<paul_laut...@yahoo.comwrote:
A php include has to go in a php file.
HTML includes are normally done using SSI.
If you are using HTL includes then you are asking in totally the wrong
place.
That is incorrect.
You can have php includes in a html file.
How does that work?
a php include must be in a file that will be interpreted by the php
interpreter. The file extension may be .HTML, but the file will be a
php file by virtue of having the include() within php tags and the web
server will have been told that this type of file is a php file.
A php include() within a file that contains pure html and no php tags
will AFAIAA not do anything.
John wrote:
A php include has to go in a php file.
HTML includes are normally done using SSI.
If you are using HTL includes then you are asking in totally the wrong
place.
That is incorrect.
You can have php includes in a html file.
In theory, yes. In practice, no. Because most webservers are not
configured to parse a .html file through PHP.
If the filename does not end in .php (.php5 or other widely accepted
extension which denotes a PHP file) it won't be parsed and the PHP
include won't get executed.
Sure, if you have total control of the webserver you can tell it to
parse every file through PHP but this is considered bad practice as it
will slow down the server.
Bye!
Captain Paralytic wrote:
On 27 Jul, 15:58, John <John_nos...@nnnnnnnnn.nowherewrote:
>On Fri, 27 Jul 2007 02:02:52 -0700, Captain Paralytic
<paul_laut...@yahoo.comwrote:
>A php include has to go in a php file.
>HTML includes are normally done using SSI.
>If you are using HTL includes then you are asking in totally the wrong
place.
That is incorrect.
You can have php includes in a html file.
How does that work?
AddType application/x-httpd-php .html
For Apache of course. You just force the MIME type of .html files to be PHP
files. If you're using an executable directory so to say (+ExecCGI), you
could just put #!/usr/bin/env php at the top and it would be treated as a
PHP file regardless of file extension.
--
'Yes, firefox is indeed greater than women. Can women block pops up for you?
No. Can Firefox show you naked women? Yes.'
Matt S wrote:
Captain Paralytic wrote:
>On 27 Jul, 15:58, John <John_nos...@nnnnnnnnn.nowherewrote:
>>On Fri, 27 Jul 2007 02:02:52 -0700, Captain Paralytic
<paul_laut...@yahoo.comwrote:
A php include has to go in a php file.
HTML includes are normally done using SSI.
If you are using HTL includes then you are asking in totally the wrong
place.
That is incorrect.
You can have php includes in a html file.
How does that work?
AddType application/x-httpd-php .html
For Apache of course. You just force the MIME type of .html files to be PHP
files. If you're using an executable directory so to say (+ExecCGI), you
could just put #!/usr/bin/env php at the top and it would be treated as a
PHP file regardless of file extension.
And waste a hell of a lot of server resources parsing your static HTML
files for PHP.
Thank &Diety most shared hosting environments don't allow this. What a
bunch of crappola.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
..oO(Jerry Stuckle)
>Matt S wrote:
>For Apache of course. You just force the MIME type of .html files to be PHP
files. If you're using an executable directory so to say (+ExecCGI), you
could just put #!/usr/bin/env php at the top and it would be treated as a
PHP file regardless of file extension.
And waste a hell of a lot of server resources parsing your static HTML
files for PHP.
* using .htaccess you can enable that on a per-directory basis
* if you're using PHP for more than just a form on a single page, then
it doesn't matter, because all pages have to be parsed anyway
* the file extension .html (or no extension at all) is preferred for
stable URIs
>Thank &Diety most shared hosting environments don't allow this. What a
bunch of crappola.
Not if done properly.
Micha
Michael Fesser wrote:
.oO(Jerry Stuckle)
>Matt S wrote:
>>For Apache of course. You just force the MIME type of .html files to be PHP
files. If you're using an executable directory so to say (+ExecCGI), you
could just put #!/usr/bin/env php at the top and it would be treated as a
PHP file regardless of file extension.
And waste a hell of a lot of server resources parsing your static HTML
files for PHP.
* using .htaccess you can enable that on a per-directory basis
So? It's still a waste of resources.
* if you're using PHP for more than just a form on a single page, then
it doesn't matter, because all pages have to be parsed anyway
Only if they contain php code.
* the file extension .html (or no extension at all) is preferred for
stable URIs
That's your opinion, anyway.
>Thank &Diety most shared hosting environments don't allow this. What a
bunch of crappola.
Not if done properly.
Micha
If you have any static html pages on your site, you are wasting resources.
It's exactly WHY Apache doesn't by default parse everything with PHP,
PERL, and everything else on the market.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
..oO(Jerry Stuckle)
>Michael Fesser wrote:
>>
* using .htaccess you can enable that on a per-directory basis
So? It's still a waste of resources.
Like storing images in a database for example. Who's wasting resources
then?
>* if you're using PHP for more than just a form on a single page, then
it doesn't matter, because all pages have to be parsed anyway
Only if they contain php code.
As said, "if you're using PHP for more than just a form on a single
page", then it's very likely that all pages contain PHP code, even if
it's just an include of a menu bar script.
>* the file extension .html (or no extension at all) is preferred for
stable URIs
That's your opinion, anyway.
Not only mine. It's also the W3C's opinion.
Micha
Michael Fesser wrote:
.oO(Jerry Stuckle)
>Michael Fesser wrote:
>>* using .htaccess you can enable that on a per-directory basis
So? It's still a waste of resources.
Like storing images in a database for example. Who's wasting resources
then?
Not at all. Databases are quite efficient at retrieving data -
including images.
>>* if you're using PHP for more than just a form on a single page, then
it doesn't matter, because all pages have to be parsed anyway
Only if they contain php code.
As said, "if you're using PHP for more than just a form on a single
page", then it's very likely that all pages contain PHP code, even if
it's just an include of a menu bar script.
Nope. Not at all. I have several sites with some pages which have no
PHP in them at all. And if they have a menu bar script, they're
included with SSI.
>>* the file extension .html (or no extension at all) is preferred for
stable URIs
That's your opinion, anyway.
Not only mine. It's also the W3C's opinion.
Micha
Exactly where do they say that? And where do they say they've taken
over programming and support for Apache, IIS, and other web servers?
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
..oO(Jerry Stuckle)
>Of course, you conveniently ignore the fact those 20 images require 20
additional calls to the server, anyway.
Doesn't matter here. 20 requests are 20 requests, but it makes a big
difference if the server can deliver them statically as-is or if it has
to invoke a script handler for every single image.
>The script will already be in
memory (if nothing else, the OS cache will have it),
Page-generating scripts can be cached as well, dependent on the
configuration of the webserver and the PHP interpreter.
>and the overhead of
interpreting it isn't very bad at all.
So you want to tell me that a simple page-generating script wastes more
resources then a script that has to
* open a connection to a database
* query the DB (requires to analyze and optimize the query)
* transfer binary data from the DB into the script
* close the connection
* transfer the data to the webserver
?
And it beats trying to keep
track of thousands (or tens of thousands) of files on the disk.
Doesn't matter here. We were talking about performance and "wasting a
hell of a lot" resources. If you think interpreting all pages as PHP
wastes that many resources, but fetching images from the DB does not,
then there must be something really wrong ...
>Not nearly as much as PHP.
Depends on the server configuration I would say. SSI requires a parser/
interpreter as well. And PHP running as a server module is quite fast.
The work that has to be done by the parsers is quite the same - they
just look for special directives in the HTML code.
>But I didn't say I used SSI on all pages,
either, did I?
Well, using SSI for a menu indicates that.
>They say URI's don't change. They don't say to interpret every page as PHP.
Again: This wasn't the point here. We were talking about leaving out
file extensions from a URL.
Micha
Michael Fesser wrote:
.oO(Jerry Stuckle)
>Of course, you conveniently ignore the fact those 20 images require 20
additional calls to the server, anyway.
Doesn't matter here. 20 requests are 20 requests, but it makes a big
difference if the server can deliver them statically as-is or if it has
to invoke a script handler for every single image.
Not nearly as much as you claim.
>The script will already be in
memory (if nothing else, the OS cache will have it),
Page-generating scripts can be cached as well, dependent on the
configuration of the webserver and the PHP interpreter.
Sure they can. But they still have to be interpreted unnecessarily.
>and the overhead of
interpreting it isn't very bad at all.
So you want to tell me that a simple page-generating script wastes more
resources then a script that has to
* open a connection to a database
* query the DB (requires to analyze and optimize the query)
* transfer binary data from the DB into the script
* close the connection
* transfer the data to the webserver
?
This isn't part of the discussion. There are other reasons for
delivering images from the database.
> And it beats trying to keep
track of thousands (or tens of thousands) of files on the disk.
Doesn't matter here. We were talking about performance and "wasting a
hell of a lot" resources. If you think interpreting all pages as PHP
wastes that many resources, but fetching images from the DB does not,
then there must be something really wrong ...
If it doesn't matter, then why did you bring it up?
>Not nearly as much as PHP.
Depends on the server configuration I would say. SSI requires a parser/
interpreter as well. And PHP running as a server module is quite fast.
The work that has to be done by the parsers is quite the same - they
just look for special directives in the HTML code.
You obviously don't understand how it works. The SSI parser is much
smaller and much faster than the PHP parser.
>But I didn't say I used SSI on all pages,
either, did I?
Well, using SSI for a menu indicates that.
Sure, but I didn't say it was on every page, either.
>They say URI's don't change. They don't say to interpret every page as PHP.
Again: This wasn't the point here. We were talking about leaving out
file extensions from a URL.
Micha
Exactly. They say don't change the URL. They don't say interpret every
page as PHP. There are other ways to do it.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
..oO(Jerry Stuckle)
>Michael Fesser wrote:
>Doesn't matter here. 20 requests are 20 requests, but it makes a big
difference if the server can deliver them statically as-is or if it has
to invoke a script handler for every single image.
Not nearly as much as you claim.
Why are you then claiming that calling a script for every page wastes "a
hell of a lot" resources if it doesn't make much of a difference?
>>The script will already be in
memory (if nothing else, the OS cache will have it),
Page-generating scripts can be cached as well, dependent on the
configuration of the webserver and the PHP interpreter.
Sure they can. But they still have to be interpreted unnecessarily.
Like an image-from-db script. If it can be done with static files as
well, then calling the image script is unnecessary. Same thing.
>This isn't part of the discussion.
Of course it is. You were the one complaining about wasting resources
when parsing HTML for PHP, but you don't see (or actually don't want to
see) the wasted resources when delivering images from a DB.
>There are other reasons for
delivering images from the database.
This isn't part of the discussion.
>Depends on the server configuration I would say. SSI requires a parser/
interpreter as well. And PHP running as a server module is quite fast.
The work that has to be done by the parsers is quite the same - they
just look for special directives in the HTML code.
You obviously don't understand how it works. The SSI parser is much
smaller and much faster than the PHP parser.
Looking for <?php or <!--#foo in a string is pretty easy. Even the PHP
parser doesn't have much to do in plain HTML.
Micha
Michael Fesser wrote:
.oO(Jerry Stuckle)
>Michael Fesser wrote:
>>Doesn't matter here. 20 requests are 20 requests, but it makes a big
difference if the server can deliver them statically as-is or if it has
to invoke a script handler for every single image.
Not nearly as much as you claim.
Why are you then claiming that calling a script for every page wastes "a
hell of a lot" resources if it doesn't make much of a difference?
Because it's completely unnecessary. But you don't seem to understand
that part.
>>>The script will already be in
memory (if nothing else, the OS cache will have it),
Page-generating scripts can be cached as well, dependent on the
configuration of the webserver and the PHP interpreter.
Sure they can. But they still have to be interpreted unnecessarily.
Like an image-from-db script. If it can be done with static files as
well, then calling the image script is unnecessary. Same thing.
But there are other reasons for delivering images from databases. There
are no good reasons for parsing every file as PHP.
>This isn't part of the discussion.
Of course it is. You were the one complaining about wasting resources
when parsing HTML for PHP, but you don't see (or actually don't want to
see) the wasted resources when delivering images from a DB.
No, you're just trying to change the topic. Your current argument isn't
succeeding, so you're desperately trying to find an argument you can
score points on. It's not going to work.
>There are other reasons for
delivering images from the database.
This isn't part of the discussion.
Oh, so now it's not part of the discussion? Make up your mind. Or is
it part of the discussion when you want to bring up a point, but not
when I do?
It's not part of the discussion - so forget about bringing it up.
>>Depends on the server configuration I would say. SSI requires a parser/
interpreter as well. And PHP running as a server module is quite fast.
The work that has to be done by the parsers is quite the same - they
just look for special directives in the HTML code.
You obviously don't understand how it works. The SSI parser is much
smaller and much faster than the PHP parser.
Looking for <?php or <!--#foo in a string is pretty easy. Even the PHP
parser doesn't have much to do in plain HTML.
Micha
You really need to understand parsers more before you make such claims.
Searching for <?php or <!--$foo are not the only things parsers must do.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
..oO(Jerry Stuckle)
>Michael Fesser wrote:
>Why are you then claiming that calling a script for every page wastes "a
hell of a lot" resources if it doesn't make much of a difference?
Because it's completely unnecessary. But you don't seem to understand
that part.
I _do_ understand that, I just don't agree that it wastes as much
resources as you claim.
Additionally I don't care that much at all about some more or less CPU
cycles (you won't even notice a difference on a properly configured
machine) because there's a whole bunch of other things that can (and do)
waste a lot more.
>Like an image-from-db script. If it can be done with static files as
well, then calling the image script is unnecessary. Same thing.
But there are other reasons for delivering images from databases.
There are also reasons for not doing that.
>There
are no good reasons for parsing every file as PHP.
There are, I already gave some. One reason was to have proper URLs
without a .php suffix. Of course there are other ways to do that, but
passing all pages through PHP is one way to achieve that goal and is
quite easy to setup. This _is_ a reason.
>>There are other reasons for
delivering images from the database.
This isn't part of the discussion.
Oh, so now it's not part of the discussion?
No. The reasons why or why not delivering images from a DB is not part
of this discussion, and actually I don't really want to discuss that.
But the fact that it wastes resources _is_ part of the discussion.
>Looking for <?php or <!--#foo in a string is pretty easy. Even the PHP
parser doesn't have much to do in plain HTML.
You really need to understand parsers more before you make such claims.
I do.
Searching for <?php or <!--$foo are not the only things parsers must do.
Sure, but that's where it all begins. No processing instruction, no
further parsing. Just pass-through.
Micha
Michael Fesser wrote:
.oO(Jerry Stuckle)
>Michael Fesser wrote:
>>Why are you then claiming that calling a script for every page wastes "a
hell of a lot" resources if it doesn't make much of a difference?
Because it's completely unnecessary. But you don't seem to understand
that part.
I _do_ understand that, I just don't agree that it wastes as much
resources as you claim.
Additionally I don't care that much at all about some more or less CPU
cycles (you won't even notice a difference on a properly configured
machine) because there's a whole bunch of other things that can (and do)
waste a lot more.
That's your opinion. But there are other, more efficient ways to do it.
And if what you say is true, why don't Apache and PHP recommend it?
They don't, though. And they know best.
>>Like an image-from-db script. If it can be done with static files as
well, then calling the image script is unnecessary. Same thing.
But there are other reasons for delivering images from databases.
There are also reasons for not doing that.
>There
are no good reasons for parsing every file as PHP.
There are, I already gave some. One reason was to have proper URLs
without a .php suffix. Of course there are other ways to do that, but
passing all pages through PHP is one way to achieve that goal and is
quite easy to setup. This _is_ a reason.
No, you haven't given any good reasons for parsing all files as PHP.
What you have done is given the most inefficient way possible to achieve
that goal.
>>>There are other reasons for
delivering images from the database.
This isn't part of the discussion.
Oh, so now it's not part of the discussion?
No. The reasons why or why not delivering images from a DB is not part
of this discussion, and actually I don't really want to discuss that.
But the fact that it wastes resources _is_ part of the discussion.
Not at all.
>>Looking for <?php or <!--#foo in a string is pretty easy. Even the PHP
parser doesn't have much to do in plain HTML.
You really need to understand parsers more before you make such claims.
I do.
> Searching for <?php or <!--$foo are not the only things parsers must do.
Sure, but that's where it all begins. No processing instruction, no
further parsing. Just pass-through.
Micha
Oh, but there are - a huge number of other things going on even before
the parser gets involved - like loading the parser in that process or
thread, setting up the PHP environment, parsing the URL, and so on.
With SSI there is no environment to set up, no URL parsing or a lot of
other things PHP does even before it gets to the point of scanning your
file.
Parsing files for PHP unnecessarily is a waste of a lot of resources.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
..oO(Jerry Stuckle)
>That's your opinion. But there are other, more efficient ways to do it.
And if what you say is true, why don't Apache and PHP recommend it?
They don't, though.
They don't say "don't do that" either.
>And they know best.
Not always. There are also some default options in the Apache config,
which are at least questionable. But that's another story.
>There are, I already gave some. One reason was to have proper URLs
without a .php suffix. Of course there are other ways to do that, but
passing all pages through PHP is one way to achieve that goal and is
quite easy to setup. This _is_ a reason.
No, you haven't given any good reasons for parsing all files as PHP.
What you have done is given the most inefficient way possible to achieve
that goal.
That's your opinion.
>Oh, but there are - a huge number of other things going on even before
the parser gets involved - like loading the parser in that process or
thread, setting up the PHP environment, parsing the URL, and so on.
Some of them can be avoided if PHP is installed as a module, some other
work is required for SSI as well.
>Parsing files for PHP unnecessarily is a waste of a lot of resources.
So are images in a DB, but we're moving in circles. I don't want to
waste any more of my own resources with that. You have your opinion,
I have mine. As usual.
EOD for me
Micha
Michael Fesser wrote:
.oO(Jerry Stuckle)
>That's your opinion. But there are other, more efficient ways to do it.
And if what you say is true, why don't Apache and PHP recommend it?
They don't, though.
They don't say "don't do that" either.
No, they tell you WHAT TO DO - not WHAT NOT TO DO.
>And they know best.
Not always. There are also some default options in the Apache config,
which are at least questionable. But that's another story.
In your opinion.
>>There are, I already gave some. One reason was to have proper URLs
without a .php suffix. Of course there are other ways to do that, but
passing all pages through PHP is one way to achieve that goal and is
quite easy to setup. This _is_ a reason.
No, you haven't given any good reasons for parsing all files as PHP.
What you have done is given the most inefficient way possible to achieve
that goal.
That's your opinion.
No, it's a fact.
>Oh, but there are - a huge number of other things going on even before
the parser gets involved - like loading the parser in that process or
thread, setting up the PHP environment, parsing the URL, and so on.
Some of them can be avoided if PHP is installed as a module, some other
work is required for SSI as well.
No, even set up as a module all of the above has to be done. And the
only thing done with SSI is to load the module. It doesn't set up a
special environment, parse a url, or any of the rest of that.
>Parsing files for PHP unnecessarily is a waste of a lot of resources.
So are images in a DB, but we're moving in circles. I don't want to
waste any more of my own resources with that. You have your opinion,
I have mine. As usual.
Completely off-topic and unrelated to this discussion.
As I said - there are much more efficient ways to get the same result.
But you ignore that.
EOD for me
Micha
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
On Jul 31, 12:23 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
Michael Fesser wrote:
.oO(Jerry Stuckle)
That's your opinion. But there are other, more efficient ways to do it.
And if what you say is true, why don't Apache and PHP recommend it?
They don't, though.
They don't say "don't do that" either.
No, they tell you WHAT TO DO - not WHAT NOT TO DO.
And they know best.
Not always. There are also some default options in the Apache config,
which are at least questionable. But that's another story.
In your opinion.
I would say Apache and PHP have been around long enough to know what
is efficient and what is inefficient. They don't tell you "don't do
that" because they could care less how inefficiently you wish to run
your server. They could probably come up with thousands of things
"not to do", but why would they "waste their resources" with that?
Instead, they tell you the most efficient way, "what to do".
>
>There are, I already gave some. One reason was to have proper URLs
without a .php suffix. Of course there are other ways to do that, but
passing all pages through PHP is one way to achieve that goal and is
quite easy to setup. This _is_ a reason.
No, you haven't given any good reasons for parsing all files as PHP.
What you have done is given the most inefficient way possible to achieve
that goal.
That's your opinion.
No, it's a fact.
A sacrifice of ease over efficiency is perfectly acceptable on a test
machine, that way when you push it to production, you know how slowly
it "won't" run. So yea, I guess that _is_ a reason...not valid.
>
Oh, but there are - a huge number of other things going on even before
the parser gets involved - like loading the parser in that process or
thread, setting up the PHP environment, parsing the URL, and so on.
Some of them can be avoided if PHP is installed as a module, some other
work is required for SSI as well.
No, even set up as a module all of the above has to be done. And the
only thing done with SSI is to load the module. It doesn't set up a
special environment, parse a url, or any of the rest of that.
Parsing files for PHP unnecessarily is a waste of a lot of resources.
So are images in a DB, but we're moving in circles. I don't want to
waste any more of my own resources with that. You have your opinion,
I have mine. As usual.
Completely off-topic and unrelated to this discussion.
You got it, Jerry. Though I know little about the PHP interpreter, I
know completely that passing every page through the interpreter is
inefficient. How do I know that? It's pretty black and white
really. Have the web server set up to load the SSI module, or, as you
said, have php load up, parse the url, interpret the page and send to
web server...hmm...sounds like a simpler step to me. No brainer.
Images in a database have multiple purposes...not simply retrieval.
To store images in a db for simple retrieval *would* be a waste of
resources. However, since it there can also be a procedure to
manipulate that image, store information along *with* that image, AND
to shrink the SIZE of that image; I'd say it doesn't compare nor
relate to this conversation.
>
As I said - there are much more efficient ways to get the same result.
But you ignore that.
EOD for me
Micha
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================
Just my two cents, here, gentlemen. I just can't stand to see
somebody defend a topic they seem to know very little or nothing
about...just enough to get themselves into a tight situation and then
bail when they fail to "win" the debate. So good job, Jerry, master
of the ring. Let me know when you get into another _heated_
debate...I'd love to spectate! :)
..oO(mac)
>Images in a database have multiple purposes...not simply retrieval.
To store images in a db for simple retrieval *would* be a waste of
resources. However, since it there can also be a procedure to
manipulate that image
In the DB?
>, store information along *with* that image
Can also be done with the image data stored on disk.
>AND
to shrink the SIZE of that image;
Hardly.
>So good job, Jerry, master
of the ring. Let me know when you get into another _heated_
debate...I'd love to spectate! :)
I'm just waiting that he calls me a troll ...
Micha This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: VK |
last post by:
09/30/03 Phil Powell posted his "Radio buttons do not appear checked"
question.
This question led to a long discussion about the naming rules applying to
variables, objects, methods and properties...
|
by: Francois Keyeux |
last post by:
hello everyone:
i have a web site built using vbasic active server scripting running on
iis (it works on either iis 50 and 60, but is designed for iis 50)
i know how to create a plain text...
|
by: cirillo_curiosone |
last post by:
Hi,
i'm new to javascript. I started studing it on the web few weeks ago,
but still haven't been able to solve one big problem: HOT TO PASS VALUES
FROM A SCRIPT VARIABLE TO A CHILD HTML...
|
by: LRW |
last post by:
http://gto.ie-studios.net/index.php
When you view the above site in IE, if the 1st of the three product
images is tall enough to push the cell down a couple of pixels, IE
somehow doesn't show...
|
by: Boris Ammerlaan |
last post by:
This notice is posted about every week. I'll endeavor to use the same
subject line so that those of you who have seen it can kill-file the
subject; additionally, Supersedes: headers are used to...
|
by: Patient Guy |
last post by:
Taking the BODY element as an example, all of its style attributes
('alink', 'vlink', 'background', 'text', etc.) are deprecated in HTML 4.01,
a fact noted in the DOM Level 2 HTML specification.
...
|
by: serge calderara |
last post by:
Dear all,
I am new in asp.net and prepare myself for exam
I still have dificulties to understand the difference between server control
and HTML control.
Okey things whcih are clear are the fact...
|
by: Guy Macon |
last post by:
cwdjrxyz wrote:
HTML 5 has solved the above probem. See the following web page:
HTML 5, one vocabulary, two serializations
http://www.w3.org/QA/2008/01/html5-is-html-and-xml.html
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
| |
