Re: How do we get there from here?

Tom deL wrote:

I'll snip everything I agree with or that we have covered sufficiently.
If you want to skim -- check the summary points at the ==>

> > I know that is the LAMP approach and I understand it. It makes for a
>
> If I may again complain about semantics: Assigning everything to an
> acronym does a disservice to our language (see Newspeak) as well as to
> the discussion of technical methods.
>
> LAMP (like AJAX, etc., etc.) is someone's buzz word for a combination
> of tools.

My distinction here is that with a "typical" LAMP approach, no matter
whether you are writing OO or procedural code, you are pre-processing
server-side-scripted html. Alternately, you can keep the scripting in
your html documents to client-side scripting (or links to such) and use
the server side languages in response to actions from the client (using
XMLHttpRequest from JavaScript, for example).

>
> A very important distinction: Using a PHP script to send HTML
> (including js) code to a browser in no way taints that code.

In no way? See example that you wrote below.

> You seem
> to have the sense that the source of the data somehow changes the
> nature of that data. It doesn't (in this case at least). Consider:
>
> something.html
> <HTML>
> <HEAD><TITLE>Howdy</TITLE></HEAD>
> <BODY>
> Hello World!
> </BODY>
> </HTML>
>
> something.php
> <?
> echo "
> <HTML>
> <HEAD><TITLE>Howdy</TITLE></HEAD>
> <BODY>
> Hello World!
> </BODY>
> </HTML>\n";
> ?>

This is a simple example with very little php scripting. In spite of
that, I can still say that I would prefer to maintain something.html
instead of something.php.

==>1. To maintain the first, I need to learn html. To maintain the
second, I need to learn html and php.

> somethingelse.php
> <?
> require "something.html";
> ?>
>
> There is NO difference in the three examples above as far as the
> browser is concerned. None.

I'm with you on that.

> I don't think (js experts, if I am wrong
> please pipe up) the browser can detect the source of any of these
> examples (maybe some implication made based on the file extension but I
> could trick that too).

Although there is no difference to the browser, the difference to the
source code is not my only issue. If I separate the html and the php,
I can run them in different web servers. The web server for the second
example requires a php pre-processor. That isn't just a matter of
installation (or paying for the feature from your ISP as I do), it also
means that the version of the php pre-processor on your web server must
align with the version of php written in the file. I want to write
PHP5 and my ISP has no plans for moving there -- no date they can give
me.

==>2. a php file is not as portable as an html file

I could have all of my html on one server with one ISP and my hosted by
another (with a database on another).

-->3. I can separate the web servers used for html and that used for
php if I separate the code

> > browser-javascript controller hub, with php (or whatever I end up
> > choosing) used more as a mechanism for managing the persistence
> > interface and not highly involved in the user experience components of
> > the application.
>
> And for someone who dislikes js and its browser dependence, this sounds
> like a nightmare! In a model that I commonly use (and mentioned here),
> HTML and CSS can be/is stored in a database item or static file and
> retrieved per the user's preference (another buzz: 'skins'). Would you
> be able to store / catalog / retrieve this sort of 'user experience'
> information using javaScript?

I have no intention of using JavaScript for data persistence (other
than possibly cookies)

>
> Answering my own question: To an extent, yes. But it will be one
> helluva cookie. And what are you going to do when your users clear
> their cookie cache (or buy a new PC or ...)?
>
> Remember when considering the above that 'generating' CSS and HTML via
> a PHP script can be as simple as 'require "somefilename";' ... so you
> can easily offer a user a selection of 'experiences' and then quickly
> and easily (and invisibly to the browser) provide them with one line of
> code. Can you show me how to do this using js?

In theory, CSS would be the way to do changes to the look (and maybe
even feel to some extent), otherwise it would be done by javascript the
same way as any other data persistence -- ask the server for info and
apply it.

> > > And it can gather those pieces from
> > > disk files, database queries, calls to other servers or ???
> >
> > Yes, the web server & your php code are where it is happenin'. If I
> > get stuck with the other AJAX approach, I might end up there, but I am
> > hoping not to.
>
> And I am still VERY confused about this 'other AJAX'.

It isn't another AJAX -- just another approach -- using server-side
scripting for server-side functions and not as a pre-processor for
client-side html.

> Can you please
> alleviate my confusion on this? How would it differ from the two
> examples I have posted recently? (the pseudo code in this thread and
> the working code in another)
>
> <snip>
>
> > > The browser never sees anything not sent to it by the script. There is
> > > no obscuration through something unseen.
> >
> > I was thinking of the php intermixed with html making it harder to see
> > your html since you have to put your php-interpreter hat on to see what
> > the html will look like when you are coding. If this doesn't resonate
> > with you, it isn't likely important and might have only to do with my
> > lack of experience with php (I have written php, but very limited).
>
> Aha! Maybe I am beginning to see. Please reread the above but allow me
> to give you a real-world example:
>
> In my hosting business, I attempt to give the end user as much control
> as possible within the constraints of their (usually meagre) abilities.
> Some of the things that I offer are CMS bits - guestbook, links,
> calendar, classified ads, forums, portfolio (picture, not stock)
> management and so on.

I can tell you have done a lot with content management. I don't have
such experience. Content management as a browser-UI database
application has the unique aspect that the user data and your code need
to be highly integrated. So, I don't doubt that you have a good
strategy for your application. I'm looking at "data processing 101"
applications (scalable in many directions).

> I alluded to this elsewhere but here is how (this part of it) works:
>
> The script itself is vulernable to being overwritten accidentally so I
> make it be owned by the root user and without write perms for the user.
>
> To explain: If the user retrieves the web site using say frontPage, the
> _output_ of the guestbook script will be saved on their PC as
> 'guestbook.php'. When they dump it back, the HTML page that was
> generated by the guestbook.php script is copied back and wants to
> overwrite the sctipt. This would replace a dynamic script with a static
> page. We don't want that.
>
> To keep the scripts generic, the HTML is separate from the script and
> is INCLUDEd as above. Each virtual domain has their own HTML template
> directory and it is writable by them. They can use Netscape Composer,
> frontPage or whatever to edit these templates (implying that they can
> see them without the PHP interpreter). After modifications, the next
> time the PHP script is called, it includes the page with the changes.
>
> Does this make sense?

yes.

> E-Mail me tomd at blackflute dot com for a URL/Username/Passwd to see
> some toys I have been playing with using PHP/openQM/AJAX.

Will do. --dawn

.

Relevant Pages

  • Re: how to run scripts after a page has already loaded and been sent to a users browser?
    ... > It's because PHP is a server side scripting language, ... > do stuff before you send stuff to user's web browser. ... As we've discussed on this newsgroup before, if a script starts ... that is after the last HTML is sent to a web browser. ...
    (alt.php)
  • Re: standard coding...
    ... >> So the file, once spat out, should be called .html. ... >> still call php files .php even after they've been passed. ... The web server or the maintainer? ... Making sure your extensions match your content is ...
    (comp.lang.php)
  • Re: PHP-Yes, HTML-No --- Why?
    ... Because the files, when downloaded, are called .php and have absolutely no php in them:) ... But the extension doesn't match the contents of the file. ... Surely a dynamic web server should appear exactly the same as a static one - all files that contain HTML when viewed should be called .html. ...
    (comp.lang.php)
  • Re: PHP-Yes, HTML-No --- Why?
    ... Surely a dynamic web server should appear exactly the same as a static one - all files that contain HTML when viewed should be called ..html. ... If you know how, say, the PHP apache module works, you'll see that the hit is absolutely, positively minimal. ... "Andrew DeFaria" <That's also exactly why php files should have php as their extensions - because that's the way that web servers determine which pages not only need parsing, but which parsing it needs. ...
    (comp.lang.php)
  • Re: How do we get there from here?
    ... Unlike my dislike for PHP, my dislike for SQL is based on ... >>> up with at least html and php quite mixed into each other, ... Using a PHP script to send HTML ... code to a browser in no way taints that code. ...
    (comp.databases.pick)