Difference between revisions of "SimpleWebKit"
Jump to navigation
Jump to search
| Line 1: | Line 1: | ||
| − | SimpleWebKit | + | === SimpleWebKit === |
Here some first items (for further editing) | Here some first items (for further editing) | ||
| Line 6: | Line 6: | ||
* aims at providing the most popular methods of Full WebKit for the classes WebView, WebFrame, WebDataSource, etc. | * aims at providing the most popular methods of Full WebKit for the classes WebView, WebFrame, WebDataSource, etc. | ||
* aims at rendering (X)HTML as good as possible | * aims at rendering (X)HTML as good as possible | ||
| + | * is work in heavy progress - so expect larger changes throughout the whole project | ||
| − | + | == Status == | |
| + | |||
| + | Features of the code in SVN trunk: | ||
* parses (X)HTML into a DOM tree | * parses (X)HTML into a DOM tree | ||
| − | * renders approx. 50% of the HTML 4.0 tags in a reasonable way (e.g. <font color="#667788"> works) | + | * renders approx. 50% of the HTML 4.0 tags in a reasonable way (e.g. < font color="#667788"> works) |
* makes <a> links clickable and processes them | * makes <a> links clickable and processes them | ||
* is prepared to load <img>, <script> etc. and already loads them as subresources | * is prepared to load <img>, <script> etc. and already loads them as subresources | ||
| Line 18: | Line 21: | ||
Missing: | Missing: | ||
* really display <img> tags | * really display <img> tags | ||
| − | * handle <table>, <ul> etc. | + | * handle < table>, < ul> etc. |
* properly merge <script> | * properly merge <script> | ||
* completion of ECMAScript engine | * completion of ECMAScript engine | ||
* any CSS and <style> | * any CSS and <style> | ||
| − | + | == Screenshots == | |
| + | |||
| + | Some first screen shots (made by linking against Apple AppKit&Foundation) | ||
[[Image:SimpleWebKit_Example_1.png]] | [[Image:SimpleWebKit_Example_1.png]] | ||
| + | |||
| + | == How it Works == | ||
| + | |||
| + | 1. the WebView | ||
| + | * is the master view object and there is only one per browser (or browser tab) | ||
| + | * it holds the mainFrame which represents either the normal <body> or the top level <frame> or <frameset> | ||
| + | * if there is a <frameset> hierarchy, there are additional child WebFrames | ||
| + | |||
| + | 2. the WebFrame | ||
| + | * is repsonsible for loading and rendering content from a specific URL | ||
| + | * it uses a WebDataSource to trigger loading and get callbacks | ||
| + | * it is also the owner of the DOMDocument tree | ||
| + | * JavaScript statements are evaluated in a frame context | ||
| + | * it is also the target of user clicks on links since it knows the base URL (through the WebDataSource) | ||
| + | |||
| + | 3. the WebDataSource | ||
| + | * is responsible for loading data from an URL | ||
| + | * it may cache data and handle/synchronize loading fo subresources (e.g. for an embedded <img> tag) | ||
| + | * it translates the request and the response URLs | ||
| + | * it provides an estimated content length (for a progress indicator) and the MIMEType of the incoming data stream | ||
| + | * as soon as the header comes in a WebDocomentRepresentation is created and incoming segments are notified | ||
| + | * it also collects the incoming data, so that a WebDocomentRepresentation can handle either segments or the collected data | ||
| + | |||
| + | 4. the WebDocumentRepresentation(s) | ||
| + | * there is one for each MIME type (the WebView provides a mapping database) | ||
| + | * it is responsible for parsing the incoming data stream (either completely when finished, or partially) | ||
| + | * and provide a better suitable representation, e.g. an NSImage or a DOMHTMLTree | ||
| + | * finally, it creates a WebDocumentView as the child of the WebView and attaches it to the WebFrame as the -webFrameView | ||
| + | * so, if you want to handle an additional MIME type, write a class that conforms to the WebDocumentRepresentation protocol | ||
| + | |||
| + | 5. the DOMHTMLTree | ||
| + | * is only for HTML content | ||
| + | * is (re)built each time a new segment of HTML data comes in | ||
| + | * any change in the DOMHTMLTree is notified to the WebDocumentView (or one of its subviews) by setNeedsLayout | ||
| + | |||
| + | 6. the WebDocumentView(s) an its subviews | ||
| + | * are responsible for displaying the contents of its WebDataRepresentation | ||
| + | * either HTML, Images, PDF or whatever (e.g. SVG, XML, ...) | ||
| + | * they gets notified about changes either by updates of the WebDataSource (-dadaSourceUpdated:) or directly (-setNeedsLayout:) | ||
| + | * if one needs layout, it must go to the DOM Tree to find out what has changed and update its size, content, children, layout etc. | ||
| + | * this is a little tricky/risky since the -layout method is called within -drawRect: - so changing e.g. the View frame is very critical and may result in drawing glitches | ||
| + | * for HTML, we do a simple trick: the WebDocumentView is an NSTextView and the DOMHTMLTree objects can be traversed to return an attributedString with embedded Tables and NSTextAttachments | ||
| + | |||
| + | 7. the JavaScript engine | ||
| + | * is programmed according to the specificaion of ECMA-262 | ||
| + | * uses a simple recursive stateless parser (could be optimized in stack useage and speed by a state-table driven approach) | ||
| + | * parses the script into a Tree representation in a first step | ||
| + | * then, evaluates the expressions and statements according to the current environement | ||
| + | * this allows to store scripts in translated form and reevaluate them when needed (e.g. on mouse events) | ||
| + | * uses Foundation for basic types (string, number, boolean, null) | ||
| + | * uses WebScriptObject as the base Object representation | ||
| + | * DOMObjects are a subclass of WebScriptObjects and therefore provide bridging, so that changing a DOMHTML tree element through JavaScript automativally triggers the appropriate WebDocumentView notification | ||
Revision as of 15:30, 30 March 2007
SimpleWebKit
Here some first items (for further editing)
- originated in mySTEP
- is completely written in Objective-C (1.0)
- aims at providing the most popular methods of Full WebKit for the classes WebView, WebFrame, WebDataSource, etc.
- aims at rendering (X)HTML as good as possible
- is work in heavy progress - so expect larger changes throughout the whole project
Status
Features of the code in SVN trunk:
- parses (X)HTML into a DOM tree
- renders approx. 50% of the HTML 4.0 tags in a reasonable way (e.g. < font color="#667788"> works)
- makes <a> links clickable and processes them
- is prepared to load <img>, <script> etc. and already loads them as subresources
- is prepared to handle <frame>
- is prepared to handle <form>
- has a ECMAScript engine that parses 90% of the syntax and evaluates expressions (missing are Statements and the native Objects incl. "document", "window", "event" etc.)
Missing:
- really display <img> tags
- handle < table>, < ul> etc.
- properly merge <script>
- completion of ECMAScript engine
- any CSS and <style>
Screenshots
Some first screen shots (made by linking against Apple AppKit&Foundation)
File:SimpleWebKit Example 1.png
How it Works
1. the WebView
- is the master view object and there is only one per browser (or browser tab)
- it holds the mainFrame which represents either the normal <body> or the top level <frame> or <frameset>
- if there is a <frameset> hierarchy, there are additional child WebFrames
2. the WebFrame
- is repsonsible for loading and rendering content from a specific URL
- it uses a WebDataSource to trigger loading and get callbacks
- it is also the owner of the DOMDocument tree
- JavaScript statements are evaluated in a frame context
- it is also the target of user clicks on links since it knows the base URL (through the WebDataSource)
3. the WebDataSource
- is responsible for loading data from an URL
- it may cache data and handle/synchronize loading fo subresources (e.g. for an embedded <img> tag)
- it translates the request and the response URLs
- it provides an estimated content length (for a progress indicator) and the MIMEType of the incoming data stream
- as soon as the header comes in a WebDocomentRepresentation is created and incoming segments are notified
- it also collects the incoming data, so that a WebDocomentRepresentation can handle either segments or the collected data
4. the WebDocumentRepresentation(s)
- there is one for each MIME type (the WebView provides a mapping database)
- it is responsible for parsing the incoming data stream (either completely when finished, or partially)
- and provide a better suitable representation, e.g. an NSImage or a DOMHTMLTree
- finally, it creates a WebDocumentView as the child of the WebView and attaches it to the WebFrame as the -webFrameView
- so, if you want to handle an additional MIME type, write a class that conforms to the WebDocumentRepresentation protocol
5. the DOMHTMLTree
- is only for HTML content
- is (re)built each time a new segment of HTML data comes in
- any change in the DOMHTMLTree is notified to the WebDocumentView (or one of its subviews) by setNeedsLayout
6. the WebDocumentView(s) an its subviews
- are responsible for displaying the contents of its WebDataRepresentation
- either HTML, Images, PDF or whatever (e.g. SVG, XML, ...)
- they gets notified about changes either by updates of the WebDataSource (-dadaSourceUpdated:) or directly (-setNeedsLayout:)
- if one needs layout, it must go to the DOM Tree to find out what has changed and update its size, content, children, layout etc.
- this is a little tricky/risky since the -layout method is called within -drawRect: - so changing e.g. the View frame is very critical and may result in drawing glitches
- for HTML, we do a simple trick: the WebDocumentView is an NSTextView and the DOMHTMLTree objects can be traversed to return an attributedString with embedded Tables and NSTextAttachments
7. the JavaScript engine
- is programmed according to the specificaion of ECMA-262
- uses a simple recursive stateless parser (could be optimized in stack useage and speed by a state-table driven approach)
- parses the script into a Tree representation in a first step
- then, evaluates the expressions and statements according to the current environement
- this allows to store scripts in translated form and reevaluate them when needed (e.g. on mouse events)
- uses Foundation for basic types (string, number, boolean, null)
- uses WebScriptObject as the base Object representation
- DOMObjects are a subclass of WebScriptObjects and therefore provide bridging, so that changing a DOMHTML tree element through JavaScript automativally triggers the appropriate WebDocumentView notification