Conversion script: link fix

2006-01-22T02:33:21Z

link fix

← Older revision		Revision as of 02:33, 22 January 2006
Line 9:		Line 9:
	SPObjects are more efficient representations of the SVG data in a form convenient for quick updates; changes are often made here and periodically flushed back to the repr layer.		SPObjects are more efficient representations of the SVG data in a form convenient for quick updates; changes are often made here and periodically flushed back to the repr layer.

	SPObjects are also responsible for updating a number of NRArenaItems in their care.		SPObjects are also responsible for updating a number of [[NRArenaItems]] in their care.

	== NRArena ==		== NRArena ==

	Populated by NRArenaItems, these essentially represent an incremental-update rendering context.		Populated by [[NRArenaItems]], these essentially represent an incremental-update rendering context.

	= Change Propagation =		= Change Propagation =

	== SPItem to NRArenaItem ==		== SPItem to [[NRArenaItem]] ==

	Changes are typically first registered by internal methods, which change the SPObject and then call sp_object_request_modified() with flags indicating the type of changes that have taken place. The "modified" callbacks are responsible for updating basic state and propagating the flag changes elsewhere.		Changes are typically first registered by internal methods, which change the SPObject and then call sp_object_request_modified() with flags indicating the type of changes that have taken place. The "modified" callbacks are responsible for updating basic state and propagating the flag changes elsewhere.

	Later on, sp_object_request_update() is called, which calls the "update" signal -- it's the "update" handlers that are responsible for e.g. actually updating NRArenaItems and such. Usually (but not always) updates are done from the idle loop.		Later on, sp_object_request_update() is called, which calls the "update" signal -- it's the "update" handlers that are responsible for e.g. actually updating [[NRArenaItems]] and such. Usually (but not always) updates are done from the idle loop.

	== SPRepr to SPObject ==		== SPRepr to SPObject ==
Line 27:		Line 27:
	SPObject initially retrieves its state (e.g. after being created) from an SPRepr when the "build" signal is serviced; at this time it may create/request_build() its children also.		SPObject initially retrieves its state (e.g. after being created) from an SPRepr when the "build" signal is serviced; at this time it may create/request_build() its children also.

	The sp_object_invoke_build function, besides calling the object's build method, also attaches a listener to the source SPRepr (see ReprListeners) so that any changes to the repr that bypass its object (such as undo, which directly changes reprs, or changes done in XML editor) are caught and reflected in the object. This listener passes attribute and property changes to the "set" method, which dispatches them appropriately.		The sp_object_invoke_build function, besides calling the object's build method, also attaches a listener to the source SPRepr (see [[ReprListeners]]) so that any changes to the repr that bypass its object (such as undo, which directly changes reprs, or changes done in XML editor) are caught and reflected in the object. This listener passes attribute and property changes to the "set" method, which dispatches them appropriately.

	== SPStyle to NRArenaItem ==		== SPStyle to [[NRArenaItem]] ==

	Currently, the NRArenaItem holds a reference to the SPStyle directly (bad!), but ... the details of this are still a bit unclear to me. SPStyles have no callbacks to speak of; I think the process is driven by the callbacks on SPRepr attributes (both property attributes, and the "style" attribute).		Currently, the [[NRArenaItem]] holds a reference to the SPStyle directly (bad!), but ... the details of this are still a bit unclear to me. SPStyles have no callbacks to speak of; I think the process is driven by the callbacks on SPRepr attributes (both property attributes, and the "style" attribute).

	== SPObject to SPRepr ==		== SPObject to SPRepr ==

	To write state from an SPObject back into SPRepr form, request_write(); flags indicate how much data to flush back. The "write" handlers may create a new Repr if an existing one is not provided.		To write state from an SPObject back into SPRepr form, request_write(); flags indicate how much data to flush back. The "write" handlers may create a new Repr if an existing one is not provided.

Buliabyak: *

2004-02-21T02:41:23Z

New page

= Overview =

== SPRepr ==

SPReprs directly represent the (simplified) parse tree of the XML document.

== SPObject ==

SPObjects are more efficient representations of the SVG data in a form convenient for quick updates; changes are often made here and periodically flushed back to the repr layer.

SPObjects are also responsible for updating a number of NRArenaItems in their care.

== NRArena ==

Populated by NRArenaItems, these essentially represent an incremental-update rendering context.

= Change Propagation =

== SPItem to NRArenaItem ==

Changes are typically first registered by internal methods, which change the SPObject and then call sp_object_request_modified() with flags indicating the type of changes that have taken place. The "modified" callbacks are responsible for updating basic state and propagating the flag changes elsewhere.

Later on, sp_object_request_update() is called, which calls the "update" signal -- it's the "update" handlers that are responsible for e.g. actually updating NRArenaItems and such. Usually (but not always) updates are done from the idle loop.

== SPRepr to SPObject ==

SPObject initially retrieves its state (e.g. after being created) from an SPRepr when the "build" signal is serviced; at this time it may create/request_build() its children also.

The sp_object_invoke_build function, besides calling the object's build method, also attaches a listener to the source SPRepr (see ReprListeners) so that any changes to the repr that bypass its object (such as undo, which directly changes reprs, or changes done in XML editor) are caught and reflected in the object. This listener passes attribute and property changes to the "set" method, which dispatches them appropriately.

== SPStyle to NRArenaItem ==

Currently, the NRArenaItem holds a reference to the SPStyle directly (bad!), but ... the details of this are still a bit unclear to me. SPStyles have no callbacks to speak of; I think the process is driven by the callbacks on SPRepr attributes (both property attributes, and the "style" attribute).

== SPObject to SPRepr ==

To write state from an SPObject back into SPRepr form, request_write(); flags indicate how much data to flush back. The "write" handlers may create a new Repr if an existing one is not provided.

LegacyArchitecture - Revision history

Conversion script: link fix

Buliabyak: *