Discussion on:
View:
Show:
I would like to draw your attention to an AJAX paradigm shift. One should be aware that I am not, and do not pretend to be objective. Visual WebGui is an open source rapid application development framework for graphic user interfaces of IT web applications. It replaces the obsolete paradigms of ASP.NET which were designed for developing sites, with WinForms methodologies, which were designed for developing applications. Thus enabling designer that was designed for application.This provides the developer with an extremely efficient way to design interfaces using drag and drop instead of hand coding HTML. VWG doesn?t expose logic, data or open services on client requests and therefore is not as vulnerable as common AJAX solution. Worth a look ? www.visualwebgui.com
It's yet another naff bodge for attempting to produce stateful applications using HTTP.
Ajax does what it does reasonable well, what it doesn't do is solve the real problem.
That would require a paradigm shift.
Ajax does what it does reasonable well, what it doesn't do is solve the real problem.
That would require a paradigm shift.
then no ajax, again disabling javascript itself is a sin!
code2dotnet.blogspot.com
code2dotnet.blogspot.com
If you have a filter on all incoming requests that forwards you to the login screen when the session has expired, this could pose a problem to Ajax requests.
Possible solution: Have a dialog box appear on the user's screen prior to session expiration. If the user does not respond, allow session to expire. Otherwise, refresh the session with an Ajax call.
Possible solution: Have a dialog box appear on the user's screen prior to session expiration. If the user does not respond, allow session to expire. Otherwise, refresh the session with an Ajax call.
number one deadly sin is USING JAVASCRIPT.
if the site doesn't function without it, then there is ZERO content worth anyone's time.
if the site doesn't function without it, then there is ZERO content worth anyone's time.
There's another option: just make sure the site still works, albeit less smoothly and less like a desktop app, without Javascript. Make sure the site degrades gracefully.
In other words, the Zeroth Deadly Sin should be:
Making Access Depend On Javascript
. . . or:
Making Usability Depend On AJAX
. . . or something along those lines.
In other words, the Zeroth Deadly Sin should be:
Making Access Depend On Javascript
. . . or:
Making Usability Depend On AJAX
. . . or something along those lines.
Anyone remember the days when near any page would load in Linx or Lynx (the later supporting tables)?
Yeah, I know.. everyone loves the GUI but sometimes you just want to load a freaking page to get a quick bit of info, whithout loading a GUI layer.
Yeah, I know.. everyone loves the GUI but sometimes you just want to load a freaking page to get a quick bit of info, whithout loading a GUI layer.
The World Wide Web is meant to support rich document formatting with images, backgrounds, et cetera. I prefer designing with XHTML and CSS over doing so with HTML 3.0, too. I've left the kind of functionality Lynx provides a long time ago.
On the other hand, browsers that provide the functionality I need also utterly fail to be reasonably well-designed. Even Firefox, my favorite browser, sucks. It simply sucks less than the alternatives.
One of these days, I may get around to creating a new web browser that is highly functional without having to be "feature rich" in the grand tradition of bloatware. In the meantime, however, I have another idea that occurred to me when I was thinking about the reasons Lynx doesn't do it for me any longer.
I think we need a second form of browser, in addition to the web browser, for accessing hyperlinked documents on the Internet. Such a thing could be interoperable with webpages, so long as those webpages are designed to make use of a well-formatted text document inserted into the page by server-side scripts. Then, a metadata page for use with this other document browser application could also be placed, which would provide information like related links. That metadata page could then be used to populate links on the webpage. Between the text document and the metadata page, a hyperlinked network of formatted text documents separate from the concerns of the rich content World Wide Web could coexist with it, without any redundant development effort, that would provide content sans gimmicky BS.
Maybe I should start working on that some time soon. I even have an idea for how I could make such a thing actually "catch on" with people.
On the other hand, browsers that provide the functionality I need also utterly fail to be reasonably well-designed. Even Firefox, my favorite browser, sucks. It simply sucks less than the alternatives.
One of these days, I may get around to creating a new web browser that is highly functional without having to be "feature rich" in the grand tradition of bloatware. In the meantime, however, I have another idea that occurred to me when I was thinking about the reasons Lynx doesn't do it for me any longer.
I think we need a second form of browser, in addition to the web browser, for accessing hyperlinked documents on the Internet. Such a thing could be interoperable with webpages, so long as those webpages are designed to make use of a well-formatted text document inserted into the page by server-side scripts. Then, a metadata page for use with this other document browser application could also be placed, which would provide information like related links. That metadata page could then be used to populate links on the webpage. Between the text document and the metadata page, a hyperlinked network of formatted text documents separate from the concerns of the rich content World Wide Web could coexist with it, without any redundant development effort, that would provide content sans gimmicky BS.
Maybe I should start working on that some time soon. I even have an idea for how I could make such a thing actually "catch on" with people.
Are you talking about a dynamic document or a static one. Could a .pdf document provide you with both the rich text information and links?
Just a thought.
Just a thought.
I'm not talking about a rich text document with links like that. I'm talking about low-bandwidth plain text source files with rich text formatting, plus links. In other words, a Lynx-style interface that doesn't actually leave out the mass of functionality you'd get from visiting the same page in, say, Firefox.
Often too cluttered with Ad boxes and such but definately pretty. Browser accessed applications are one thing but a page such as techrepublic and other content pages should be developed to degrade gracefully all the way back to html 3.0.. The fancy stuff and pretty add-ons could be included through metadata and themes with a simple text based default for the near-dead browsers.
This could even be done in the same way that a framed page used to direct non-framing browsers to a single page while still presenting Netscape and IE with seporate pages in framed context.
Sometimes a cigar is just a cigar (george carlin) and sometimes a webpage is just a page of information rather than a challenge to see how convoluted the formatting can be.
Some pages have to contain those rich bells and whistles but there are so many pages where the content itself is simple and all you need to do is pop open a second text terminal and Lynx www.blah.com/page.thml instead of loading a bloated memory hog just to view a news article or technical spec sheet.
For efficiency of browsing, I've even tried that fiddly keyboard navigation plugin for Firefox but it simply eats the page formatting while adding a numeric tag to each link.
This could even be done in the same way that a framed page used to direct non-framing browsers to a single page while still presenting Netscape and IE with seporate pages in framed context.
Sometimes a cigar is just a cigar (george carlin) and sometimes a webpage is just a page of information rather than a challenge to see how convoluted the formatting can be.
Some pages have to contain those rich bells and whistles but there are so many pages where the content itself is simple and all you need to do is pop open a second text terminal and Lynx www.blah.com/page.thml instead of loading a bloated memory hog just to view a news article or technical spec sheet.
For efficiency of browsing, I've even tried that fiddly keyboard navigation plugin for Firefox but it simply eats the page formatting while adding a numeric tag to each link.
Now, I may be a bit unusual in this idea ... Shouldn't AJAX applications be a business function and not really a public consumption function?
I can control what browser is used and the settings of that browser if it is a business function, I cannot do so if it is a site designed for public use. I feel that most web-apps of this sort (business function) would be a replacement of existing desktop or legacy applications or the introduction of new applications for the associates of the firm. Therefore, the issue with the browser being either java-script compatible or enabled should never arise.
I can control what browser is used and the settings of that browser if it is a business function, I cannot do so if it is a site designed for public use. I feel that most web-apps of this sort (business function) would be a replacement of existing desktop or legacy applications or the introduction of new applications for the associates of the firm. Therefore, the issue with the browser being either java-script compatible or enabled should never arise.
is reduced installation/deployment issues.
Internally I don't see any security problem with using ajax / javascript, if you can lock javascript execution to your domain.
However it's no easier (in fact often harder to impossible) to write a rich web based app and a well written executable will out perform them every time. .NET has improved things but it's still stateless and that causes all sorts of design issues and inefficiencies.
There are situations where they are useful, coping with cross platform issues , or in widely spread business units as long as the apps are reasonably simple at the front end is an acceptable use of the technology. In my opinion it should be a last resort internally, not the more common oh look there's a bandwagon, lets jump under it, first choice.
Internally I don't see any security problem with using ajax / javascript, if you can lock javascript execution to your domain.
However it's no easier (in fact often harder to impossible) to write a rich web based app and a well written executable will out perform them every time. .NET has improved things but it's still stateless and that causes all sorts of design issues and inefficiencies.
There are situations where they are useful, coping with cross platform issues , or in widely spread business units as long as the apps are reasonably simple at the front end is an acceptable use of the technology. In my opinion it should be a last resort internally, not the more common oh look there's a bandwagon, lets jump under it, first choice.
You forgot the first element in the colleciton deadlySins[0]="Ajax". AJAX is an improper capitalization. Although an acronym, the originators would expect you to use the right case.
If you are working under. NET, there is a free library called PokeIn. No leak, no problem.. http://pokein.codeplex.com
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
