Post #53,784
9/29/02 1:47:05 AM
|
Avoid web-based
(* wap or web browser based custom for the small screen size. *)
Nahw! You want coordinate-based control of the screen. Flow-based (nested) layout management of widgets goes down-hill really fast for non-trivial UI's.
Others may disagree, but that is my .02.
________________
oop.ismad.com
|
Post #53,969
9/30/02 12:46:35 PM
|
Re: Avoid web-based
Agreed, but disgreed. Avoid web-based, use Acrobat for forms. It's killer-diller! And it's completely transparent across anything that can run Acrobat (Reader). It's close to realizing my dream of HTML/PDF unification.
-drl
|
Post #54,153
10/1/02 12:25:23 AM
|
okay now I am totally confused
html is a language that allows input fields across a lot of platforms. The input can be used to access a lot of legacy and non legacy type data which is then displayed back to the user in a co-herent fashion. It is called stove-piping. What the heck is wrong with that?
thanx,
bill
will work for cash and other incentives [link|http://home.tampabay.rr.com/boxley/resume/Resume.html|skill set]
qui mori didicit servire dedidicit
|
Post #55,000
10/5/02 12:43:18 AM
|
What, character Lynx?
________________
oop.ismad.com
|
Post #55,033
10/5/02 3:37:40 AM
|
Yes.
Peter
[link|http://www.debian.org|Shill For Hire]
[link|http://www.kuro5hin.org|There is no K5 Cabal]
[link|http://guildenstern.dyndns.org|Blog]
|
Post #59,582
10/25/02 11:07:06 PM
|
Fsck Lynx. Don't hold the other 99.9% hostage
________________
oop.ismad.com
|
Post #54,158
10/1/02 2:09:45 AM
|
I got your coordinates right here
<input type="text" style="position: absolute; left: 100px; top: 60px; width:100px; height:20px" />
--
Chris Altmann
|
Post #55,002
10/5/02 12:50:23 AM
10/5/02 12:51:34 AM
|
re: I got your coordinates right here
That is a start, but there is still the whole event-handling and "session persistence/redraw" issue.
Rather than rekindle that battle all over again, here are links to my side of the story: [link|http://geocities.com/tablizer/webstif.htm|[link|http://geocities.com/tablizer/webstif.htm|http://geocities.co.../webstif.htm]] and [link|http://geocities.com/tablizer/scghist.htm| [link|http://geocities.com/tablizer/scghist.htm|http://geocities.co.../scghist.htm]]
________________
oop.ismad.com
Edited by tablizer
Oct. 5, 2002, 12:51:34 AM EDT
|
Post #55,032
10/5/02 3:31:39 AM
|
re: I got your coordinates right here
There is a fourth approach: store the view state in hidden, compressed HTML form fields to be re-loaded into RAM on the next pass. The problem with this approach is that we cannot easily "interrupt" one form or screen with another, and then come back. Therefore, I will not discuss it any further.
Too bad you dismiss this approach because up until this point you were describing the ASP.NET model almost exactly. Yes I realize your objections to having to pass viewstate back and forth, but the meat of your article was how to make the best of the web situation. If you are worried about interrupting a form, you could open the new form in a separate window (like most traditional VB apps would), then use client side scripting to trigger a refresh in the original form if needed. Some people seem to also be storing the (hidden form field) viewstate in a (server side) session variable for later use. I suppose you could store it in a table too :) PS. Have you ever looked at XUL from the Mozilla project? Not what you looking for either (It also uses JS+DOM, but at a higher level of GUI abstraction), but it could be a platform on which to build your ideas. You could make your own SCGUIzed Mozilla based browser. --
Chris Altmann
|
Post #55,083
10/5/02 6:18:47 PM
|
why on the client?
If you are worried about interrupting a form, you could open the new form in a separate window (like most traditional VB apps would), then use client side scripting to trigger a refresh....
If you are going to depend on client-side scripting, which is often buggy, version-sensative, and inconsistent, then you might as well go with an applet-type approach. That would be better than JavaScript+DOM imo if it was not so bloated. JavaScript+DOM is a "medium client", not fat, but medium; plus it is a sloppy addon to the HTML model instead of built for GUI's up front.
Better to just byte the bullet and store the "state" or "UI image" on the server rather than the client IMO. It makes things conceptually far simpler.
PS. Have you ever looked at XUL from the Mozilla project?
I may have. It sounds familiar, but from a while ago. I have not been playing with SCGUI much lately.
B-to-B stuff just needs better, simpler HTTP-friendly GUI protocols. Nobody seems to want to directly solve this, living with kludgey hackey approaches instead and worrying about performance instead of programmer productivity, which is usually the more important thing for B-to-B. They assume everybody is ebay.
Thanx for the feedback, -T-
________________
oop.ismad.com
|
