|
Eye Of The Day[^]
(Just to please Marco Bertschi[^])
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
You look better today!
speramus in juniperus
|
|
|
|
|
I can't comment on this. At least without having my account closed.
Clean-up crew needed, grammar spill... - Nagy Vilmos
|
|
|
|
|
And here I thought this to be your real eye[+]
Loading signature...
. . . Please Wait . . .
|
|
|
|
|
Eye see what you mean.
|
|
|
|
|
Eye see what you did there!
|
|
|
|
|
(Best pirrate voice) Eye did ye now lad?
|
|
|
|
|
Eye browsed by[^] this post, and eye had to leaf.
Clean-up crew needed, grammar spill... - Nagy Vilmos
|
|
|
|
|
Eye'd ne careful with browse like that!
|
|
|
|
|
Nice to see you're finally getting the hang of using the blush along with the eyeliner, Griff. I'm sure you'll be a hit in the pasture tonight!
Will Rogers never met me.
|
|
|
|
|
It was the eyebrow plucking that took the time...
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
Unobtrusive Javascript is bad... OK, that should get the conversation started. To make it short, the proposition here is that you should bind events with code in an external file so that you can have purity of semantic coding is worse than a goto statement. A goto statement is at least a follow-able link. External binding is a fashion with no more benefit than any other fashion. I can buy that you should keep the majority of your javascript in external files, but putting the event binding externally, is to hide or at least obscure what the program flow and what the program is doing.
So, what do you think the upside and downside of putting your event bindings in the HTML? "Purity of code" is not going to impress me... any. I live in the trenches.
I expect some difference of opinion on this based on experience and role. I would expect that developers that have done a lot of trouble shooting and maintenance have a different opinion than those that write code that they do not have to maintain. You might mention this type experience when replying.
|
|
|
|
|
Member 7980583 wrote: Unobtrusive Javascript is bad - very bad!!!
However unobtrusive not only talks about separation, but also states that your page will work without that JavaScript present at all!
So, if you go unobtrusive , then you must separate JavaScript form HTML (and CSS)!
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)
modified 3-Feb-14 8:21am.
|
|
|
|
|
Ya know, you have an interesting point. I have written web apps with noscript capability. I understand the principles, but how often are you going to do that? Some security contexts might need to have javascript turned off, but most of the time, I would be inclined to just say too bad. Isn't the web about HTML5, javascript and responsive CSS? I cannot see working within that restricted environment. Sorry Charlie, but I write web sites that are too high performance to work without javascript. It's like telling me that we need a ditch dug, but you have to use your hands rather than a shovel.
|
|
|
|
|
I have some project - military/police related - where the absence of JavaScript is a demand...
Very annoying...
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)
|
|
|
|
|
I have done pages that had to work without javascript and it is not that the javascript can't be in the page, it is that the page can function without it. The funny thing about using the "noscript" tag (so to speak) is that you shouldn't need it. You get a lot of things that are submits instead of javascript actions, but they become javascript actions if the javascript works to make them so. Really nasty.
|
|
|
|
|
What Me Worry?
I do what needs to be done - move things around when it seems sensible and keep them together when it doesn't.
Aside from my personal JavaScript libraries (=generally useful functions), if a file is too big, move out the excess, and if not, and everything fits nicely in a small and readable file, then leave it there.
A lot of how this is done (size and selection) is personal taste on how the logic flows and the reader (particularly yourself) visualizes.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "As far as we know, our computer has never had an undetected error." - Weisert | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Consider the element id to be the Goto label.
BTW how is declaring the events in the element going to help you?
You can search for the event function or for the elementID.click. I don't really see the big difference.
modified 20-Oct-19 21:02pm.
|
|
|
|
|
"You can search" ... That's the difference. So do you search on every id in the page to see if something has been attached somewhere? It might have been attached by class even or heaven forbid, by element. It is a waste of time in any case.
"Consider the element id to be the Goto label." ... It might be or might not be, usually it is not one. You have to investigate to find out. Makes maintenance more difficult, but I still haven't heard any advantage. yet. Remember, typically the cost of maintenance of an application is higher than the development. That will just raise the time/cost of maintenance as well as hide the functionality.
|
|
|
|
|
Well, badly written applications usually do obscure functionality. So you suggest to declare the events within the elements?
How about properties, is CSS also hindering maintenance?
modified 20-Oct-19 21:02pm.
|
|
|
|
|
I am less of an expert at CSS to feel like offering an opinion, but thinking about it, I have thought that putting location information where the element is as part of the element might be appropriate. I do complicated stuff where adjusting the location by pixel distances is important sometimes. That would not be document wide whereas say font or other appearance styling would be. So put appearance styling in a CSS file, but perhaps element location information in the style of the element.
|
|
|
|
|
How about, you write a Javascript object for form validation that can be reused for different forms?
I'm actually playing around with such a thing.
Or a menu object that can be configured with a JSON object for different purposes?
You cannot know in advance what elements will be hooked up with the events
But otherwise, yeah, going through thousands of lines of badly written code is a pain.
However it is hardly the unobtrusive Javascript to blame.
modified 20-Oct-19 21:02pm.
|
|
|
|
|
Validation is something that should be generalized and probably from a library. Both should be in an external file, the attachment though should be at the element that is to be validated (IMO).
If you are sending JSON for configuration or data, then it is javascript that is doing the responding. The element might request the information, but the element cannot (normally) read JSON. The JSON may setup the event, but by then you had better be keeping track of what you are doing. Really, you point to the larger sphere of this issue. When you attach an event at an element, you are actually placing meta data - "when this type event happens, do this". So instead of specifically saying that "a javascript event should be attached where the element is declared", it should be "there should be meta data at the element describing that an event of such type is attached here and will so something like this". It is also known as documentation or self-documentation, the mark of a professional programmer.
Once you are doing configuration with JSON it is your responsibility to let the maintenance developer know what you had in mind... and something about what is expected from the server... another goto blind situation.
|
|
|
|
|
Once you are doing configuration with JSON it is your responsibility to let the maintenance developer know what you had in mind
^I agree with that
modified 20-Oct-19 21:02pm.
|
|
|
|
|
Member 7980583 wrote: "Purity of code" is not going to impress me... any. I live in the trenches.
I certainly hope that this statement doesn't lump in everyone else who plays a role in product sustaining as a software developer. Just because you have made the code more readable for you does not mean you have improved it.
Member 7980583 wrote: So, what do you think the upside and downside of putting your event bindings in the HTML?
Simply put the answer is performance.
The upside is that you improve the performance of your web page and the downside is that by not doing so you degrade it's performance.
The less that you clutter your page means the faster that it loads. By moving your CSS and javascript content into a separate file that lowers the content of the page that the browser must load. Thus you get an improvement in performance.
This becomes even more of a fact when you take into consideration the simple fact that the browser will cache javascript and css files. so that file where all of your javascript exists... well it's already loaded and the browser won't have to sacrifice a few hundred milliseconds for loading that content on each and every page.
I would recommend a reading of Steve Souder[^] and performance tuning your web site.
Member 7980583 wrote: I would expect that developers that have done a lot of trouble shooting and maintenance have a different opinion than those that write code that they do not have to maintain. You might mention this type experience when replying.
I have worked in both areas and personally took some offense to this statement. It is in my opinion best to question why things are done a certain way and hope to learn something as a skill building experience in furthering and enhancing your abilities. However, this statement comes across as almost to say that one group knows better or more than the other??
Member 7980583 wrote: "Purity of code"
You could say purity of code but you could also say purity of using the design pattern being modeled. In this case since we are talking about MVC and assuring that code from either M, V or C doesn't get co-mingled with the other. This generally helps in code maintenance..
you want something inspirational??
|
|
|
|