SimpleWebKit

From GNUstepWiki

(Difference between revisions)
Revision as of 15:25, 30 March 2007
Hns (Talk | contribs)

← Previous diff
Revision as of 15:30, 30 March 2007
Hns (Talk | contribs)

Next diff →
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
-Here some features of the current version:+== 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>
-Here some first screen shots (made by linking against Apple AppKit&Foundation)+== 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

Contents

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)

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