Avoid 'GET' method

[el_roachmeister]

Is there a way to make a text link post to a form without passing all
the parameters in the url? The urls tend to get very long and messy. I
often wonder if there is a limit to how long they can get?

[DJ Craig]

The 'POST' method?
http://www.w3schools.com/php/php_forms.asp

or sessions:
http://www.phpriot.com/d/articles/ph...-php-sessions/
or for really simple stuff, just cookies:
http://www.w3schools.com/php/php_cookies.asp
which can be written by javascript:
http://www.webreference.com/js/column8/functions.html

[John Dunlop]

somebody wrote:

Is there a way to make a text link post
no, you can't make a link *do* anything.
The urls tend to get very long and messy.
How come your addresses are so long?

What are you trying to do?
I often wonder if there is a limit to how long they can get?

no limit imposed by any public specification - in fact the
relevant one, RFC2616, even says it sets no limit - but
perhaps obviously there are implementation-specific limits.

--
Jock

[Gordon Burditt]

>> Is there a way to make a text link post

no, you can't make a link *do* anything.

Yes, you can, but it's debatable as to whether it's a good idea.
For example, you might have a link labelled 'Delete' next to
a listing for a user on the editusers.php page:
http://my.domain.com/admin/editusers...te&userid=7362
and clicking on it deletes the user in question. (Obviously some kind
of authentication is in use for this, and maybe it takes you to a
confirmation page).

I'd be interested in someone's idea for a solution to the general
problem: you have a table with possibly hundreds or thousands of
lines in it. You want to have several clickable things on *each
line* that do stuff to the item (say, a DNS record) in question
(edit, delete, disable, enable, whatever). I've been using GET
with links that have a mode variable and some kind of id variable.
Disadvantages: running linkchecker on this destroys the database,
given that it effectively clicks on every delete button.

I've considered using PUT with forms with hidden fields instead.
Disadvantages: (a) the submit buttons tend to be too darn big,
making viewing enough of the table at one time impossible, and (b)
browsers tend to run out of memory much faster with a thousand forms
rather than a thousand links, and (c) a page with lots of forms is
a lot longer in HTML than a page with lots of links, making load
times noticible.

Gordon L. Burditt

[Jim Hoagland]

Have you tried using hidden fields in a single form? You can use
JavaScript's onclick method to set your hidden fields based on the link you
click, and then to submit the form using formname.submit(); - your form can
the use the POST method. You can use the onsubmit=return confirm('are you
sure you want to delete'); to make sure a link checker never gets to delete
anything... it's also a good idea to have a JavaScript confirmation for your
users as they may not want to delete. Remember, of course, that this does
not stop anyone from deleting records with malicious intent - they can
submit a form from any other web site that is identical to yours - so you
will need an additional verification (login with cookies/session, etc).

ECRIA
http://www.ecria.com

[John Dunlop]

Gordon Burditt wrote:

[John Dunlop wrote:]

no, you can't make a link *do* anything.

Yes, you can,

yes, the resource the link identifies can do something, but
the link itself can't. that's what I meant; sorry for any
confusion.

--
Jock

[Gordon Burditt]

>Have you tried using hidden fields in a single form?

I don't see how to do that, as the value of the hidden field has to
identify which record is to be affected.

You can use
JavaScript's onclick method to set your hidden fields based on the link you
click, and then to submit the form using formname.submit(); - your form can
the use the POST method. You can use the onsubmit=return confirm('are you
sure you want to delete'); to make sure a link checker never gets to delete
anything... it's also a good idea to have a JavaScript confirmation for your
users as they may not want to delete.
JavaScript is Turned Off(tm) until someone comes up with a browser
that can have JavaScript selectively enabled by as sophisticated a
filter as Firefox has for cookies (enable for JavaScript from
specific hosts ONLY). And even then I'd have a hard time getting
it accepted by the admins in question. It manages to lock up
browsers too often, and having to remember to turn it off after
"temporarily" enabling it is a problem. Admins sometimes have to
investigate SPAM complaints, and this may lead them to follow links
in SPAM with malicious JavaScript (the most obnoxious that aren't
coupled with viruses are the ones that open two windows when you
close one).

Forms like this are for use by people who are supposed to know what
they are doing. Altering raw DNS records is not for the casual
user. Also, re-entering a single accidentally-deleted DNS record
does not require a lot of typing to re-enter. And there is a history
log of changes.

Other uses of pages like this are for personal applications like a
To Do list, which only one person will be using, me. One click to
mark something done. No confirmation. But the record isn't deleted,
so undoing the change is possible (but not as convenient). I have
yet to need to do that yet.
Remember, of course, that this does
not stop anyone from deleting records with malicious intent - they can
submit a form from any other web site that is identical to yours - so you
will need an additional verification (login with cookies/session, etc).

There's already .htaccess requiring passwords *AND* a very limited
set of IP addresses that it can be used from on the whole virtualhost.
The malicious intent problem is basically solved by firing anyone
found to be doing anything malicious, and keeping good backups.

Gordon L. Burditt

[Shelly]

<el*************@yahoo.com> wrote in message
news:11**********************@g47g2000cwa.googlegr oups.com...

Is there a way to make a text link post to a form without passing all
the parameters in the url? The urls tend to get very long and messy. I
often wonder if there is a limit to how long they can get?

How about setting all those variable in an array:

$theArray = array();
$theArray['item1'] = "item1 value";
etc.
$_SESSION['theArray'] = $theArray;

Then in the receiving page:
$theArray = $_SESSION['theArray'] ;
and then use
$theArray['item1'], etc.

If they weren't set then the value is NULL.

BTW, this works for me.

Shelly

[Malcolm Dew-Jones]

el*************@yahoo.com wrote:
: Is there a way to make a text link post to a form without passing all
: the parameters in the url? The urls tend to get very long and messy. I
: often wonder if there is a limit to how long they can get?

One possible technique

Use sessions.

Create a session for a user.

When you generate the table with all the links, save the details of each
link as part of the session, and index the details via an id, and use that
id in the link instead of the details.

<a href="mysite.com/myscript.php?the-id=A57">click here</a>


--

This space not for rent.

[Umberto Salsi]

go***********@burditt.org (Gordon Burditt) wrote:

I'd be interested in someone's idea for a solution to the general
problem: you have a table with possibly hundreds or thousands of
lines in it.

$button_n = 0;

function Button($text, $action)
{
global $button_n;
echo "<input type=submit name=button_", $button_n, " value=$text>";
echo "<input type=hidden name=action_", $button_n, " value=",
base64encode( serialize( $action ) ), ">";
/* optional: add an hidden field with the MAC of the serialized
$action, to be checked later on submit */
$button_n++;
}

/* Generate the form: */

for( every row of the table ){
echo "<form ...>";
echo "...the record...";
Button("Edit", array( "op" => EDIT, "record" => 1234 ));
Button("Remove", array( "op" => REMOVE, "record" => 1234 ));
/* ...and so on for every button */
echo "</form>";
}

.....

/* Handle the POST: */

$n = examine $_POST looking for the number of the parameter
named "^button_[0-9]+$";
$action = unserialize( base64decode( $_POST['action_' . $n] ) );
-- do the action given by $action

Hint: all those hidden fields may conveniently be stored in the user session.
Hint 2: the "$action" may contain the name and the arguments of a function
to call, so that with Button() we set a "call-back". In this case, better
to use the session, or the MAC is mandatory to prevent tampering.

Regards,
___
/_|_\ Umberto Salsi
\/_\/ www.icosaedro.it

[Tony Marston]

First, always use the POST method to update the database.

Second, do not put a separate set of buttons against each entry, use a
single set for the whole page. Put a checkbox against each entry so that the
user may select one or more entries, then when a button is pressed it
performs that action against those selected entries. Take a look at
http://www.tonymarston.co.uk/sample/person_list.php for an example.

This is part of my sample application
(http://www.tonymarston.net/php-mysql...plication.html) which you can
download to run locally.

--
Tony Marston

http://www.tonymarston.net

"Gordon Burditt" <go***********@burditt.org> wrote in message
news:11*************@corp.supernews.com...

Is there a way to make a text link post

no, you can't make a link *do* anything.

Yes, you can, but it's debatable as to whether it's a good idea.
For example, you might have a link labelled 'Delete' next to
a listing for a user on the editusers.php page:
http://my.domain.com/admin/editusers...te&userid=7362
and clicking on it deletes the user in question. (Obviously some kind
of authentication is in use for this, and maybe it takes you to a
confirmation page).

I'd be interested in someone's idea for a solution to the general
problem: you have a table with possibly hundreds or thousands of
lines in it. You want to have several clickable things on *each
line* that do stuff to the item (say, a DNS record) in question
(edit, delete, disable, enable, whatever). I've been using GET
with links that have a mode variable and some kind of id variable.
Disadvantages: running linkchecker on this destroys the database,
given that it effectively clicks on every delete button.

I've considered using PUT with forms with hidden fields instead.
Disadvantages: (a) the submit buttons tend to be too darn big,
making viewing enough of the table at one time impossible, and (b)
browsers tend to run out of memory much faster with a thousand forms
rather than a thousand links, and (c) a page with lots of forms is
a lot longer in HTML than a page with lots of links, making load
times noticible.

Gordon L. Burditt

[Peter Fox]

Following on from Malcolm Dew-Jones's message. . .

el*************@yahoo.com wrote:
: Is there a way to make a text link post to a form without passing all
: the parameters in the url? The urls tend to get very long and messy. I
: often wonder if there is a limit to how long they can get?

One possible technique

Use sessions.

Create a session for a user.

When you generate the table with all the links, save the details of each
link as part of the session, and index the details via an id, and use that
id in the link instead of the details.

<a href="mysite.com/myscript.php?the-id=A57">click here</a>

And if your record ids are 1,2,3 ... 45,46,47 etc then you need to
protect that id from being known or accessible or usable from the
'hidden' information. [Even if you use large random numbers for record
IDs this only protects against peeking at another customer's record etc
(and then not perfectly) and it means that for example
"?CN=123456789&ACTION=DENY" is an invitation to use the same CN with
other actions.]

So, one method is to create a record in the session (array) of
parameters and dynamically generated random number. The link now looks
lime "?LNK=152482763" with 152482763 referencing something in the
session. The next time the exact same link is generated (same customer,
same action say) there will be a completely different random number.

This works for page-to-page links and also URLs embedded into emails.
(In the latter case store the info in a table. - I have a class that
encapsulates this nicely with extra functions for things like expiry and
deleting all options when one is chosen - I suppose I ought to start
publishing some of my useful classes.)
--
PETER FOX Not the same since the e-commerce business came to a .
pe******@eminent.demon.co.uk.not.this.bit.no.html
2 Tees Close, Witham, Essex.
Gravity beer in Essex <http://www.eminent.demon.co.uk>

[Bob]

Tony,
Those are beautiful pages.
I did not think you could do that with php.
Now I have some serious reading to do on XSL.
Thanks.

[Gordon Burditt]

>First, always use the POST method to update the database.
It would be nice if that were practical.

Second, do not put a separate set of buttons against each entry, use a
single set for the whole page.
This is WAY too clumsy a user interface for what I want.
Do you have stock in a medical corporation that treats carpal
mouse syndrome?

On your page I can only see 10 records at a time, and there's a
lot of space between them. I'd like to see at least 30. Without
scrolling (on a 1024x768 display). But I don't mind scrolling if
there's hundreds of records. The different sort orders available
usually put the records I'm interested in at the top.
Put a checkbox against each entry so that the
user may select one or more entries, then when a button is pressed it
performs that action against those selected entries. Take a look at
http://www.tonymarston.co.uk/sample/person_list.php for an example.

Selecting more than one record at a time is rarely useful for
my purposes. The idea is to enter updates as needed, not save
up a whole batch of them and enter them every few days.

Gordon L. Burditt

[Tony Marston]

"Gordon Burditt" <go***********@burditt.org> wrote in message
news:11*************@corp.supernews.com...

First, always use the POST method to update the database. It would be nice if that were practical.

Tell me why it is NOT practical?

Second, do not put a separate set of buttons against each entry, use a
single set for the whole page.

This is WAY too clumsy a user interface for what I want.
Do you have stock in a medical corporation that treats carpal
mouse syndrome?

It is not clumsy. I have been using a similar interface on desktop
applications for 20 years and no user has ever complained.
On your page I can only see 10 records at a time, and there's a
lot of space between them. I'd like to see at least 30.
That's what the "show 10 | show 25 | show 50 | show 100" hyperlinks are for,
to allow you to set your own page size.
Without
scrolling (on a 1024x768 display).
You cannot guarantee that everyone has a screen resolution of 1024x768
But I don't mind scrolling if
there's hundreds of records. The different sort orders available
usually put the records I'm interested in at the top.

The column headings are hyperlinks which, when pressed, will cause the data
to be sorted on that column. I mean ALL the data, not just the data in the
current page.

Put a checkbox against each entry so that the
user may select one or more entries, then when a button is pressed it
performs that action against those selected entries. Take a look at
http://www.tonymarston.co.uk/sample/person_list.php for an example.

Selecting more than one record at a time is rarely useful for
my purposes. The idea is to enter updates as needed, not save
up a whole batch of them and enter them every few days.

It may not be useful for your purposes, but other people find it VERY
useful. It is not about storing updates for several days and then applying
them in a batch.

In your method I suppose you can only select one record at a time in the
LIST screen before you can navigate down to a DETAIL screen. If you then
want to move onto another record you have to exit the DETAIL, return to the
LIST screen, make another selection, then activate the DETAIL screen again.
Using my method you can select all the records in the LIST screen (that's
what the "select all" hyperlink is for, by the way) then activate the chosen
DETAIL screen. This shows you the first record that you selected, but gives
you scrolling options so that you can scroll forwards and backwards through
all the records you selected WITHOUT having to return to the LIST screen.

How do you like THEM apples?

--
Tony Marston

http://www.tonymarston.net

[Tony Marston]

"Bob" <cl****@qualitythink.com> wrote in message
news:11**********************@g43g2000cwa.googlegr oups.com...

Tony,
Those are beautiful pages.
I did not think you could do that with php.
Now I have some serious reading to do on XSL.
Thanks.

Those pages are straightforward HTML which PHP was designed to generate, so
why should PHP not be able to generate them? The same pages can be generated
in ANY language. It's not rocket science.

The page design follows what I achieved in a desktop programming language
for the previous 10 years. All I have done is adapt them for a stateless
environment.

--
Tony Marston

http://www.tonymarston.net

[Bob]

Let me amplify my statement, I did not conceive of this being possible
in a "stateless" environment.

[Tony Marston]

"Bob" <cl****@qualitythink.com> wrote in message
news:11**********************@g43g2000cwa.googlegr oups.com...

Let me amplify my statement, I did not conceive of this being possible
in a "stateless" environment.

PHP's session handling functions (see
http://www.php.net/manual/en/ref.session.php) help a great deal. This makes
it easy to pass data between one page request and another within the same
session. It would not be so easy trying to do it with cookies or hidden HTML
fields.

--
Tony Marston

http://www.tonymarston.net

[Gordon Burditt]

>> >First, always use the POST method to update the database.

It would be nice if that were practical.
Tell me why it is NOT practical?

(a) too many forms slow browser to a crawl and/or run it out of memory.
(b) the amount of HTML required has a noticible effect on load time.

Second, do not put a separate set of buttons against each entry, use a
single set for the whole page.

This is WAY too clumsy a user interface for what I want.
Do you have stock in a medical corporation that treats carpal
mouse syndrome?

It is not clumsy. I have been using a similar interface on desktop
applications for 20 years and no user has ever complained.

*I* am the primary user of this interface, and *I* am complaining.

This is not a typical user interface: it's for admins, and you can
expect that admins will have privileges and know-how to do anything
the page can do with manually-typed-in SQL. If mass changes are
required, it will probably be easier and safer to use manually-typed-in
SQL. The page is supposed to be for quick entry of simple changes.
If it's not more convenient to use the page than manually-typed-in
SQL, it's useless.

I certainly wouldn't design something like this for the world at
large to use. And that's not who's going to be using it.

On your page I can only see 10 records at a time, and there's a
lot of space between them. I'd like to see at least 30.

That's what the "show 10 | show 25 | show 50 | show 100" hyperlinks are for,
to allow you to set your own page size.

But you still can't see that many on the screen at one time.
Checkboxes or submit buttons take up too much vertical space, out
of proportion to the actual size of the box or button on the screen,
and I haven't found a way around that even by making the type size
tiny. To make the interface usable, I want to be able to SEE lots
of records at a time.

Without
scrolling (on a 1024x768 display).

You cannot guarantee that everyone has a screen resolution of 1024x768

I can guarantee that anyone who doesn't is not authorized to use
the application. :-) I'll tolerate scrolling if the screen is
smaller, although there aren't that many smaller screens around any
more.

But I don't mind scrolling if
there's hundreds of records. The different sort orders available
usually put the records I'm interested in at the top.

The column headings are hyperlinks which, when pressed, will cause the data
to be sorted on that column. I mean ALL the data, not just the data in the
current page.

Ok, this is much like the pages I have, except I don't try to paginate
them, just put everything on one page. Also, there's a search function
to display a subset of the data.

Put a checkbox against each entry so that the
user may select one or more entries, then when a button is pressed it
performs that action against those selected entries. Take a look at
http://www.tonymarston.co.uk/sample/person_list.php for an example.
Selecting more than one record at a time is rarely useful for
my purposes. The idea is to enter updates as needed, not save
up a whole batch of them and enter them every few days.

It may not be useful for your purposes, but other people find it VERY
useful.

Other people aren't authorized to use this application. User
interface design is not a one-size-fits-all thing: it should be
done with the users who are going to use it, which is not always
the entire world.
It is not about storing updates for several days and then applying
them in a batch.

In your method I suppose you can only select one record at a time in the
LIST screen before you can navigate down to a DETAIL screen. If you then
I want to be able to change the status of a record *WITHOUT* going
to a detail screen. If I want a detail screen, that's what the
EDIT button is for, which allows changing a lot more fields but is
used less often.
want to move onto another record you have to exit the DETAIL, return to the
LIST screen, make another selection, then activate the DETAIL screen again.
Using my method you can select all the records in the LIST screen (that's
what the "select all" hyperlink is for, by the way) then activate the chosen
DETAIL screen. This shows you the first record that you selected, but gives
you scrolling options so that you can scroll forwards and backwards through
all the records you selected WITHOUT having to return to the LIST screen.

How do you like THEM apples?

Manually-typed-in SQL is looking better all the time ...

Gordon L. Burditt

[Tony Marston]

"Gordon Burditt" <go***********@burditt.org> wrote in message
news:11*************@corp.supernews.com...

>First, always use the POST method to update the database.
It would be nice if that were practical.
Tell me why it is NOT practical?

(a) too many forms slow browser to a crawl and/or run it out of memory.
(b) the amount of HTML required has a noticible effect on load time.

There are no studies which show that the POST method is slower than the GET
method, or puts a heavier load on the server, so I don't believe you.

Second, do not put a separate set of buttons against each entry, use a
single set for the whole page.

This is WAY too clumsy a user interface for what I want.
Do you have stock in a medical corporation that treats carpal
mouse syndrome?

It is not clumsy. I have been using a similar interface on desktop
applications for 20 years and no user has ever complained.

*I* am the primary user of this interface, and *I* am complaining.

I prefer the opinion of all my users over the past 10 years over that of a
lone individual.
This is not a typical user interface: it's for admins, and you can
expect that admins will have privileges and know-how to do anything
the page can do with manually-typed-in SQL. If mass changes are
required, it will probably be easier and safer to use manually-typed-in
SQL. The page is supposed to be for quick entry of simple changes.
If it's not more convenient to use the page than manually-typed-in
SQL, it's useless.

I certainly wouldn't design something like this for the world at
large to use. And that's not who's going to be using it.

On your page I can only see 10 records at a time, and there's a
lot of space between them. I'd like to see at least 30.
That's what the "show 10 | show 25 | show 50 | show 100" hyperlinks are
for,
to allow you to set your own page size.

But you still can't see that many on the screen at one time.

If you click "show 50" it changes the page size to 50 lines. Did you
actually try it?
Checkboxes or submit buttons take up too much vertical space, out
of proportion to the actual size of the box or button on the screen,
I think that one checkbox per line and one set of navigation links per page
is FAR superior to a separate set of navigation links per line. But that's
just my opinion (and the opinion of all my users over the past 10 years.).
and I haven't found a way around that even by making the type size
tiny. To make the interface usable, I want to be able to SEE lots
of records at a time.
That's what the "show 10 | show 25 | show 50 | show 100" hyperlinks are for.

Without
scrolling (on a 1024x768 display).

You cannot guarantee that everyone has a screen resolution of 1024x768

I can guarantee that anyone who doesn't is not authorized to use
the application. :-)

So it's not an internet application then?
I'll tolerate scrolling if the screen is
smaller, although there aren't that many smaller screens around any
more.

But I don't mind scrolling if
there's hundreds of records. The different sort orders available
usually put the records I'm interested in at the top.

The column headings are hyperlinks which, when pressed, will cause the
data
to be sorted on that column. I mean ALL the data, not just the data in the
current page.

Ok, this is much like the pages I have, except I don't try to paginate
them, just put everything on one page. Also, there's a search function
to display a subset of the data.

There's also a search function in my screen. Just press the SEARCH button
and up it pops.

Put a checkbox against each entry so that the
user may select one or more entries, then when a button is pressed it
performs that action against those selected entries. Take a look at
http://www.tonymarston.co.uk/sample/person_list.php for an example.

Selecting more than one record at a time is rarely useful for
my purposes. The idea is to enter updates as needed, not save
up a whole batch of them and enter them every few days.

It may not be useful for your purposes, but other people find it VERY
useful.

Other people aren't authorized to use this application. User
interface design is not a one-size-fits-all thing: it should be
done with the users who are going to use it, which is not always
the entire world.

It is not about storing updates for several days and then applying
them in a batch.

In your method I suppose you can only select one record at a time in the
LIST screen before you can navigate down to a DETAIL screen. If you then

I want to be able to change the status of a record *WITHOUT* going
to a detail screen. If I want a detail screen, that's what the
EDIT button is for, which allows changing a lot more fields but is
used less often.

Surely a LIST screen is for listing data while an UPDATE screen is for
updating data?

want to move onto another record you have to exit the DETAIL, return to
the
LIST screen, make another selection, then activate the DETAIL screen
again.
Using my method you can select all the records in the LIST screen (that's
what the "select all" hyperlink is for, by the way) then activate the
chosen
DETAIL screen. This shows you the first record that you selected, but
gives
you scrolling options so that you can scroll forwards and backwards
through
all the records you selected WITHOUT having to return to the LIST screen.

How do you like THEM apples?

Manually-typed-in SQL is looking better all the time ...

Gordon L. Burditt

If your users are happy to manually type in the SQL to update the database
then why bother trying to write your own user interface at all? Just give
them phpMyAdmin and have done with it.

--
Tony Marston

http://www.tonymarston.net

[Gordon Burditt]

>>>> >First, always use the POST method to update the database.

It would be nice if that were practical.

Tell me why it is NOT practical?
(a) too many forms slow browser to a crawl and/or run it out of memory.
(b) the amount of HTML required has a noticible effect on load time.

There are no studies which show that the POST method is slower than the GET
method, or puts a heavier load on the server, so I don't believe you.

Count the characters in the HTML (these take time to transmit over the net):

Link method:

<a href="zone.php?id=5&mode=delete">Delete</a>

vs. form method:

<form action="zone.php"><input type="hidden" name="id" value="5"><input type="mode" value="delete"><input type="submit" value="delete"></form>

Can you shrink the form method to use less than 50% more characters
than the link method?

More HTML takes more time to send over the net. Multiply that by
hundreds of lines of data and multiple buttons per line. Lots of
forms seem to slow down the *BROWSER* much more than lots of links.
I didn't say anything about server load, except the bigger the HTML,
the more it takes to send it. IE6 seems to get much slower for
1000 forms vs. 1000 links. Firefox and Mozilla don't slow down as
much, but they still slow down. I suspect it takes more memory to
deal with forms than links and the browser starts paging. In any
case, I don't get to redesign the browsers. Even with an open-source
browser, that takes too much effort.

>Second, do not put a separate set of buttons against each entry, use a
>single set for the whole page.

This is WAY too clumsy a user interface for what I want.
Do you have stock in a medical corporation that treats carpal
mouse syndrome?

It is not clumsy. I have been using a similar interface on desktop
applications for 20 years and no user has ever complained.
*I* am the primary user of this interface, and *I* am complaining.

I prefer the opinion of all my users over the past 10 years over that of a
lone individual.

You prefer the opinion of people who are *NOT* using the application
over the person that is? I pity anyone you're doing web design for
if you won't pay attention to the requirements for the design.

This is not a typical user interface: it's for admins, and you can
expect that admins will have privileges and know-how to do anything
the page can do with manually-typed-in SQL. If mass changes are
required, it will probably be easier and safer to use manually-typed-in
SQL. The page is supposed to be for quick entry of simple changes.
If it's not more convenient to use the page than manually-typed-in
SQL, it's useless.

I certainly wouldn't design something like this for the world at
large to use. And that's not who's going to be using it.

On your page I can only see 10 records at a time, and there's a
lot of space between them. I'd like to see at least 30.

That's what the "show 10 | show 25 | show 50 | show 100" hyperlinks are
for,
to allow you to set your own page size.

But you still can't see that many on the screen at one time.

If you click "show 50" it changes the page size to 50 lines. Did you
actually try it?

I want to see at least 30 lines on the *SCREEN*. Not the *PAGE*.
I want 30 lines on the *SCREEN* simultaneously. Checkboxes and
submit buttons seem to take much more vertical space than they
visually occupy so you can't get that even if you make the font
size way too tiny.

Checkboxes or submit buttons take up too much vertical space, out
of proportion to the actual size of the box or button on the screen,
I think that one checkbox per line and one set of navigation links per page
is FAR superior to a separate set of navigation links per line. But that's
just my opinion (and the opinion of all my users over the past 10 years.).

They aren't "navigation links", they are things you click on that
DO something.

and I haven't found a way around that even by making the type size
tiny. To make the interface usable, I want to be able to SEE lots
of records at a time.

That's what the "show 10 | show 25 | show 50 | show 100" hyperlinks are for.

Without
scrolling (on a 1024x768 display).

You cannot guarantee that everyone has a screen resolution of 1024x768

I can guarantee that anyone who doesn't is not authorized to use
the application. :-)

So it's not an internet application then?

It does operate over the internet (admins can use it from home).
It most certainly is not intended for general use by the public.

I'll tolerate scrolling if the screen is
smaller, although there aren't that many smaller screens around any
more.

But I don't mind scrolling if
there's hundreds of records. The different sort orders available
usually put the records I'm interested in at the top.

The column headings are hyperlinks which, when pressed, will cause the
data
to be sorted on that column. I mean ALL the data, not just the data in the
current page.

Ok, this is much like the pages I have, except I don't try to paginate
them, just put everything on one page. Also, there's a search function
to display a subset of the data.

There's also a search function in my screen. Just press the SEARCH button
and up it pops.

>Put a checkbox against each entry so that the
>user may select one or more entries, then when a button is pressed it
>performs that action against those selected entries. Take a look at
>http://www.tonymarston.co.uk/sample/person_list.php for an example.

Selecting more than one record at a time is rarely useful for
my purposes. The idea is to enter updates as needed, not save
up a whole batch of them and enter them every few days.

It may not be useful for your purposes, but other people find it VERY
useful.

Other people aren't authorized to use this application. User
interface design is not a one-size-fits-all thing: it should be
done with the users who are going to use it, which is not always
the entire world.

It is not about storing updates for several days and then applying
them in a batch.

In your method I suppose you can only select one record at a time in the
LIST screen before you can navigate down to a DETAIL screen. If you then

I want to be able to change the status of a record *WITHOUT* going
to a detail screen. If I want a detail screen, that's what the
EDIT button is for, which allows changing a lot more fields but is
used less often.

Surely a LIST screen is for listing data while an UPDATE screen is for
updating data?

A <whatever you want to call it> screen is for listing data *and*
making quick one-click updates to the status of things. That's
what's needed.

want to move onto another record you have to exit the DETAIL, return to
the
LIST screen, make another selection, then activate the DETAIL screen
again.
Using my method you can select all the records in the LIST screen (that's
what the "select all" hyperlink is for, by the way) then activate the
chosen
DETAIL screen. This shows you the first record that you selected, but
gives
you scrolling options so that you can scroll forwards and backwards
through
all the records you selected WITHOUT having to return to the LIST screen.

How do you like THEM apples?

Manually-typed-in SQL is looking better all the time ...

Gordon L. Burditt

If your users are happy to manually type in the SQL to update the database
then why bother trying to write your own user interface at all? Just give
them phpMyAdmin and have done with it.

A well-written (NOT according to your standards, though) page would
allow users to make a set of simple changes (but which comprise a
very large percentage of the changes actually needed in practice)
faster than typing manual SQL. Change the status of something:
call up the page (likely to be bookmarked), then one click to make
the change. You seem to insist that because it's not a suitable
interface for the general public (and I agree, it's not), it
can't/shouldn't be done at all.

Gordon L. Burditt

[Tony Marston]

"Gordon Burditt" <go***********@burditt.org> wrote in message
news:11*************@corp.supernews.com...

> >First, always use the POST method to update the database.
> It would be nice if that were practical.

Tell me why it is NOT practical?

(a) too many forms slow browser to a crawl and/or run it out of memory.
(b) the amount of HTML required has a noticible effect on load time.
There are no studies which show that the POST method is slower than the
GET
method, or puts a heavier load on the server, so I don't believe you.

Count the characters in the HTML (these take time to transmit over the
net):

Link method:

<a href="zone.php?id=5&mode=delete">Delete</a>

vs. form method:

<form action="zone.php"><input type="hidden" name="id" value="5"><input
type="mode" value="delete"><input type="submit" value="delete"></form>

Can you shrink the form method to use less than 50% more characters
than the link method?

Your style of coding is very inefficient. In my pages, using the POST
method, I have no more than this:

<input class="submit" type="submit" name="task#person_del.php"
value="Delete" />

The advantage of my method is that I do not pass primary keys in URLs as a
security measure.
More HTML takes more time to send over the net. Multiply that by
hundreds of lines of data and multiple buttons per line. Lots of
forms seem to slow down the *BROWSER* much more than lots of links.
I didn't say anything about server load, except the bigger the HTML,
the more it takes to send it. IE6 seems to get much slower for
1000 forms vs. 1000 links. Firefox and Mozilla don't slow down as
much, but they still slow down. I suspect it takes more memory to
deal with forms than links and the browser starts paging. In any
case, I don't get to redesign the browsers. Even with an open-source
browser, that takes too much effort.

>>Second, do not put a separate set of buttons against each entry, use a
>>single set for the whole page.
>
> This is WAY too clumsy a user interface for what I want.
> Do you have stock in a medical corporation that treats carpal
> mouse syndrome?

It is not clumsy. I have been using a similar interface on desktop
applications for 20 years and no user has ever complained.

*I* am the primary user of this interface, and *I* am complaining.
I prefer the opinion of all my users over the past 10 years over that of a
lone individual.

You prefer the opinion of people who are *NOT* using the application
over the person that is? I pity anyone you're doing web design for
if you won't pay attention to the requirements for the design.

The people who have used the applications that I have been writing over the
past 10 years have not complained. I ignore the opinions of those who do not
use my software.

This is not a typical user interface: it's for admins, and you can
expect that admins will have privileges and know-how to do anything
the page can do with manually-typed-in SQL. If mass changes are
required, it will probably be easier and safer to use manually-typed-in
SQL. The page is supposed to be for quick entry of simple changes.
If it's not more convenient to use the page than manually-typed-in
SQL, it's useless.

I certainly wouldn't design something like this for the world at
large to use. And that's not who's going to be using it.

> On your page I can only see 10 records at a time, and there's a
> lot of space between them. I'd like to see at least 30.

That's what the "show 10 | show 25 | show 50 | show 100" hyperlinks are
for,
to allow you to set your own page size.

But you still can't see that many on the screen at one time.

If you click "show 50" it changes the page size to 50 lines. Did you
actually try it?

I want to see at least 30 lines on the *SCREEN*. Not the *PAGE*.
I want 30 lines on the *SCREEN* simultaneously.

Whenever I have been asked by a lone individual to fill the screen with as
much data as possible in order to prevent the need to jump to another screen
all the other users reject it for being too "busy". They prefer the data
being presented in reasonably sized chunks rather than great masses.

Thank goodness I will never have to use one of your applications.
Checkboxes and
submit buttons seem to take much more vertical space than they
visually occupy so you can't get that even if you make the font
size way too tiny.

Checkboxes or submit buttons take up too much vertical space, out
of proportion to the actual size of the box or button on the screen,

I think that one checkbox per line and one set of navigation links per
page
is FAR superior to a separate set of navigation links per line. But that's
just my opinion (and the opinion of all my users over the past 10 years.).

They aren't "navigation links", they are things you click on that
DO something.

Then you don't understand the meaning of the term "navigation link". It is a
method of navigating to another script in order to perform a different
action. The current script also passes down any context so that the new
script knows which record to act on.

and I haven't found a way around that even by making the type size
tiny. To make the interface usable, I want to be able to SEE lots
of records at a time.

That's what the "show 10 | show 25 | show 50 | show 100" hyperlinks are
for.

> Without
> scrolling (on a 1024x768 display).

You cannot guarantee that everyone has a screen resolution of 1024x768

I can guarantee that anyone who doesn't is not authorized to use
the application. :-)

So it's not an internet application then?

It does operate over the internet (admins can use it from home).
It most certainly is not intended for general use by the public.

I'll tolerate scrolling if the screen is
smaller, although there aren't that many smaller screens around any
more.
There are still plenty of people using screens at 800 x 600.
But I don't mind scrolling if
> there's hundreds of records. The different sort orders available
> usually put the records I'm interested in at the top.

The column headings are hyperlinks which, when pressed, will cause the
data
to be sorted on that column. I mean ALL the data, not just the data in
the
current page.

Ok, this is much like the pages I have, except I don't try to paginate
them, just put everything on one page. Also, there's a search function
to display a subset of the data.

There's also a search function in my screen. Just press the SEARCH button
and up it pops.

>>Put a checkbox against each entry so that the
>>user may select one or more entries, then when a button is pressed it
>>performs that action against those selected entries. Take a look at
>>http://www.tonymarston.co.uk/sample/person_list.php for an example.
>
> Selecting more than one record at a time is rarely useful for
> my purposes. The idea is to enter updates as needed, not save
> up a whole batch of them and enter them every few days.

It may not be useful for your purposes, but other people find it VERY
useful.

Other people aren't authorized to use this application. User
interface design is not a one-size-fits-all thing: it should be
done with the users who are going to use it, which is not always
the entire world.

It is not about storing updates for several days and then applying
them in a batch.

In your method I suppose you can only select one record at a time in the
LIST screen before you can navigate down to a DETAIL screen. If you then

I want to be able to change the status of a record *WITHOUT* going
to a detail screen. If I want a detail screen, that's what the
EDIT button is for, which allows changing a lot more fields but is
used less often.

Surely a LIST screen is for listing data while an UPDATE screen is for
updating data?

A <whatever you want to call it> screen is for listing data *and*
making quick one-click updates to the status of things. That's
what's needed.

Not in my designs it isn't. A LIST screen is for listing, an UPDATE screen
is for updating, and an INSERT screen is for inserting.

want to move onto another record you have to exit the DETAIL, return to
the
LIST screen, make another selection, then activate the DETAIL screen
again.
Using my method you can select all the records in the LIST screen
(that's
what the "select all" hyperlink is for, by the way) then activate the
chosen
DETAIL screen. This shows you the first record that you selected, but
gives
you scrolling options so that you can scroll forwards and backwards
through
all the records you selected WITHOUT having to return to the LIST
screen.

How do you like THEM apples?

Manually-typed-in SQL is looking better all the time ...

Gordon L. Burditt

If your users are happy to manually type in the SQL to update the database
then why bother trying to write your own user interface at all? Just give
them phpMyAdmin and have done with it.

A well-written (NOT according to your standards, though) page would
allow users to make a set of simple changes (but which comprise a
very large percentage of the changes actually needed in practice)
faster than typing manual SQL. Change the status of something:
call up the page (likely to be bookmarked), then one click to make
the change. You seem to insist that because it's not a suitable
interface for the general public (and I agree, it's not), it
can't/shouldn't be done at all.

Gordon L. Burditt

You design applications your way, and I will continue to design applications
my way.

--
Tony Marston

http://www.tonymarston.net

[Geoff Berrow]

I noticed that Message-ID: <db*******************@news.demon.co.uk> from
Tony Marston contained the following:

<input class="submit" type="submit" name="task#person_del.php"
value="Delete" />

The advantage of my method is that I do not pass primary keys in URLs as a
security measure.

What's the worst they could do with the primary key?

--
Geoff Berrow (put thecat out to email)
It's only Usenet, no one dies.
My opinions, not the committee's, mine.
Simple RFDs http://www.ckdog.co.uk/rfdmaker/

[Tony Marston]

"Geoff Berrow" <bl******@ckdog.co.uk> wrote in message
news:qr********************************@4ax.com...

I noticed that Message-ID: <db*******************@news.demon.co.uk> from
Tony Marston contained the following:

<input class="submit" type="submit" name="task#person_del.php"
value="Delete" />

The advantage of my method is that I do not pass primary keys in URLs as a
security measure.

What's the worst they could do with the primary key?

Submit a request using the primary key of a record which they are not
authorised to access. This would be a HUGE security flaw.

--
Tony Marston

http://www.tonymarston.net

[Csaba Gabor]

Correct me if I am wrong, Gordon, but as I understand it, what you want
is, effectively, a "what you see is what there is" type of editor for a
database, similar to the notion of Excel (where you might have to do a
final save to commit). The idea of having to select a row, then bring
up a form for it, then edit it, then commit it, is way too slow. Too
many mouse clicks, too much waiting (for page loading), too much
distraction as pages change. If so, I concur - in the situation where
a user is allowed wholesale access to the database (or significant
subportion thereof), it would be far more efficient to be able to make
direct edits.

I implemented something like this a year ago (only an alpha version,
but I still use it). However, I do not share your aversion to
javascript usage. What I have done is to return (a portion of) the
database, which I display in an HTML table. Fields are either freely
changeable, grudgingly changeable (computed fields such as Ids) in
gray, or not changeable (derived values). As you change a field (which
is really a textarea or text input element within a TD), onChange
scripts highlight the entry in red, if it has changed. There are
additional considerations such as the maximum number of lines to allow
a field to expand to. At any rate, once a line has been suitably
modified, the user clicks on a small Insert or Append button that
appeared as that record started to be edited (which buttons have an
accessKey set, of course. In the case of Insert, the gray fields don't
get submitted). The values for the line being edited are collected and
posted via an IFrame. The database signals back to the IFrame whether
there was a problem or not, and a <body onload=...> from the IFrame
causes that row to be suitably refreshed. Saves me a huge amount of
time.
However, if you are insistent on staying with no javascript, can't you
do something like the following where you can make that POST button
look like a link with something like:
<form method=post action="showInfo.php" name=myform>
<input type=hidden name='foo' value='bar'>
<button name=tryme value=hitme
style="border:0px solid red;background-color: white"
accessKey='s' type='Submit'><u>S</u>ubmit</button>
</form>
</body>
For showinfo.php I just had
<?php phpinfo(); ?>
Upon rereading your post, I see that you only want to take prescripted
actions. The method I outlined just above does not require hidden
fields, and all the action is encoded (by virtue of identifying the
recordId and action in the single value=... of the <button ...>. Only
one form is necessary, not many. And as shown, by using style sheets
(the generalization of the style="..." line) you can make the button
seem like a gainly link.

Csaba Gabor from Vienna