Re: How do we get there from here?

Hi Dawn,

Hope I don't snip too much but I really need to get some work done <g>

<snip>

> > What is your DB of choice?
>
> U2, but I'm investigating other options as well, in and out of the MV
> world, but all non-1NF, and SQL is not the language I want to use for
> persistence. Unlike my dislike for PHP, my dislike for SQL is based on
> knowledge and experience. I'm a PHP-novice, perhaps ignoramous at this
> point.

At risk of sounding like a broken record, you should give openQM a try.
It took me a little getting used to due to my PICK background but
should be a breeze for you. And since you have at least some facility
with PHP it seems a good fit.

> > > You can work to separate these in a variety of ways, but you will end
> > > up with at least html and php quite mixed into each other, which is
> > > what php was designed to handle.
> >
> > Many in the php world even consider that bad form.
>
> good.
>
> > I sometimes exhibit
> > bad form.
>
> it happens to the best of us - a result of risk-assessment, I suppose

Or old, bad habits. The first dynamic content methods that I used were
all SSI oriented ... meaning that one was forced to mingle code and
HTML. Since going to real scripting (PHP) and CSS it is much easier to
separate but I still haven't purged all of my old code.

> > > Now assign someone, perhaps yourself, the responsibility for
> > > maintaining this source code. I'm working, instead, to write an xhtml
> > > document (as .html), one or more stylesheets as .css, one or more
> > > javascripts for client-side logic as .js, and one or more php
> > > server-side logic scripts as .php. Within the php will be the language
> > > used with the persistence mechanism, such as SQL.
> >
> > This is really all a matter of preference.
>
> Yes, but that preference is not arbitrary. There is likely a reason,
> based on my desire for big-bang-for-the-buck and highly maintainable
> systems, that I prefer to separate the source code for the various
> languages.

And I am pretty indifferent about this. In a tiny application, I will
just throw the CSS in there inline. There are times when separate files
become less maintainable.

Thinking about this brings to mind a local consulting firm (who
happened to be MV). In training a programmer, the owner strongly
suggested breaking the code down into subroutines. This person went hog
wild, making innumerable three line cataloged subs ... and making the
resultant code virtually unreadable. This negated one of the strong
points of PICK/BASIC: its maintainability.

> > In some applications I have
> > css and html 'boilerplate' that the end user can build upon ... but
> > their revisions are stored in a database.
>
> I suspect that is a somewhat common approach if you are building a
> content management-like system for users. I would prefer that the html
> and css be split out so the css links to the style *** instead.

Again, this decision should be based upon need IMHO. In a large system
or application it is the way to go. In a small one it may not be.

> > If no database entry is
> > found, the boilerplate is used.
>
> good enough.
>
> > This I think has confused you ... as I mentioned in my other post, it
> > matters not srom where the data comes.
>
> said like someone who cares not from where the data comes ;-)

It is just that making the source the major concern obscures the
mechanisms at play.

<snip>

> 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. It in no way defines nor dictates methodology. There was a
big blow-up in the PHP community recently when it was decided to firm
up PHP's object model and bring it in line with more mainstream models.
The procedural folks saw this as an assault on their way of doing
things. The procedural methods were retained (in some ways
strengthened) and PHP now has stronger OOP capabilities.

You can use PHP very much as you would use PICK/BASIC or (especially
now with PHP5) as you would use Java. If we have this sort of range in
one of the tools which comprise LAMP, can't the whole mess be less
rigid than your 'LAMP approach'?

> php controler hub. The paradigm I'm using has more of a

Again there are times when a 'hub' makes sense and times when it
doesn't.

A very important distinction: Using a PHP script to send HTML
(including js) code to a browser in no way taints that code. 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";
?>

somethingelse.php
<?
require "something.html";
?>

There is NO difference in the three examples above as far as the
browser is concerned. None. 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).

> 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?

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?

> > 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'. 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 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? The code isn't really 'intermingled' (with some
exceptions that CSS has diminished). Speaking of CSS, it can be handled
in this same way.

> > > If you are currently coding LAMP and want to move to AJAX, it is
> > > understandable that you might want to do it this way, however. If you
> > > are starting fresh, I wouldn't take that approach.
> > >
> > > Also, I would much rather use Java in the middle tier or a language
> >
> > Each to her own I guess. I strongly dislike Java and like PHP very
> > much. Doesn't matter as long as we understand where the pieces fit, eh?
>
> There's no accounting for taste ;-)

Taste (I'm a 3gl, procedural sort of guy) as well as liking the
quicker, lighter, more concise PHP over loading that cumbersome load of
stuff needed by Java on each call.

> My server is linux and last time I looked, I couldn't use openQM on

All of my servers are Linux (OK, <gulp> I _do_ still have one SCO box)
and use Linux for openQM development every day. You seem a perfect fit
for it.

> linux or perhaps it was just that the java interface wasn't there yet.
> I haven't looked at it lately.

Dunno (nor do I want to <g>) about a Java interface.

<snip>

> > I don't care for javaScript but it has become more predictable in
> > recent years. And as you said, if you want to do stupid browser tricks
> > you need to use it :-\
>
> Ah, here is where we really differ -- at one time I might have thought
> that JavaScript was for stupid browser tricks, but no longer. Google
> and others use javascript to write rich internet applications like
> gmail, google maps, etc. JavaScript is back on the rise because it is
> at the heart of AJAX. There is a reason that google is forcing
> Microsoft to reorganize and sweat a little.

OK after calling for accuracy in language, I deserved that. I was being
facetious.

> JavaScript is now an enterprise tool and one of the reasons why "real"
> software applications in a browser are likely to succeed. Did you look
> at the link -- brainjar.com/dhtml/windows/demo.html ? That is just one
> little hint at what is on the horizon for web apps. I have a huge list
> of ajax apps (that url is not ajax) that are quite impressive. cheers!
> --dawn

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.
-Tom

.

Quantcast