| Newbie questions about Pliant
Opera webbrowser
Pliant seems to be almost compatible with Opera (6.1) now.
Modifying database fields does not works.
File upload does not work.
'deflate' compression is unkown?
|
| Message posted by thomasb on 2002/11/28 07:50:47 |
Do you have any idea way file upload does not work?
It fails with error message "I have not received the file name !".
There was a .page that to test all functions some time ago. Do you have this
page? Would make it easier to check if everythink is ok. |
| Message posted by hubert.tonneau on 2002/11/28 21:09:25 |
If you look in module /pliant/protocol/http/common/virtual_tre.page
you will find the Javascript code Pliant is using.
Part of it is:
http_stream writeline " if(f.elements[lb]i[rb].name.substring(0,12)=='file upload ') {"
http_stream writeline " if(f.elements[lb]i[rb].value!='') {"
http_stream writeline " document.pliant.encoding = 'multipart/form-data'"
http_stream writeline " }[lf]"
http_stream writeline " }"
So, Pliant always set forms method as 'POST', which is not compatible with
uploading a file, and when the button is clicked on, the 'complete' Javascript
function is always executable. In the function, if we find one of the form
fields to be a non empty file upload variable (which mean a file has truely
been specified in the browser) then we change the form format so that it will
send 'multipart/form-data' instead, which is less compact, but more powerfull
so is ok to upload a file.
The problem is probably that Opera is either not abble at all to send
'multipart/form-data' forms, or does not support the Javascript code I've
written in order to switch just before submition.
Anyway, if you are fond of Opera, you should have a look at the nighly build
(much better that the 0.4 milestone) of Phoenix lighter browser. It seems
to run better for us on small systems, it's still the high quality Gecko
engine, and it installs nicely through simply untarring to /usr/local/
http://www.mozilla.org/projects/phoenix/
|
| Message posted by thomasb on 2002/11/28 23:35:18 |
The problem is solved. I just changed:
document.pliant.encoding = 'multipart/form-data'
to:
document.pliant.enctype = 'multipart/form-data'
This actually works in Mozilla too, but according to the JavaScript spesification
the property is named 'encoding'. Even Opera's own spesification says this!
Maybe this changes in later versions of Opera, so I suggest to set both. |
| Message posted by thomasb on 2002/11/29 00:44:32 |
An even better solution would be to change the default. In html set
enctype='multipart/form-data' if there are any file upload fields in the form.
When the form is submitted this is changed if no non-empty file upload fields is
found.
This way, file upload will also work without JavaScript. |
| Message posted by hubert.tonneau on 2002/11/29 10:36:35 |
> The problem is solved.
Great.
I've included the following change:
if http_request:browser_model="opera"
http_stream writeline " document.pliant.enctype = 'multipart/form-data'"
else
http_stream writeline " document.pliant.encoding = 'multipart/form-data'"
The reason is that it is better for me fo have ifs in the code that remind
me everything non standard with each browser, and enables me to stick to the
standard for any unknown browser, which is probably better.
> An even better solution would be to change the default.
I would have switched the defaut if HTTP had provision for compression in forms
submition, just as it has for pages download.
Now having a browser silently using mime forms is probably a bad idea since
Pliant database forms can be very very long (thousands of cells), so if the
Javascript code is not abble to shrink it before back submition, then it's
probably better to fail than silently eat all the bandwidth which would also
disturb other users.
One important thing I have to change is switch to a two forms per page model:
one would be the down form which is filled by Pliant web pages, but will never
be sent back by the browser, the other would be the up form which would be
filled by Javascript code each time the user on the browser is changing a
field.
The key advantage would be significantly better responsivity when you press
a button. The reason is that currently, some Javascript code (mentionned
earlier) is used to shrink the form before submitting it back to the server
in order to save bandwidth (and avoid discarding changes that appent in the
mean time from other users to database fields). This is slow, because
Javascript is slow and it has to scan all form fields, including the very
large majority of them that the user did not change. So, switching to filling
a second form when a field is changed would mainly remove the need to scan
each field of the form.
Also I agree that Pliant is slowly moving to a Javascript is required model
which is probably not very good for openess. So, I also have to finish the
Pliant browser, which as no Javascript support, so that I can demonstrate
how it is possible to do all that with smart HTML / HTTP extensions instead.
|
| Message posted by thomasb on 2002/11/29 11:18:19 |
> Now having a browser silently using mime forms is probably a bad idea since
> Pliant database forms can be very very long (thousands of cells), so if the
> Javascript code is not abble to shrink it before back submition, then it's
> probably better to fail than silently eat all the bandwidth which would also
> disturb other users.
I understand, but is the bandwidth such a big problem?
> (and avoid discarding changes that appent in the
> mean time from other users to database fields).
However, this is a bigger problem...
> Also I agree that Pliant is slowly moving to a Javascript is required model
> which is probably not very good for openess.
You are quite right. Ideally JavaScript should only used to add extra
functionality and not requried for all basic functions. However I understand
that it might be better to fail than to abuse network resources.
> So, I also have to finish the Pliant browser, which as no Javascript support,
> so that I can demonstrate how it is possible to do all that with smart HTML / HTTP extensions instead.
I agree. JavaScript does not solve problems, but creates them...
However it would be nice to at if it was possible to add this smart extenstions
to existing browsers too. If JavaScript supported tcp/ip to the server this
could be quite easy. A small script could then have been written that waited
for new code from the server and eval()'ed it. A work around is to use Java.
A Java-applet talks to server and passes the new code to javascript engine via
LiveConnect. Not a very elegant design, but at least it should be possible. |
| Message posted by hubert.tonneau on 2002/11/29 13:29:18 |
> I understand, but is the bandwidth such a big problem?
You because my experience is that end users are unable to detect if sad
behaviour is related to selecting a poor browser, or bandwidth problems,
or server CPU power problems, or poor program design.
So, better avoid most possible problems since they will always conclude
to a general 'Pliant is bad'. |