Good god, get a JS display component framework. I haven't cared what browser / device / resolution anybody is using in years. I like Ext-JS, but there are plenty of others just as good.
Well put, and hits on why I like doing OO design. More than any other style of programming it feels like creating proofs in a system of formal reasoning, and consequently gives a lot more ongoing feedback as to the sound-ness of your design when those proofs are validated. It also points out how flawed your thinking is when it cannot be made consistent within the rules of the system. I feel like this is why so many people hate OO actually - I see a lot of devs get whiny because they think 'anything that works is OK'. May be fine for small, isolated projects, but when you are dealing with a whole ecosystem of re-usable modules that can be recombined in any number of ways, internal consistency is just as important as 'my concrete thingy passes the unit test'.
you need somebody in between, who really understands the appropriate design patterns, and who also knows how to write the code, so he/she can command respect (and offer guidance) to the developers. "Architect" might be the word I'm looking for.
"Asshole" I think is the word the sales guys and junior devs have in mind, but somebody's gotta do it.
Actually, you know the number of times in my career any existing project has switched databases? Zero times.
That's funny, because I deliver the same platform to different customer sites on Oracle, SQL Server, Postgres and sometimes even HSQLDB. Here we go again with the 'I've never needed it so it's dumb and useless' routine.
The actually important thing for businesses is the payload data in the database.
No, the important thing for businesses is whatever the important thing is for that business. Sometimes that is consistency of internal IT infrastructure and wanting to colocate applications in their existing RDBMS platform.
The entire data and validation stuff should be in the database. It's not a key-value store and it's not the 60's.
I can't even parse that sentence in such a way that it would constitute an argument. You've never written code that needed to be portable and/or unit testable independent of an external RDBMS - good for you I guess?
If you insist on doing the complicated thing then look up distributed transactions.
I use them all the time. Not sure what it has to do with the topic being discussed.
Haha, never heard that one. Far more appropriate, although I still don't get people's beef with well-factored OO code. As far as I can tell everybody just reacts to either the readability aspect (there is plenty of IDE tooling for making class/interface hierarchies easy to understand, and FFS it's not meant for linear scripting, people) or the time they got some evangelist nutjob on the team who jammed OO where it didn't need to be (not exactly the language's fault). There is a difference between a bad tool and a frequently mis-handled tool.
I love abstraction - distilling logic so that it can be promoted up a level, be consistent with the API and instantly empower everything downstream in the hierarchy...it's like getting a 4 row wipeout in Tetris. In terms of nerd fun, for me it's right up there with crunching on high-performance algorithms - I don't get why people shit on it so much here. I mean if your project doesn't call for OO then don't use it, but disparaging it without context just seems silly.
separating re-usable "business logic" from the vendor-specific language of your data repository
ftfy, make more sense now? Not everybody delivers (or stays) on the same RDBMS all the time. Not to mention how miserable it is to debug programs that live half in the middle tier and half in triggers. Or better yet, autonomous transactions in triggers - aren't those fun? You may want to look into interception frameworks.
Funny how you seem to think that the most important detail of a shooting story is the person's race, as if that means something in terms of condemning/exonerating persons of that/other races. Any apparent media agenda in this department is a direct result of the painfully obvious agendas carried by you and all the other people frothing at the mouth looking to spin every story of evil deeds in such a way as to excuse yourself from all responsibility, concern or need for reflection because one of the 'others' did it. This 'fucking mess' is one of your own making.
A company operating a website whose code is otherwise proprietary is unlikely to be willing to release
Another 5 seconds on Google turns up 10 free JS libraries for managing local storage, which if you recall was option 1. You are the one who ignored that and went straight to option 2 to complain about how impractical it is, when it is in fact your only remaining option after option 1, which is moot, because option 1 is completely practical.
And this still leaves open the question of how to handle users who do not use JavaScript at all.
Everything I deliver is scrutinized for dependency usage, scanned for vulnerabilities and interrogated for sound architecture by some very anal retentive folks implementing some very extensive security standards. The software is then deployed into some very secure physical sites to be used on their very locked down workstations. In all of this, I have never heard anybody ask for a web UI with JS turned off. I suppose I will cross that bridge when I get there, but I get the feeling you are just being willfully obstinate in posing this as a refutation of the idea that a web page is capable of managing its own state.
Attending the Sarah Palin school of rhetoric I see?
Funny, cars have come a long way in 50 years, but turn signals still work
Let's test that logic in a far more appropriate analogy:
"Funny, web pages have come a long way in 10 years, but 10 year old browsers still work"
This is what you are actually trying to say. Sounds a bit 'lame and quite silly', no? If you'd care to address the actual meat of the comment (the part where you will need to actually understand how web 2.0+ works), by all means please let me know how Opera manages to populate dynamic form fields that do not yet physically exist. Why don't you give it a try right here on/., where the comment field does not exist until you click 'reply'. Write your comment, click 'back', click 'forward' and then click 'submit' (because your comment is still there, right?)
tl;dr Look at the bottom. We are actually agreeing with each other.
As for an active page you can't close causing problems, as we're only keeping it alive for a brief period (I'd say about a minute) to allow a quick 'forward' to save you from an accidental 'back', it wouldn't be a problem for very long.
'Very long' in this context is highly subjective.
As the problem here is accidental back navigation, and the backspace key is very rarely used to move back, a more satisfying solution to this is to only save the page if the backspace key is used to navigate back.
I actually think this is an interesting problem independent of backspace, so removing it doesn to make the issue moot. Accidental navigation can still happen many other ways (my cat is very skilled at hitting the nav buttons on my mouse).
As it's only a problem if the user has entered information in to a form, you could also only save the page this way if form data has been entered.
Not quite. Many pages that have had overeager UX inflicted upon them have 'stages' of data entry where the form controls for an initial entry are gone now, and you cannot properly detect/restore the overall state of data entry by simply monitoring.form fields.
That is, prompt to confirm back navigation if data has been entered in to a form field.
Now we are in agreement. This is what I do in my web UIs. If you scroll up a ways through this post, you will see that this all started because that was my simpler solution and I was objecting to somebody calling browser developers idiots for not undertaking the Rube Goldberg contraption approach when such a simple solution was available. Now we are just having some fun tinkering with the Rube Goldberg idea, but I think it is silly to expect this to be a built-in browser feature that works flawlessly when there is such a simpler bottom-up approach exists.
How does the page save the state if the user or the user's network is blocking JavaScript as a security measure?
Well it's not, is it? As you said, it's blocking the set of JavaScript libraries not released under a free software license. Surely, within that set of JavaScript libraries, there is one for managing local storage? You make it sound like they are literally blocking the execution or download of all JS, in which case I don't know how they expect to load any page made in the last 15 years.
Or, you could just follow the simple instructions that I found in 5 seconds of Googling on how to release your own JavaScript so that it will be accepted by LibreJS.
HTML5 local storage? I'm not sure what 'non-free' script means, but I'm pretty sure it does not preclude all use of HTML5 features, particularly this one designed for this exact purpose.
A tab is not just state. In modern pages, it is likely to be buzzing with JS calls and active AJAX requests. Not only are these things difficult to store as 'state', one of them is impossible because the other end of it is on the remote server. Web pages these days are very rarely WYSIWYG, they are generally built dynamically and rely on a bunch of non-static, non-serializable things to behave as intended. Anybody can store the current rendered markup, or even the memory state of the JS thread, but this still does not mean it will come back as intended
Sounds elegant, but problematic if you think about it. Is the JS engine thread for that page suspended? If not, you now have an active page that you cannot see or close (what if you navigated away to stop whatever the page was doing?). If it is suspended, then what about timer loops, active Ajax calls, time-sensitive cookies/session content on which the page depends? There is a high chance in today's fancypants websites that the resumption of that page will not go as planned.
Oh goody it fills in form fields. And when those fields do not exist when I go forward because they were created dynamically based on initial actions and/or context, which executed a bunch of JS / sent a bunch of AJAX requests to get the content for the rest of the page? Or, when the field elements have generated IDs? Or worse, when they don't, and the browser keeps thinking it remembers the field when it is an entirely different one?
Opera solved it 10 years ago
For the websites of 10 years ago. Bully for them. You may have noticed that websites look and act a little differently in today's age of hyperactive UX designers.
Oh great, so all I need to do is install programmable keyboards and/or key mapping software on the 2 laptops and 3 desktop I personally use, every terminal in the server lab and every team member workstation that I pair program on. Problem solved I guess, how silly of me.
Oh plenty, but what you are talking about is alert() loops. Those take place before the unload event, and they are their own pain in the ass. I like how they stretch the dialog off the screen though so you can't get at the 'stop this...' checkbox.
So you'll just let us know when you have solved this incredibly easy problem, then? It seems you know quite a bit about HTTP, HTML/5, JS, CSS, browsers and UI design. More than me obviously, because I cannot imagine just how the fuck you would store every form value, JS variable, DHTML element state, dynamically loaded resource and HTML5 local store content perfectly back to their original states. What do I know though, I'm just an idiot developer.
Keep your barren hellscape of a keyboard away from my development work. Backspace and Delete are not the same thing. Home and End are indispensable. Modifiers don't help, because Ctrl+Home and Ctrl+End are also indispensable, as are Ctrl+Shit+Home and Ctrl+Shit+End. Every time I have to pick the mouse up precious sub-threads of my train of thought are at risk. I would happily give up my Insert key, but I'm sure there is somebody who is editing hex in a monospace text editor who would sooner gut you than give theirs up.
Right, so then they can deal with the cries of horror as people discover that Chrome is saving what they enter in forms? That is not the browser's job, it is the page's (and server-side session's) job. It's easy to recognize people who have never built a UI before - whatever they personally want is so obviously the right thing to do and those developers just such idiots for not doing exactly what you want all the time.
Slashdot Mirror
*snicker*
Good god, get a JS display component framework. I haven't cared what browser / device / resolution anybody is using in years. I like Ext-JS, but there are plenty of others just as good.
you need somebody in between, who really understands the appropriate design patterns, and who also knows how to write the code, so he/she can command respect (and offer guidance) to the developers. "Architect" might be the word I'm looking for.
"Asshole" I think is the word the sales guys and junior devs have in mind, but somebody's gotta do it.
Actually, you know the number of times in my career any existing project has switched databases? Zero times.
That's funny, because I deliver the same platform to different customer sites on Oracle, SQL Server, Postgres and sometimes even HSQLDB. Here we go again with the 'I've never needed it so it's dumb and useless' routine.
The actually important thing for businesses is the payload data in the database.
No, the important thing for businesses is whatever the important thing is for that business. Sometimes that is consistency of internal IT infrastructure and wanting to colocate applications in their existing RDBMS platform.
The entire data and validation stuff should be in the database. It's not a key-value store and it's not the 60's.
I can't even parse that sentence in such a way that it would constitute an argument. You've never written code that needed to be portable and/or unit testable independent of an external RDBMS - good for you I guess?
If you insist on doing the complicated thing then look up distributed transactions.
I use them all the time. Not sure what it has to do with the topic being discussed.
Haha, never heard that one. Far more appropriate, although I still don't get people's beef with well-factored OO code. As far as I can tell everybody just reacts to either the readability aspect (there is plenty of IDE tooling for making class/interface hierarchies easy to understand, and FFS it's not meant for linear scripting, people) or the time they got some evangelist nutjob on the team who jammed OO where it didn't need to be (not exactly the language's fault). There is a difference between a bad tool and a frequently mis-handled tool.
I love abstraction - distilling logic so that it can be promoted up a level, be consistent with the API and instantly empower everything downstream in the hierarchy...it's like getting a 4 row wipeout in Tetris. In terms of nerd fun, for me it's right up there with crunching on high-performance algorithms - I don't get why people shit on it so much here. I mean if your project doesn't call for OO then don't use it, but disparaging it without context just seems silly.
I think maybe you are not clear on the meaning of 'spaghetti' vis a vis code.
separating re-usable "business logic" from the vendor-specific language of your data repository
ftfy, make more sense now? Not everybody delivers (or stays) on the same RDBMS all the time. Not to mention how miserable it is to debug programs that live half in the middle tier and half in triggers. Or better yet, autonomous transactions in triggers - aren't those fun? You may want to look into interception frameworks.
If you're going to be a semantics pedant, at least get it right. The root word 'phobia' means aversion, not fear.
Funny how you seem to think that the most important detail of a shooting story is the person's race, as if that means something in terms of condemning/exonerating persons of that/other races. Any apparent media agenda in this department is a direct result of the painfully obvious agendas carried by you and all the other people frothing at the mouth looking to spin every story of evil deeds in such a way as to excuse yourself from all responsibility, concern or need for reflection because one of the 'others' did it. This 'fucking mess' is one of your own making.
Crap. Meant to select 'Insightful'. Sorry 'bout that. A 'confirm' button would be nice.
Poorly designed programs respond to overloads by slowing down, running out of stack space and crashing.
FTFY
A company operating a website whose code is otherwise proprietary is unlikely to be willing to release
Another 5 seconds on Google turns up 10 free JS libraries for managing local storage, which if you recall was option 1. You are the one who ignored that and went straight to option 2 to complain about how impractical it is, when it is in fact your only remaining option after option 1, which is moot, because option 1 is completely practical.
And this still leaves open the question of how to handle users who do not use JavaScript at all.
Everything I deliver is scrutinized for dependency usage, scanned for vulnerabilities and interrogated for sound architecture by some very anal retentive folks implementing some very extensive security standards. The software is then deployed into some very secure physical sites to be used on their very locked down workstations. In all of this, I have never heard anybody ask for a web UI with JS turned off. I suppose I will cross that bridge when I get there, but I get the feeling you are just being willfully obstinate in posing this as a refutation of the idea that a web page is capable of managing its own state.
You know, I've never used Opera so I got curious and just tried it out. Wonder of wonders, it didn't fucking work.
Funny, cars have come a long way in 50 years, but turn signals still work
Let's test that logic in a far more appropriate analogy:
"Funny, web pages have come a long way in 10 years, but 10 year old browsers still work"
This is what you are actually trying to say. Sounds a bit 'lame and quite silly', no? If you'd care to address the actual meat of the comment (the part where you will need to actually understand how web 2.0+ works), by all means please let me know how Opera manages to populate dynamic form fields that do not yet physically exist. Why don't you give it a try right here on /., where the comment field does not exist until you click 'reply'. Write your comment, click 'back', click 'forward' and then click 'submit' (because your comment is still there, right?)
As for an active page you can't close causing problems, as we're only keeping it alive for a brief period (I'd say about a minute) to allow a quick 'forward' to save you from an accidental 'back', it wouldn't be a problem for very long.
'Very long' in this context is highly subjective.
As the problem here is accidental back navigation, and the backspace key is very rarely used to move back, a more satisfying solution to this is to only save the page if the backspace key is used to navigate back.
I actually think this is an interesting problem independent of backspace, so removing it doesn to make the issue moot. Accidental navigation can still happen many other ways (my cat is very skilled at hitting the nav buttons on my mouse).
As it's only a problem if the user has entered information in to a form, you could also only save the page this way if form data has been entered.
Not quite. Many pages that have had overeager UX inflicted upon them have 'stages' of data entry where the form controls for an initial entry are gone now, and you cannot properly detect/restore the overall state of data entry by simply monitoring.form fields.
That is, prompt to confirm back navigation if data has been entered in to a form field.
Now we are in agreement. This is what I do in my web UIs. If you scroll up a ways through this post, you will see that this all started because that was my simpler solution and I was objecting to somebody calling browser developers idiots for not undertaking the Rube Goldberg contraption approach when such a simple solution was available. Now we are just having some fun tinkering with the Rube Goldberg idea, but I think it is silly to expect this to be a built-in browser feature that works flawlessly when there is such a simpler bottom-up approach exists.
How does the page save the state if the user or the user's network is blocking JavaScript as a security measure?
Well it's not, is it? As you said, it's blocking the set of JavaScript libraries not released under a free software license. Surely, within that set of JavaScript libraries, there is one for managing local storage? You make it sound like they are literally blocking the execution or download of all JS, in which case I don't know how they expect to load any page made in the last 15 years.
Or, you could just follow the simple instructions that I found in 5 seconds of Googling on how to release your own JavaScript so that it will be accepted by LibreJS.
HTML5 local storage? I'm not sure what 'non-free' script means, but I'm pretty sure it does not preclude all use of HTML5 features, particularly this one designed for this exact purpose.
A tab is not just state. In modern pages, it is likely to be buzzing with JS calls and active AJAX requests. Not only are these things difficult to store as 'state', one of them is impossible because the other end of it is on the remote server. Web pages these days are very rarely WYSIWYG, they are generally built dynamically and rely on a bunch of non-static, non-serializable things to behave as intended. Anybody can store the current rendered markup, or even the memory state of the JS thread, but this still does not mean it will come back as intended
Sounds elegant, but problematic if you think about it. Is the JS engine thread for that page suspended? If not, you now have an active page that you cannot see or close (what if you navigated away to stop whatever the page was doing?). If it is suspended, then what about timer loops, active Ajax calls, time-sensitive cookies /session content on which the page depends? There is a high chance in today's fancypants websites that the resumption of that page will not go as planned.
Opera solved it 10 years ago
For the websites of 10 years ago. Bully for them. You may have noticed that websites look and act a little differently in today's age of hyperactive UX designers.
Oh great, so all I need to do is install programmable keyboards and/or key mapping software on the 2 laptops and 3 desktop I personally use, every terminal in the server lab and every team member workstation that I pair program on. Problem solved I guess, how silly of me.
Oh plenty, but what you are talking about is alert() loops. Those take place before the unload event, and they are their own pain in the ass. I like how they stretch the dialog off the screen though so you can't get at the 'stop this...' checkbox.
Fucking idiot web browser developers
So you'll just let us know when you have solved this incredibly easy problem, then? It seems you know quite a bit about HTTP, HTML/5, JS, CSS, browsers and UI design. More than me obviously, because I cannot imagine just how the fuck you would store every form value, JS variable, DHTML element state, dynamically loaded resource and HTML5 local store content perfectly back to their original states. What do I know though, I'm just an idiot developer.
Keep your barren hellscape of a keyboard away from my development work. Backspace and Delete are not the same thing. Home and End are indispensable. Modifiers don't help, because Ctrl+Home and Ctrl+End are also indispensable, as are Ctrl+Shit+Home and Ctrl+Shit+End. Every time I have to pick the mouse up precious sub-threads of my train of thought are at risk. I would happily give up my Insert key, but I'm sure there is somebody who is editing hex in a monospace text editor who would sooner gut you than give theirs up.
Right, so then they can deal with the cries of horror as people discover that Chrome is saving what they enter in forms? That is not the browser's job, it is the page's (and server-side session's) job. It's easy to recognize people who have never built a UI before - whatever they personally want is so obviously the right thing to do and those developers just such idiots for not doing exactly what you want all the time.