I recently encountered this on one of my project and I don't think I have the full understanding of this thing at all. The only thing I know are the following:
-That DOM prevents scripts that are loaded on blocking the rest of the page.
-Html files and other page source codes are parsed and turned into DOM, with which, when you inspect it or go to view page source, the DOM format of the code is what it will throw you.
-I was also able to implement DOM on our project through the help of a tutorial.
Now, my questions are:
-Is the code in the devtools the DOM?
-Does DOM adds security features on a system?
-Since DOM was widely implemented in the layout engines of the web browser, is there any other advantages of using DOM aside from it prevents possible blocking of the rest of the codes of the page?
Thanks guys.
The DOM (Document Object Model) is all about the code/object hierarchy within a given system/node. It is symbolic of the branches of an upside-down tree. It forces the different layers of code to always have a parent-child-sibling relationship.Any code inside another block of code is a child of the larger block. For html, the html tag is the parent of all other tags, followed by the head, then body tag. Most all displayed content is in the body section, with one division creating the main page you see. After the division tag you have the ul / li / p / a tags. Sometime the span tag is used as a wrapper for the 'a' or 'p' tags. The 'ul' tag is a child of the div tag it is in, and the 'li' and/or 'p' tag is a child of the 'ul' tag. Only the span tag varies in location when used, depending on its need to keep objects and/or text inline. The lowest possible child (or leaf in a node tree) is either a 'p' tag or an 'a' tag. No other tag can be used inside the 'a' tag. A sibling is referred as a tag or node of the same level in the tree, but in an adjacent div or ul or li tag. Their relationship is not defined normally, unless there is a need to do so. In summary, the DOM is used to insure order and readability in html / XML /SQL and other software systems. It does NOT guarantee good working code by itself, but it sure helps create efficient working code early in the design stage.Also, new coding functions are being employed that can bypass or modify the way the DOM behaves. Angularjs and MEAN, which includes a micro-server and node.js, are trying to turn a clients web page into a de-facto desktop application, such that the request to the server become as minimal as possible. These new functions do not contradict the DOM model, but act as a wrapper so action/editing/motion on a webpage appears instantly without having to contact the main server. During periods of no user action an update is sent to the main server, so the website and the PC stay in sync in terms of changes that are at least semi-permanent.Please read as much as you can about these topics, because every year something new is added.
Related
I have a query regarding CQ. Your reply will really make the difference to my understanding.
In other CMS like Vignette, content authors create the contents separately (not directly on the page) for ex. products details and then those contents are iterated / processed to display on the page. But in CQ, the scenario is other way round. Authors directly create the content on the page. Now if same content is needed on other page, how will that be re-used ?
Regards,
Ronak
Content can be reused across pages via Reference components. From the docs:
The Reference component lets you reference text in another part of a
CQ based website (within the current instance). The referenced
paragraph will then appear as if it was on the current page. Instead
of referencing a specific paragraph, the path can also be modified to
specify an entire [paragraph-system]...
There are some other techniques for sharing content and reference data across pages, including inheritance and "data components," described in this SO Q&A.
We are develpoing a web-based automation solution for a web application that is built using ExtJs.
Currently i am testing various different object identification techniques that identify web elements in the best way.
We'd like to use the IE developer tools (F12) to highlight and select DOM objects on the page, and (somehow) get their corresponding ExtJs component (along with its corresponding properties, such as itemId).
Is this possible to do through code or through some other technique?
I am unfamiliar with IE Dev tools for such things, however I can attempt to answer targeting specific components and their elements.
You can target Ext components via several ways:
Ext.ComponentQuery.query(CQselector) method (see docs for examples)
Ext.getCmp(componentID) if you know component ID
up() and down() methods from any container/component. these also take CQselector expressions
Any of these methods are accessible from the page since Ext library is loaded. In browsers like FF and Chrome you can execute these methods directly from the console. I am guessing similarly they should be available in IE Dev tools.
Once you have reference to the Ext component you can get HTML elements through .dom or .el or similar properties. Or you could use Dom query directly.
I believe that if you set the id property rather than the itemId, you can achieve the desired result as this is passed through as the html id property of the top level container for the component (I think!). It's a little complicated to get that to work with accuracy though given the amount of nested divs/tables that are used in most of the extjs components. Good luck!
Hard to tell what you're looking for, but if you're trying to get a reference to an Ext.Component that is rendered, you can look for the wrapper node for your component in the HTML structure. The HTML id is the same as the component id. If you run var comp = Ext.getCmp('some-id-12345') and if that returns something, you've found the wrapper for an Ext.Component.
You could then use
comp.itemId
To retrieve the itemId
You should look into http://www.illuminations-for-developers.com/ A plugin for firebug that shows Ext.Components.
You can also use the Sencha Page Analyzer to see the entire component tree
I am attempting to build a simple application using wicket and have been impressed so far. I have been taking advantage of the Component class to determine behavior of elements on the page based on user input or the model. I see the component model similarities with JSF, but find the wicket lifecycle easier to manage.
What i haven't been able to understand is having to add every component to the tree for every wicket:id mentioned on a page, especially for ones without any children. it seems heavy handed to have to build up the tree in java code when the tree has already been somewhat defined within the markup. what am i missing?
edit
I should probably give an example. I have a label for an input box that in some cases i want to be able to modify. 95% of the time the text and attributes i have for the label in markup will be fine.
Short answer: Yes, you have to add them.
Long answer: You can create custom code to do this, but I doubt it's worth the effort.
With JSF, you use a non-html tag, which has one component type associated to it - for example, h:inputText correspond to the class HtmlInputText -, so it knows what class to instantiate.
With Wicket, the HTML file contains only (with a few exceptions) HTML tags, and you have to instantiate a concrete component for each wicket:id-marked tag you add to the markup, because it can't know for sure if <span wicket:id='xyz'> means a Label, a FeedbackPanel, a WebMarkupContainer, or some custom component.
With JSF you do in the markup what, with Wicket, you do in Java code, that is, to build the component tree, bind components to properties, and handle events. It keeps everything in one file (you don't have to create a class for every template file), which has many, many cons (some may think it has some pros, I digress).
You page is never just a simple form that does nothing. You want to convert and validate the input, you want to process the submit, you want to update components using Ajax. With JSF, you do all that in the (non-compilable, type-unsafe, poorly tooled, non-refactorable) template, making it bloated with expressions, configuration tags, and - gawd forbid - business logic.
If Wicket had support for this (and, for the matter, it has the flexibility needed for you to build this add-on yourself), you would have to add lots of extra annotations (special, non-standard tags and attributes) to the markup, to declare what class to instantiate, what model to update, what validations to execute, etc., compromising two of the beauties of the framework, the clean HTML template, and the clear separation between visuals and logic.
One framework that tries to do more in the template, while remaining less bloated than JSF (which isn't that hard anyway) is Apache Tapestry. But as can be seen in its tutorial, you still end up having to use non-standard tags and following arbitrary conventions to bind the template to the code (you may like it, but if this is the case you have baaad taste, sorry :P).
I have a label for an input box that in some cases i want to be able to modify. 95% of the time the text and attributes i have for the label in markup will be fine.
You could try to wrap the content of the label in a Model, enclose that label in a container and repaint the container (target.add(container);).
Offcurse you should add them.One of the most powerful facilities of wicket is that allow you to make a reusable components espacially html components.
There are a million ways to build a house, but most people wouldn’t
consider building toilets, bathtubs, and glass windows from scratch.
Why build a toilet yourself when you can buy one for less money than
it would cost you to construct it, and when it’s unlikely you’ll
produce a better one than you can get in a shop? In the same fashion,
most software engineers try to reuse software modules. “Make or buy”
decisions encompass more than whether a module is available;
generally, reusing software modules is cheaper and leads to more
robust systems. Reusing software also means you don’t have to code the
same functionality over and over again.(wicket in action:manning)
So to have a reusable wicket pages, wicket just needs a html page to show it's components hierarchy or their positions. The types and model of these components left to programmer.
I often face a problem when I need to encapsulate some far apart fields in one form, and the fields in between them in other forms. Or encapsulating first two rows of a table in form and other two in other forms and so on. But of-course this is not allowed in standard practice. My question is why such tags like form (and other non displaying tags) have to be treated as "displaying" tags, and they also are restricted to be used at some places. Is there any genuine reason.
PS: what I was thinking about form in particular, that I define as many forms as I want at a single place, and give their references (eg ids or names) to the corresponding fields. That way form tag does not have to interfere somehow with the location of fields?
Asking "why" questions of HTML behaviour is not normally a useful activity. Very often the answer is "because one of the browsers originally did it that way and we're stuck with it for backward-compatibility reasons".
Note also what #DanMan says about the displayability of <form>.
However, your description of declaring forms in one place and then having the controls associate with the forms by id, is very similar to what has been done with the HTML5 form attribute. The only difference is that the controls reference the forms, rather than the forms referencing the controls. All we need to do now is wait for implementations in the browsers.
How is a <form> a non-displaying element? You can apply all kinds of CSS on it, and they will show up. It's just that they usually have no default browser styles. It's a rookie mistake to wrap elements in <div>s and styling those, when the only thing inside them is a single element.
<div class="myform"><form>...</form></div>
<form><div class="myform">...</div></form>
Both equally superfluous. Just style the original element directly.
<form class="myform">...</form>
Now, before you jump on my back: I'm not saying you're doing that. Just a general advice.
About restricted usage: that's probably to make it easier for implementors (browser creators) and for backwards compatibility.
I am beginner into HTML & HTML5.
As I was reading through the following link, i found the terms DOM and DOM API. I read through the Wikipedia, but was not able to digest the whole idea behind it.
Could somebody explain me :
the real idea behind the concept of Document Object Model (DOM)?
how is it related to HTML5?
Thanks,
Sen
From Wikipedia:
The Document Object Model (DOM) is a
cross-platform and
language-independent convention for
representing and interacting with
objects in HTML, XHTML and XML
documents
Simply put, it's how browsers (amongst other clients) represent web documents. The DOM is not specific to HTML5. It's been there from the get-go.
DOM API basically means how you, as a programmer, can interact with the DOM. Some examples might be adding elements to the DOM, changing their styles, and other common operations you would do on a web document.
In the context of HTML5, there are several additions to the DOM that didn't exist in previous versions of the HTML spec, such as <video> and <audio> elements.
The DOM is the browser's internal representation of the HTML document.
The DOM API is the way of programming the DOM, using JavaScript when in a browser.
HTML5 is just a new flavour of HTML. It uses the DOM in exactly the same way.
What Mark Pilgrim is saying is that there are certain things you can do with HTML5 DOM elements through the DOM API, such as start a video file playing. So, if you have a <video> DOM object in JavaScript, you can call its .play() method from JavaScript. This is an example of the DOM API.
The document object model is the browser's internal representation of HTML. It's based on the idea of 'children'. So a <p> tag might contain several text nodes and several <span> tags, like this:
<p><span>Hello,</span> this is some text. <span>It</span> is just a short paragraph</p>
This <p> tag has 4 children: two <span>s, and two text nodes (this is some text and is just a short paragraph). The other bits of text are children of their respective <span> tags.
The browser stores this information (instead of just storing a huge stream of HTML, which is very difficult to process) in its internal memory. This makes it much easier to format it using Cascading Style Sheets (CSS) and to make changes to it using JavaScript (create and delete parts, move parts from one parent to another, etc).
All versions of HTML (except perhaps very early ones) use the DOM. Each version has rules, such as which tags are valid, and which can be children to each element. These rules are implemented when processing the HTML and creating a DOM representation of it.
dom is the html representation of the programmed objects , each web page is a collection of DOM objects