Added: incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/ThreadingSoln.html
URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/ThreadingSoln.html?rev=1206895&view=auto
==============================================================================
--- incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/ThreadingSoln.html (added)
+++ incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/ThreadingSoln.html Sun Nov 27 22:49:46 2011
@@ -0,0 +1,265 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+<head>
+ <title>Threading Solution</title>
+
+
+<meta HTTP-EQUIV="content-type" CONTENT="text/html; charset=UTF-8">
+</head>
+<body>
+
+<h2>Introduction</h2>
+ The goals of the threading solution research are: <br>
+
+<ul>
+ <li>To establish how threading currently works in OpenOffice</li>
+ <li>To investigate issues related to running multiple scripts simultaneously
+in OpenOffice</li>
+ <li>To suggest how IDEs would be able to attach to OpenOffice scripts
+ <br>
+ </li>
+
+</ul>
+
+<p> <a name="contents"></a> </p>
+
+<h2>Contents</h2>
+
+<ul>
+ <li><a href="#current_behaviour">Current Star Basic script threading behaviour</a>
+ </li>
+ <li><a href="#current_win_behaviour">Current Ms Basic script threading
+behaviour</a> </li>
+ <li><a href="#event_handling">Event Handling</a> </li>
+ <li><a href="#options">Options for script threading behaviour</a> </li>
+ <li><a href="#issues">Issues with allowing one script per document</a>
+ </li>
+ <li><a href="#configuration">Configuration of threading behaviour</a>
+ </li>
+ <li><a href="#ide">Identifying script threads in a debugger</a> </li>
+ <li><a href="#solarmutex">SolarMutex</a> </li>
+
+</ul>
+ Also of interest are these initial thoughts on the thread management topic
+posted to <a
+ href="http://udk.openoffice.org/common/man/draft/scripting/thread-management.html">openoffice.org</a>
+
+<hr> <a name="current_behaviour"></a>
+<h3>Current StarBasic script threading behaviour</h3>
+
+<p> Run the macro from the "Macro" dialogbox. </p>
+
+<ul>
+ <li>No frozen document you can work on any documents </li>
+ <li>Macro running in background </li>
+ <li>No macro can be run </li>
+
+</ul>
+ Assign the macro to the "F10" key. Press that key.
+<ul>
+ <li>Active document is frozen </li>
+ <li>Other document are not frozen </li>
+ <li>Can't run any macro on other document while the macro is still running
+even from the "Macro" dialogbox. </li>
+
+</ul>
+ While the macro is running, if you open the "Macro" dialogbox, the macro
+is paused
+<ul>
+ <li>If you close the dialog box, the macro is resumed </li>
+ <li>If you decide to edit a macro, the macro is resumed and you can stop
+the macro from the BASIC editor </li>
+ <li>If you switch to the BASIC editor and click on the stop button, the
+macro will be stop but nothing in the UI will be updated until the "Macro"
+dialogbox is closed (this seems to be a bug). </li>
+
+</ul>
+
+<p> <a href="#contents">Contents</a> </p>
+
+<hr> <a name="current_win_behaviour"></a>
+<h3>Current Ms Basic script threading behaviour</h3>
+
+<p> Run the macro from the "Macro" dialogbox. </p>
+
+<ul>
+ <li>All document are frozen </li>
+
+</ul>
+ Run the macro from the Ms Visual Basic editor.
+<ul>
+ <li>All document are frozen </li>
+
+</ul>
+ Assign the macro to the "F10" key. Press that key.
+<ul>
+ <li>All document are frozen </li>
+
+</ul>
+ Run a macro that will access Excel and change the cell values.
+<ul>
+ <li>All word document are frozen </li>
+ <li>Excel is not frozen, macro is running and changing value and you can
+change values. </li>
+
+</ul>
+
+<p> <a href="#contents">Contents</a> </p>
+
+<hr> <a name="event_handling"></a>
+<h3>Event Handling</h3>
+
+<p> The OpenOffice process has multiple threads. Any thread that calls Application::Yield
+or Application::Reschedule dispatches GUI events. Dispatching GUI events requires
+the SolarMutex, so only one thread at a time can dispatch GUI events. In
+practice the "main" OpenOffice thread is the thread that dispatches most GUI
+events. </p>
+
+<p> Events can be either synchronous or asynchronous. </p>
+
+<p> Synchronous events are handled immediately, that means that the functionality
+bound to the event is invoked immediately from the call stack of the thread
+where the event occurred. The thread is therefore blocked until the event has
+been handled. </p>
+
+<p> Asynchronous events are placed in a message queue by the thread handling
+the event, and the thread is not blocked, it continues executing. The message
+queue is serviced by any thread which calls Application::Yield or Application::Reschedule.
+ </p>
+
+<p> <a href="#contents">Contents</a> </p>
+
+<hr> <a name="options"></a>
+<h3>Options for script threading behaviour</h3>
+
+<p> There are two possible threading models that we could use: </p>
+
+<ol>
+ <li>One script per OpenOffice process - this is the threading model currently
+used by OpenOffice. </li>
+ <li>One script per OpenOffice document - this would allow more than one
+script to be run at the same time, but only one script could be run per document
+at a time. The thread running the script would have to grab a document lock
+before invoking the script and release it when the script has completed.
+ </li>
+
+</ol>
+
+<p> The best solution is to implement option 2, and add the possibility to
+configure the threading behaviour so that it acts like option 1 if the user
+wishes to use this behaviour (see Configuration section below). </p>
+
+<p> So, how do we implement option 2? From discussions with Mathias Bauer
+and Joerg Budischweski they feel that OpenOffice should manage the spawning
+of the threads which would invoke the scripts. In the case of synchronous
+events the thread handling the event would spawn a thread in which it would
+then invoke the script. In the case of asynchronous threads the thread which
+had grabbed the event off the message queue would spawn a new thread when
+it wanted to invoke a script. In other words the responsibility for managing
+the per document script threads would lie with OpenOffice, not the scripting
+framework. </p>
+
+<p> Changes needed: </p>
+
+<ul>
+ <li>The thread calling XFunction.invoke() (main thread for synchronous
+ events, message queue thread for asynchronous events) needs to spawn a
+new thread and call XFunction.invoke() from there. </li>
+ <li>The document for which the XFunction is being invoked needs to be
+ locked for the duration of XFunction.invoke() (with a documentmutex of
+some sort) so other XFunctions cannot be invoked for that document. The most
+difficult thing is that also every view that tries to modify a document must
+stick to this rule </li>
+
+</ul>
+
+<p>See also: "Threading model for an office scripting framework" discussion
+on openoffice.udk.dev newsgroup </p>
+
+<p> <a href="#contents">Contents</a> </p>
+
+<hr> <a name="issues"></a>
+<h3>Issues with allowing one script per document</h3>
+
+<p> Because of problems with thread safety in the OpenOffice API it is currently
+unsafe to allow more than one thread to make API calls at the same time. For
+this reason there is a global SolarMutex which thread unsafe API implementations
+automatically lock before executing any functionality, and unlock before returning.
+The thread calling the OpenOffice API is not aware of this SolarMutex. While
+the SolarMutex is grabbed, OpenOffice API calls from other threads will block
+until the SolarMutex becomes free. The OpenOffice UI will be frozen while
+the SolarMutex is locked. If a script calls a OpenOffice API, the solarmutex
+will be grabbed until the API call returns which would temporarily freeze
+all document windows. These freezes may be an unacceptable annoyance to users
+and they may prefer that the UI be completely frozen for the duration of
+script execution rather than having it freeze unexpectedly. </p>
+
+<p> See also: "Office API and thread safety" discussion on openoffice.framework.dev
+newsgroup </p>
+
+<p> <a href="#contents">Contents</a> </p>
+
+<hr> <a name="configuration"></a>
+<h3>Configuration of threading behaviour</h3>
+
+<p> The threading behaviour of Office should be configurable so that the user
+can switch on/off the one script per document behaviour as they wish. A radio
+box should be added to the Scripting pane of the Office options dialog with
+the options: </p>
+
+<p> Allow only one script to be run by OpenOffice at a time. <br>
+ Allow one script per document to be run by OpenOffice at a time </p>
+
+<p> <a href="#contents">Contents</a> </p>
+
+<hr> <a name="ide"></a>
+<h3>Identifying script threads in a debugger</h3>
+
+<p> The issue here is how we can identify which thread in a OpenOffice process
+is running the script we are interested in debugging. This is possible in
+java using the java.lang.Thread.setName() method. The pairing of script name
+and document name should be sufficient to uniquely identify the appropriate
+thread. </p>
+
+<p> <a href="#contents">Contents</a> </p>
+
+<hr> <a name="solarmutex"></a>
+<h3>SolarMutex</h3>
+
+<p> A problem could arise if a thread that does not possess the SolarMutex
+ tries to execute a script synchronously, because any API call in the script
+can possibly acquire the SolarMutex. This may cause a deadlock, f.e. if the
+thread possessing the SolarMutex waits for a resource that is locked by the
+thread that tries to execute a script synchronously. So we could add some
+code here, that denies script execution, if it should be done synchronously
+and the SolarMutex is locked. It's better to treat this as an error than taking
+the risk of getting a deadlock. <br>
+ ======<br>
+ suffice to say that for synchronous executions the thread owns the SolarMutex,
+it doesn't need to be the "main" thread. <br>
+ ======<br>
+ Every not thread safe implementation of our API will acquire the SolarMutex
+in any interface call before anything will be done inside the method. So the
+function object doesn't need to care for that <br>
+ ======<br>
+ the SolarMutex should be locked only inside the API calls (it will be anyway),
+not by the function object (it mustn't, because it doesn't know if it is called
+synchronously or not!), the event handler or anybody else. A big advantage
+of this is, that the SolarMutex will be freed between two API calls, giving
+the message queue a chance to allow for a minimum responsiveness of the office
+process. The script then will work in parallel to the event queue. Only
+for synchronous execution we should try to (!) acquire the SolarMutex before
+executing the script as described above. If the try fails, script execution
+should be denied. I consider this to be a rare case, currently I can't imagine
+that any event that may cause a script execution will occur in a thread without
+the SolarMutex. But it's good to handle this case in an appropriate way.
+<br>
+ ======<br>
+ </p>
+
+<p> <a href="#contents">Contents</a> </p>
+
+<hr> <br>
+
+</body>
+</html>
Propchange: incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/ThreadingSoln.html
------------------------------------------------------------------------------
svn:eol-style = native
Added: incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/XModules.idl
URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/XModules.idl?rev=1206895&view=auto
==============================================================================
--- incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/XModules.idl (added)
+++ incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/XModules.idl Sun Nov 27 22:49:46 2011
@@ -0,0 +1,16 @@
+#ifndef __com_sun_star_scripting_XModules_idl__
+#define __com_sun_star_scripting_XModules_idl__
+
+#include <com/sun/star/uno/XInterface.idl>
+#include <com/sun/star/scripting/XMethod.idl>
+
+module com { module sun { module star { module scripting {
+
+interface XModules: com::sun::star::uno::XInterface {
+ /* from original i/f spec this should return a flat list of
+ * the available methods, and leave any hierarchical organisation
+ * of same to the UI */
+ sequence <string> getAvailableMethods();
+};
+}; }; }; };
+#endif
Added: incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/XMonitorListener.idl
URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/XMonitorListener.idl?rev=1206895&view=auto
==============================================================================
--- incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/XMonitorListener.idl (added)
+++ incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/XMonitorListener.idl Sun Nov 27 22:49:46 2011
@@ -0,0 +1,31 @@
+#ifndef __com_sun_star_scripting_XMonitorListener__
+#define __com_sun_star_scripting_XMonitorListener__
+#ifndef __com_sun_star_uno_XInterface_idl__
+#include <com/sun/star/uno/XInterface.idl>
+#endif
+#include <com/sun/star/lang/XEventListener.idl>
+#include <ScriptCompletedEvent.idl>
+#include <ScriptStartedEvent.idl>
+
+module com {
+ module sun {
+ module star {
+ module scripting {
+ interface XMonitorListener: com::sun::star::lang::XEventListener {
+
+ /** Will be executed when script is started
+ *
+ */
+ void scriptStarted([in] ScriptStartedEvent e);
+
+ /** Will be executed when script finishes
+ *
+ */
+ void scriptCompleted([in] ScriptCompletedEvent e);
+ };
+ };
+ };
+ };
+};
+#endif
+
Added: incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/arch.txt
URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/arch.txt?rev=1206895&view=auto
==============================================================================
--- incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/arch.txt (added)
+++ incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/arch.txt Sun Nov 27 22:49:46 2011
@@ -0,0 +1,269 @@
+Language agnostic scripting framework architecture
+==================================================
+
+Author: Laszlo Kovacs
+
+1. Project goals
+----------------
+
+1. Provide a language agnostic scripting framework specification
+and implementation that allows compiled and interpreted scripting
+engines to be plugged into StarOffice. This includes support for
+plugging in various IDEs.
+
+2. Integrate in the framework described at (1) a scripting engine
+for scripts developed in JAVA and a scripting engine for a JAVA
+based scripting language.
+
+3. Select an IDE and integrate it into the framework described at
+(1). Implement command line tools that duplicate the IDE
+functionality (for script developers who prefer command line
+environment).
+
+4. Refactor the current StarBasic scripting engine and
+environment so that it is plugged into StarOffice through the
+framework described at (1). Decision has to be made about what
+kind of IDE to provide (the old one or integrate with the new
+one).
+
+2.Language agnostic scripting framework
+---------------------------------------
+
+This section deals with the first item of the project goals.
+
+The main components of the language agnostic scripting framework
+are described below.
+
+2.1 Runtime environment
+-----------------------
+
+A language agnostic runtime environment has to allow script
+engine developers to plug in script engines (runtime instances)
+of compiled or interpreted languages.
+
+Runtime instances have to be managed by a runtime manager. They
+need to implement interface(s) through which the associated VM,
+interpreter can be started, stopped, identified, status queried,
+configured.
+
+Runtime instances have to be easily deployable into StarOffice,
+implementation as UNO components or using UNO wrappers will
+achieve this.
+
+Because of the specifics of individual VM/interpreter
+configurations the runtime implementation will probably have to
+provide its own specific configuration tool.
+
+Runtime services that are common for every runtime and should be
+part of the scripting framework implementation are:
+
+1. If compiled scripts are deployed by source then they will have
+to be compiled before running. The location of related compilers
+have to be discovered for this, probably configured through the
+configuration tool.
+
+2. Executed scripts have to be provided with context. This can be
+obtained from the storage service or can be assigned dynamically.
+
+3. Lifecycle services: resources acquired by the script have to
+be tracked and cleaned up after execution.
+
+4. A sandbox could be provided for managing script resources and
+access permissions to the file system and StarOffice services
+granting various rights to scripts. However this might be
+difficult to achieve in a language agnostic way. A simpler
+approach is described in the "Binding to events" section
+(signatures).
+
+5. Defining a state persistence service is a simple matter. In
+case of languages that support persistence StarOffice specific
+persistence services can be hidden from developers.
+
+6. Single threaded scripts have to be safely usable in the
+multithreaded StarOffice environment. A simple approach of not
+running two scripts at the same time in the same context (Single
+Threaded Apartment model) might be enough here.
+
+2.2 Binding to events ---------------------
+
+A binding UI (part of StarOffice) has to be provided for users
+who use scripts developed by script developers. This UI will
+allow binding of scripts and script methods to StarOffice events.
+The binding UI should navigate scripts developed in all the
+supported languages. This can be achieved with a generic naming
+scheme that easily maps to the supported languages naming
+schemes. Deployment information is needed to describe the methods
+implemented by a script (depending on languages this may be
+automatically generated from the script). The binding UI also has
+to facilitate parameter passing to scripts.
+
+It might be preferred to provide very simple editing
+functionalities in the binding UI so that a script can be changed
+and saved by the user before it is run.
+
+Security related issues in this case are:
+
+1. If scripts are provided by source they may be encrypted so
+that only certain users can run them. The binding UI has to be
+able to decrypt them based on passwords provided by the user.
+
+2. Scripts have to be prevented of harmful behavior. This may be
+achieved by a sandbox type of approach implemented in the
+runtime. This however might be difficult to achieve for every
+language in a language agnostic way.
+
+An alternative approach is similar to the Java applet signatures.
+Scripts can contain a signature from a trusted source meaning
+that they can be trusted. It would be up to the user to decide
+whether scripts are run or not based on their signatures. If
+scripts are run they would have full access to resources and
+StarOffice services. An extension to this where trusted scripts
+would be granted with more resources and possibilities than not
+trusted ones might be difficult to implement.
+
+2.3 IDE services
+----------------
+
+Developers need an IDE or simple command line tools for
+development. The development tasks these tools have to support
+are accessing/editing/storing code, compiling, debugging, code
+encryption/decryption (see "Binding to events").
+
+The scripting framework has to include specification and
+implementation of services that will support the IDE
+functionalities. These are storage, debugging and compiling
+services. Encryption/decryption services are simple and will be
+shared between the binding UI, the IDE, the macro recording
+component and possibly the runtime environment.
+
+The compiling service supports easy plug in of various compilers
+for compiled languages. Apart from the IDE another higher level
+component that needs the compiler service is the runtime
+environment, in case scripts are deployed by source and need to
+be compiled before being run.
+
+Explicit debugging services (breakpoint setting/clearing,
+variable evaluation etc.) need to be defined. Some debuggers
+(JVM) allow direct connection of the IDE to them, with no need
+for a special debugging service.
+
+Access/edit/save of scripts, their deployment information and
+context has to rely on the script navigation and storage
+services. No extra services have to be defined here. These
+services (especially assigning context) have to be shared between
+the IDE and the binding UI.
+
+2.4 Script navigation and storage
+---------------------------------
+
+Script storage is a lower level service that most of the other
+services will rely on. IDEs and command line development tools
+will have to load, edit, save scripts. The binding UI will have
+to be able to navigate through the scripts, their deployment
+information and context. Runtimes will need to locate and load
+the scripts that are selected for execution.
+
+A storage service has to implement access, navigation and saving
+of scripts, their deployment information and context for all
+supported languages, interfaces will have to be defined for this.
+
+The approach of script storage in relation to documents and the
+application has to be defined. Scripts can be part of related
+documents or referenced from documents. The application wide
+scripts will have to be stored in an application rather than
+document specific area.
+
+2.5 Macro recording
+-------------------
+
+Macro (script) recording has to be supported by the scripting
+framework. The sharing of responsibilities between StarOffice,
+the scripting framework and language specific macro recording
+components has to be researched.
+
+3. IDE implementation and command line tools
+--------------------------------------------
+
+This section deals with the third item of the project goals.
+
+The main issue here is whether the preferred solution is to use
+an IDE framework (such as NetBeans) to develop the IDE or an IDE
+is developed from scratch (for example using JBuilder).
+
+IDEs will use the compiler service and the debugging service for
+development. They will use the storage service to edit scripts
+and to deploy scripts in various contexts (assigned to documents
+or application wide). The part of the IDE that is implemented on
+top of the storage service has to be more complex than an
+ordinary file selection box as it has to access and store scripts
+in relation to various contexts.
+
+Close integration between the binding UI, the IDE and the
+debugging services is needed for script testing during
+development. After a script has been saved (with a specific
+context), developers have to be able to bind it to an event, run
+it in a debugger and set breakpoint or evaluate variables through
+the IDE.
+
+Editing command line tools will have to implement easy extraction
+and saving of scripts in document and application contexts.
+Command line compiling does not need extra support. Command line
+debugging needs support for setting the script context before
+running and cooperation with the binding UI.
+
+An important feature of an IDE is a GUI builder. Modern script
+environments include GUI builders. In the language agnostic
+context the main issues are whether a language independent GUI
+building framework is feasible, and what effort will this put on
+developers to learn yet another UI API. Alternatively the GUI
+builder can be deferred to the individual script engine
+implementations. The possibility to achieve similar look and feel
+to StarOffice is important in this case.
+
+
+4. Architecture diagram
+------------------------
+
+This diagram tries to capture both the language agnostic
+scripting framework and the integrated IDE. It contains only the
+components and their relationships (connecting lines describe
+relationships), not what services the components provide.
+
+It does not deal with the security related issues of script
+execution (the sandbox vs the signature approach).
+
+In case of the signature approach a signature service has to be
+provided that allows scripts to be signed whenever they are
+created (IDE, macro recording) and to retrieve the signature
+before assigning to an event (binding UI).
+
+In case of the sandbox approach the common runtime services have
+to be extended with the sandbox implementation and a security
+configuration UI provided that configures the sandbox. This could
+be built on top of the signature approach.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Propchange: incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/arch.txt
------------------------------------------------------------------------------
svn:eol-style = native
Added: incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/archdiag.pdf
URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/archdiag.pdf?rev=1206895&view=auto
==============================================================================
Binary file - no diff available.
Propchange: incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/archdiag.pdf
------------------------------------------------------------------------------
svn:mime-type = application/pdf
Added: incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/basic-storage.html
URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/basic-storage.html?rev=1206895&view=auto
==============================================================================
--- incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/basic-storage.html (added)
+++ incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/basic-storage.html Sun Nov 27 22:49:46 2011
@@ -0,0 +1,310 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
+<HTML>
+<HEAD>
+ <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=iso-8859-1">
+ <TITLE></TITLE>
+ <META NAME="GENERATOR" CONTENT="OpenOffice.org 1.0 (Solaris Sparc)">
+ <META NAME="CREATED" CONTENT="20020626;15244200">
+ <META NAME="CHANGEDBY" CONTENT="Alexis Ledoux">
+ <META NAME="CHANGED" CONTENT="20020628;16180400">
+ <STYLE>
+ <!--
+ @page { margin-left: 3.18cm; margin-right: 3.18cm; margin-top: 2.54cm; margin-bottom: 2.54cm }
+ -->
+ </STYLE>
+</HEAD>
+<BODY LANG="en-US">
+<BR><B>Process
+of creating a macro and assigning it to an event</B>
+<BR><BR>
+
+<BR>Assign a
+macro that was created and saved in the Standard Library of
+OpenOffice called Test().
+<BR>The
+directory <FONT SIZE=2><FONT FACE="Courier, monospace">soffice.cfg
+is created in the <FONT SIZE=2><FONT FACE="Courier, monospace">user/config
+directory once you assign a macro to a key.
+<BR>An xml
+file per context is created and contains all the bindings.
+<BR>Because
+the macro is in the Standard Library of OpenOffice and that the
+binding is only applied to a key in Writer:
+<BR> The file
+<FONT SIZE=2><FONT FACE="Courier, monospace">writerkeybinding.xml
+is created
+<BR><BR>
+
+<BR><B>Content
+of</B> <FONT SIZE=2><FONT FACE="Courier, monospace">writerkeybinding.xml
+<BR><BR>
+
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><?xml
+version="1.0" encoding="UTF-8"?>
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><!DOCTYPE
+accel:acceleratorlist PUBLIC "-//OpenOffice.org//DTD
+OfficeDocument 1.0//EN" "accelerator.dtd">
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><accel:acceleratorlist
+xmlns:accel="http://openoffice.org/2001/accel"
+xmlns:xlink="http://www.w3.org/1999/xlink">
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>
+ ...
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>
+ <accel:item accel:code="KEY_F10"
+xlink:href="macro:///Standard.Module1.Alexis()"/>
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>
+ ...
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2></accel:acceleratorlist>
+<BR><BR>
+
+<BR><B>Content
+of</B> <FONT SIZE=2><FONT FACE="Courier, monospace">Accelerator.dtd
+<BR><BR>
+
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><!ENTITY
+% boolean "(true|false)">
+<BR><BR>
+
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><!ELEMENT
+accel:acceleratorlist (accel:item*)>
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><!ATTLIST
+accel:acceleratorlist
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2> xmlns:accel
+CDATA #FIXED "http://openoffice.org/2001/accel"
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2> xmlns:xlink
+CDATA #FIXED "http://www.w3.org/1999/xlink"
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>>
+<BR><BR>
+
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><!ELEMENT
+accel:item EMPTY>
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><!ATTLIST
+accel:item
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2> accel:code
+CDATA #REQUIRED
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2> accel:shift
+%boolean; "false"
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2> accel:mod1
+%boolean; "false"
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2> accel:mod2
+%boolean; "false"
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2> xlink:href
+CDATA #REQUIRED
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>>
+<BR><BR>
+
+<BR>The
+content of <FONT SIZE=2><FONT FACE="Courier, monospace">user/basic
+is formed by a directory per library you modified (in that case
+Standard was modified) and 2 files .xlc.
+<BR><FONT SIZE=2><FONT FACE="Courier, monospace">Script.xlc
+is the file that will be explained:
+<BR><BR>
+
+<BR><B>Content
+of the file</B> <FONT SIZE=2><FONT FACE="Courier, monospace">script.xlc
+<BR><BR>
+
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><?xml
+version="1.0" encoding="UTF-8"?>
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><!DOCTYPE
+library:libraries PUBLIC "-//OpenOffice.org//DTD OfficeDocument
+1.0//EN" "libraries.dtd">
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>
+<library:libraries
+xmlns:library="http://openoffice.org/2000/library"
+xmlns:xlink="http://www.w3.org/1999/xlink">
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>
+ <library:library library:name="Standard"
+xlink:href="file:///home/al91857/StarOffice6.0/user/basic/Standard/script.xlb/"
+xlink:type="simple" library:link="false"/>
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>
+ <library:library library:name="WebWizard"
+xlink:href="file:///usr/dist/share/staroffice,v6.0/share/basic/WebWizard/script.xlb/"
+xlink:type="simple" library:link="true"
+library:readonly="false"/>
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>
+ ...
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>
+</library:libraries>
+<BR><BR>
+
+<BR><B>Content
+of </B><FONT SIZE=2><FONT FACE="Courier, monospace">Libraries.dtd
+<BR><BR>
+
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><!ENTITY
+% boolean "(true|false)">
+<BR><BR>
+
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><!ELEMENT
+library:libraries (library:library)*>
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><!ATTLIST
+library:libraries
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2> xmlns:library
+CDATA #FIXED "http://openoffice.org/2000/library"
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2> xmlns:xlink
+CDATA #FIXED "http://www.w3.org/1999/xlink"
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>>
+<BR><BR>
+
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><!ELEMENT
+library:library EMPTY>
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><!ATTLIST
+library:library
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2> library:name
+CDATA #REQUIRED
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2> xlink:href
+CDATA #IMPLIED
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2> xlink:type
+CDATA #IMPLIED
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2> library:link
+%boolean; #REQUIRED
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2> library:readonly
+%boolean; #IMPLIED
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>>
+<BR><BR>
+
+<BR>You can
+see that the <FONT SIZE=2><FONT FACE="Courier, monospace">xlink:href
+of the <FONT SIZE=2><FONT FACE="Courier, monospace">library:name="Standard"
+is locating as file in the home directory because I modified that
+library.
+<BR><BR>
+
+<BR><B>Content
+of the file</B> <FONT SIZE=2><FONT FACE="Courier, monospace">script.xlb
+<B>in</B> <FONT SIZE=2><FONT FACE="Courier, monospace">file:///home/al91857/StarOffice6.0/user/basic/Standard
+<BR><BR>
+
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><?xml
+version="1.0" encoding="UTF-8"?>
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><!DOCTYPE
+library:library PUBLIC "-//OpenOffice.org//DTD OfficeDocument
+1.0//EN" "library.dtd">
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><library:library
+xmlns:library="http://openoffice.org/2000/library"
+library:name="Standard" library:readonly="false"
+library:passwordprotected="false">
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>
+<library:element library:name="Module1"/>
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2></library:library>
+<BR><BR>
+
+<BR><B>Content
+of</B> <FONT SIZE=2><FONT FACE="Courier, monospace">Library.dtd
+<BR><BR>
+
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><!ENTITY
+% boolean "(true|false)">
+<BR><BR>
+
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><!ELEMENT
+library:library (library:element)*>
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><!ATTLIST
+library:library
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2> xmlns:library
+CDATA #FIXED "http://openoffice.org/2000/library"
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>
+library:name CDATA #REQUIRED
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>
+library:readonly %boolean; #REQUIRED
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>
+library:passwordprotected %boolean; #REQUIRED
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>>
+<BR><BR>
+
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><!ELEMENT
+library:element EMPTY>
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><!ATTLIST
+library:element
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2> library:name
+CDATA #REQUIRED
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>>
+<BR><BR>
+
+<BR><B>Content
+of the file where my macro was saved:</B> <FONT SIZE=2><FONT FACE="Courier, monospace">Module1.xba
+<BR><BR>
+
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><?xml
+version="1.0" encoding="UTF-8"?>
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><!DOCTYPE
+script:module PUBLIC "-//OpenOffice.org//DTD OfficeDocument
+1.0//EN" "module.dtd">
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><script:module
+xmlns:script="http://openoffice.org/2000/script"
+script:name="Module1" script:language="StarBasic">REM
+ ***** BASIC *****
+<BR><BR>
+
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>Sub
+Main
+<BR><BR>
+
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>End
+Sub
+<BR><BR>
+
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>Sub
+Alexis
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>print
+&quot;alexis&quot;
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>End
+Sub</script:module>
+<BR><BR>
+
+<BR><B>Content
+of</B> <FONT SIZE=2><FONT FACE="Courier, monospace">Module.dtd
+<BR><BR>
+
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><!ELEMENT
+script:module (#PCDATA)>
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><!ATTLIST
+script:module
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2> xmlns:script
+CDATA #FIXED "http://openoffice.org/2000/script"
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2> script:name
+CDATA #REQUIRED
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2> script:language
+CDATA #REQUIRED
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>>
+<BR><BR>
+
+<BR>When
+you save the document including the macro, everything is in a Zip
+file with the same hierarchy than explained above.
+<BR><BR>
+
+<BR>The
+file hierarchy is:
+<BR><BR>
+
+<BR>Archive:
+ test.sxw
+<BR>
+ testing: content.xml
+<BR>
+ testing: Basic/Standard/Module1.xml
+<BR>
+ testing: Basic/Standard/script-lb.xml
+<BR>
+ testing: Basic/script-lc.xml
+<BR>
+ testing: styles.xml
+<BR>
+ testing: meta.xml
+<BR>
+ testing: settings.xml
+<BR>
+ testing: META-INF/manifest.xml
+<BR><BR>
+
+<BR>So
+the script-lb.xml file is the equivalent to the script.xlb file
+explained above
+<BR>The
+script-lc.xml file is the equivalent to the script.xlc file explained
+Above.
+</BODY>
+</HTML>
Propchange: incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/basic-storage.html
------------------------------------------------------------------------------
svn:eol-style = native
Added: incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/build-script.html
URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/build-script.html?rev=1206895&view=auto
==============================================================================
--- incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/build-script.html (added)
+++ incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/build-script.html Sun Nov 27 22:49:46 2011
@@ -0,0 +1,296 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
+<html>
+<head>
+
+ <meta http-equiv="CONTENT-TYPE"
+ content="text/html; charset=iso-8859-1">
+ <title>Building Scripting</title>
+
+ <meta name="GENERATOR" content="OpenOffice.org 1.0 (Solaris Sparc)">
+
+ <meta name="CREATED" content="20020626;15244200">
+
+ <meta name="CHANGEDBY" content="Alexis Ledoux">
+
+ <meta name="CHANGED" content="20020628;16180400">
+
+ <style>
+ <!--
+ @page { margin-left: 3.18cm; margin-right: 3.18cm; margin-top: 2.54cm; margin-bottom: 2.54cm }
+ -->
+ </style>
+</head>
+ <body lang="en-US">
+
+<h2>Building the Scripting Framework for OpenOffice.org</h2>
+
+<h3>Contents:</h3>
+
+<ol>
+ <li><a href="#Requirements">Requirements</a></li>
+ <li><a href="#cvs">CVS</a></li>
+ <li><a href="#env">Setting up environment</a></li>
+ <li><a href="#modify">Modifying modules</a></li>
+ <li><a href="#build">Building</a></li>
+ <li><a href="#pkg">Create package</a></li>
+ <li><a href="#install">Manual install</a><br>
+ </li>
+
+</ol>
+ <br>
+ <br>
+
+<h3><a name="Requirements"></a>Requirements:</h3>
+
+<ul>
+ <li>JDK1.3 or greater</li>
+ <li>ANT which is available from <a
+ href="http://jakarta.apache.org/builds/jakarta-ant/release">http://jakarta.apache.org/builds/jakarta-ant/release</a></li>
+ <li>Full OO643C or later solver and installation set</li>
+ <li>OO643C or greater OpenOffice build environment (see: <a
+ href="http://www.openoffice.org/dev_docs/source/643/index.html/ondownloads">Downloading
+ and Building the Source</a>, currently this is for 643 not OO643C )</li>
+
+</ul>
+
+<h3><a name="cvs"></a>Projects to get from CVS</h3>
+Backup your unoil and offapi modules and then checkout the following:<br>
+ <br>
+ Modules to be checkout from CVS head:<br>
+
+<ul>
+ <li><i>scripting</i></li>
+ <li><i>unoil/drafts/com/sun/star/script (drafts/com/sun/star/script,
+ </i>needs to be in the <i>unoil </i> module)</li>
+ <li><i>offapi/drafts/com/sun/star/script </i><i>(drafts/com/sun/star/script,
+ </i>needs to be in the <i>offapi </i> module)</li>
+
+</ul>
+ If you only have solvers, you will also need to checkout the following
+ modules on a tag that is appropriate to the release, you are building
+for:<br>
+
+<ul>
+ <li><i>unoil</i></li>
+ <li><i>offapi</i></li>
+
+</ul>
+
+<h3><a name="env"></a>Setting up build environment for Scripting</h3>
+ <b>Assumption: </b>That you have a build environment set-up to build
+ OpenOffice.org or components for OpenOffice.org, otherwise please read
+the guide on <a
+ href="http://www.openoffice.org/dev_docs/source/643/index.html/ondownloads">Downloading
+ and Building the Source</a><br>
+ <br>
+ If you have configured your environment with Java and Ant, please skip
+ on to ...... , otherwise you will need to re-run the configure script from
+ the <i>config_office</i> project and include the options <i>--with-jdk-home=<PATH
+ TO JAVA> --with-ant-home=<PATH TO ANT></i> and source or
+ run the environment set-up script.<br>
+ <br>
+ <b>NOTE: </b>If configure can not get Ant, after you have sourced or
+ run the environment set-up script, you will need add all jarfiles
+ under <i><PATH TO ANT>/lib</i> to your <i>$CLASSPATH</i><br>
+ <br>
+
+<h3><a name="modify"></a>Modifying offapi, unoil and scripting modules for
+ building</h3>
+ You will need to modify the offapi and unoil modules so that the services
+ and interfaces for scripting are available.<br>
+
+<h4>offapi module:</h4>
+
+<ol>
+ <li>Ensure that you have the drafts/com/sun/star/script directory
+under the offapi module, if you don't, you will need to check it out from
+CVS head</li>
+ <li>Modify the prj/build.lst, you will need to add the following
+lines</li>
+
+ <ul>
+ <li><i>oa offapi\drafts\com\sun\star\script\framework
+ nmake - all oa_scriptf_drafts NULL</i></li>
+ <li><i>oa offapi\drafts\com\sun\star\script\framework\provider
+ nmake - all oa_sfprovider_drafts NULL</i></li>
+ <li><i>oa offapi\drafts\com\sun\star\script\framework\storage
+ nmake - all oa_sfstorage_drafts NULL</i></li>
+ <li>and add "<i>oa_sfprovider_drafts oa_sfstorage_drafts oa_scriptf_drafts</i>"
+ to the last line before "<i>NULL</i>"</li>
+
+ </ul>
+ <li> Modify the util/makefile.mk and add the following to UNOIDLDBFILES
+ list </li>
+
+ <ol>
+ <li>$(UCR)$/dcssscriptframework.db \ </li>
+ <li>$(UCR)$/dcsssfprovider.db \ </li>
+ <li>$(UCR)$/dcsssfstorage.db </li>
+
+ </ol>
+
+</ol>
+
+<h2></h2>
+
+<h4>unoil module:</h4>
+
+<ol>
+ <li>Ensure that you have the drafts/com/sun/star/script directory under
+ the unoil module, if you don't, you will need to check it out from CVS
+head</li>
+ <li>Modify the makefile.mk in the top level directory of the module
+-</li>
+
+ <ol>
+ <li>Change the line <i>RDB = $(SOLARBINDIR)/offapi.rdb</i>
+ to <i>RDB = $(PRJ)$/..$/offapi$/$(INPATH)$/ucr$/offapi.db</i></li>
+
+ </ol>
+ <li>Modify prj/build.lst</li>
+
+ <ol>
+ <li>Add the following line:<i> ul unoil\drafts\com\sun\star\script\framework
+ nmake - all ul_scriptf_drafts ul_ucb ul_frame NUL</i>L
+ <br>
+ </li>
+ <li>Add <i>ul_scriptf_drafts </i>to the last line before <i>NULL</i></li>
+
+ </ol>
+
+</ol>
+
+<h4>scripting module:</h4>
+
+<ol>
+ <li>Remove the comments from the lines in source/cppumaker.mk:</li>
+
+ <ol>
+ <li>UNOUCRDEP=$(PRJ)/../offapi/$(INPATH)/ucr/offapi.db $(SOLARBINDIR)$/udkapi.rdb
+ $(SOLARBINDIR)$/offapi.rdb</li>
+ <li>UNOUCRRDB=$(PRJ)/../offapi/$(INPATH)/ucr/offapi.db $(SOLARBINDIR)$/udkapi.rdb
+ $(SOLARBINDIR)$/offapi.rdb<br>
+ </li>
+
+ </ol>
+ <li>Comment out the lines in source/cppumaker.mk</li>
+
+ <ol>
+ <li>UNOUCRDEP=$(SOLARBINDIR)$/udkapi.rdb</li>
+ <li>UNOUCRRDB=$(SOLARBINDIR)$/udkapi.rdb</li>
+
+ </ol>
+ <li>Remove the comment from the following line in java/build.xml:</li>
+
+ <ol>
+ <li><!-- <pathelement location="${prj}/../unoil/${inpath}/class/unoil.jar"/>
+ --></li>
+
+ </ol>
+ <li>Comment out the line in java/build.xml:</li>
+ <ol>
+ <li><pathelement location="${solar.jar}/unoil.jar"/><br>
+ </li>
+ </ol>
+
+</ol>
+
+<h3><a name="build"></a>Building scripting</h3>
+
+<ol>
+ <li>Execute <i>build</i> in the <i>offapi</i> module</li>
+ <li>Execute <i>build </i>in the <i>unoil</i> module</li>
+ <li>Execute <i>build</i> in the <i>scripting</i> module</li>
+
+</ol>
+
+<h3><a name="pkg"></a>Creating the UNO Package:</h3>
+ Please read the <a
+ href="http://api.openoffice.org/DevelopersGuide/DevelopersGuide.html">Developer's
+ Guide</a> for more information on UNO packages<br>
+
+<ol>
+ <li>Create a separate directory (<i>$pkg)</i></li>
+ <li>In this directory, create directories called <i>$pkg/<PLATFORM>.plt
+ </i>and <i>$pkg/</i><i>skip_registration (</i>Where <i><PLATFORM></i>
+ is like linux_x86)</li>
+ <li><b>NOTE</b>: A list of supported directories is available in the
+source file desktop/source/pkgchk/pkgchk_packages.cxx, you may need to modify
+this, if your platform is not supported<br>
+ </li>
+ <li>Copy in the libraries from <i>scripting/<platform>/lib </i>to
+ <i>$pkg/</i><i><PLATFORM>.plt</i></li>
+ <li>Copy in <i>ScriptRuntimeForJava.jar</i> from <i>scripting/<platform>/class</i>
+ into the top level directory, <i>$pkg</i></li>
+ <li>Copy in <i>unoil.jar </i>from <i>$pkg/</i><i>unoil/<platform>/class
+ </i> to <i>skip_registration</i> directory<br>
+ </li>
+ <li>Merge the following registries from <i>offapi/<platform>/ucr
+ </i>into one registry called <i>ooscript.rdb</i> under the top level
+directory, <i>$pkg</i></li>
+
+ <ol>
+ <li><i>dcssscriptframework.db</i></li>
+ <li><i>dcsssfprovider.db</i></li>
+ <li><i>dcsssfstorage.db</i></li>
+
+ </ol>
+ <li>Now, zip up all files in this directory, <i>$pkg</i></li>
+
+</ol>
+
+<h3><a name="install"></a>Manual Installation of the Scripting Framework</h3>
+
+<ol>
+ <li>Copy the zip file into your OpenOffice installation under the user/uno_packages
+ directory <font color="#ff0000"></font></li>
+ <li>In the program directory, run pkgchk on the zip file</li>
+ <li>Copy from the solver<i> ($SRC_ROOT)/solver/643/<platform>/bin/</i><i>regsingleton</i>
+to your OpenOffice installation under the program directory<br>
+ </li>
+ <li>Execute the following: <font color="#ff0000"></font></li>
+
+ <ol>
+ <li><i>./regsingleton <OpenOffice Path>/user/uno_packages/cache/services.rdb
+ drafts.com.sun.star.script.framework.storage.theScriptStorageManager=drafts.com.sun.star.script.framework.storage.ScriptStorageManager</i></li>
+ <li><i>./regsingleton <OpenOffice Path>/user/uno_packages/cache/services.rdb
+ drafts.com.sun.star.script.framework.theScriptRuntimeForJava=drafts.com.sun.star.script.framework.ScriptRuntimeForJava</i></li>
+
+ </ol>
+ <li>Modify the the <i>ProtocolHandler.xcu</i> file under<i> <OpenOffice
+ Path>/share/registry/data/org/openoffice/Office/</i>, add the following
+ lines:</li>
+
+ <ol>
+ <li><node oor:name="com.sun.star.comp.ScriptProtocolHandler" oor:op="replace"><br>
+
+ <prop oor:name="Protocols"><br>
+
+ <value>script:*</value><br>
+
+ </prop><br>
+
+ </node><br>
+ Under the HandlerSet Tag</li>
+
+ </ol>
+
+</ol>
+ Unzip <i>HighlightTextParcel.sxp</i> from <i>scripting/examples/java </i>into
+ <i><OpenOffice Path>/user</i>, this should create a directory under
+ <i>user </i> called <i>Scripts/java/HighlightText</i><br>
+ <br>
+ Now, run OpenOffice and under the <i>Tools->Configure</i> menu add
+a new menu which is bound to the macro <i>Standard.Main</i>, then shut down
+ OpenOffice and modify the file <i><OpenOffice>/user/config/soffice.cfg/writermenubar.cfg</i>
+ and change <i>macro://Standard.main()</i> to <i>script://HighlightText.showForm.
+ </i>Start OpenOffice again and select the menu item you have added, this
+should bring up a Java dialog box call <i>HighlightText</i><br>
+ <br>
+ If you have any problems, please post your problem to <b><i>dev@framework.openoffice.org</i></b><br>
+ <br>
+ <br>
+ <br>
+ <br>
+</body>
+</html>
Propchange: incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/build-script.html
------------------------------------------------------------------------------
svn:eol-style = native
Added: incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/ide.txt
URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/ide.txt?rev=1206895&view=auto
==============================================================================
--- incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/ide.txt (added)
+++ incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/ide.txt Sun Nov 27 22:49:46 2011
@@ -0,0 +1,146 @@
+IDE requirements
+================
+
+Author: Laszlo Kovacs
+
+This document contains the main issues related to IDE development
+and integration into StarOffice in the context of the language
+agnostic scripting framework.
+
+1. External IDEs
+----------------
+
+StarOffice currently has an internal IDE for StarBasic code ma-
+nipulation. With multiple script language support introduced in-
+tegration of StarOffice with a robust external IDE will be need-
+ed. It is feasible to adopt an existing IDE rather than develop-
+ing one from scratch. The two IDEs considered are NetBeans (Forte
+for Java) and JBuilder.
+
+1.1. NetBeans
+-------------
+
+NetBeans is both an IDE platform and a Java IDE developed on this
+platform. Unfortunately there is an obvious naming problem here,
+the NetBeans web site calls them NetBeans IDE (for the Java IDE)
+and NetBeans platform (for the IDE framework that can be used to
+develop IDEs for any application). While NetBeans is an open
+source project, Forte for Java is the commercial implementation
+of the NetBeans Java IDE.
+
+For Java and Java based scripting languages Forte for Java should
+be used as the external IDE. The NetBeans IDE has rudimentary
+support for three Java based scripting languages (environments),
+they are Jython, Dynamic Java and BeanShell. These could be en-
+hanced and moved into Forte for Java.
+
+Integration of StarBasic and other scripting languages in the
+Forte environment depends on the extensibility policy of the
+Forte environment. Forte 7 provides one unified IDE based on Net-
+Beans for all the Forte environments (Java, C, C++, Fortran). If
+Forte extensibility by Sun for Starbasic and by third parties for
+other languages is not feasible because of marketing reasons then
+the NetBeans JAVA IDE can be used for IDE integration.
+
+1.2. JBuilder
+-------------
+
+JBuilder is a very popular Java environment, there could be mar-
+keting reasons for adapting it as the external StarOffice IDE. It
+is extensible through the so called OpenTools add-ins. There is
+an open source project for extending JBuilder with Jython support
+(needs enhancements). Support for other Java based scripting lan-
+guages can be developed in a similar way.
+
+While JBuilder provides similar extensibility to NetBeans in cer-
+tain areas, the main drawback is that it does not allow replace-
+ment of Java with other languages. Various Java runtimes can be
+used, but runtimes of other languages can not be plugged in. They
+all have to integrate with the Java debugger that is part of
+JBuilder. This might change as the Open Tools documentation
+states that the debugging and building APIs will be extensively
+changed in the future (I could not find out anything about the
+nature of the changes).
+
+The only languages that could be supported in this context are
+Java and Java based scripting languages. Support for non-Java
+based scripting languages (including StarBasic) is not possible.
+
+2. Internal vs external IDE
+---------------------------
+
+Considering the various types of user groups and the scripts they
+develop a large external IDE might not be feasible to cover the
+needs and a simple internal IDE could be provided.
+
+The sharing of responsibilities between the external and internal
+IDE has to be defined. As currently StarOffice has only an inter-
+nal IDE, this provides all the needed functionality. In a multi-
+ple scripting language context (where one of the languages could
+be Java) adding complete IDE functionality to the internal IDE in
+a language agnostic way would mean duplicating a large amount of
+features of the external IDE in the internal one. Identifying the
+user groups for the two IDEs and clearly separating their needs
+will reduce the amount of duplication. For example assuming that
+the internal IDE would be used for writing very small scripts,
+complete debugging support might not be provided by the internal
+IDE.
+
+The current Starbasic IDE should be revised along these lines.
+
+3. Implementation of functionality needed by the IDE(s)
+-------------------------------------------------------
+
+In the various scenarios discussed above StarOffice might have
+both an external and an internal IDE. Depending on the internal
+IDE functionalities a number of underlying services will be
+shared by the two IDEs. An obvious approach would be to define a
+set of UNO interfaces for the functionalities (like debugging,
+compiling, storage access etc). These would be implemented by un-
+derlying components and used by both IDEs according to needs.
+
+In the context of NetBeans as an external IDE and Java and Java
+based scripting language support (among other languages) several
+issues have to be mentioned:
+
+(a) NetBeans (and Forte for Java) is already integrated with Java
+so this integration would not happen through the above mentioned
+UNO interfaces. If the languages supported would be Java, Java
+based scripting languages and Starbasic then only the new, refac-
+tored StarBasic integration would use the UNO interfaces.
+
+(b) The NetBeans IDE framework provides an extensive Java API for
+integration of other languages environments. If an UNO layer is
+attached below this, that will result in two similar APIs on top
+of each other with the only benefit that the various scripting
+language integrations can be developed in any language. If the
+UNO layer is not added then other scripting languages (like Star-
+Basic) could be integrated in Java only.
+
+4. Integration between the IDEs and the binding UI
+--------------------------------------------------
+
+The binding UI has to run a selected script's selected method. If
+the script has syntax errors in it or breakpoints have been set,
+execution has to stop and the (internal or external IDE) activat-
+ed. For Java and Java based scripting languages this can easily
+be achieved through JPDA (the Java Platform Debugger Architec-
+ture, an infrastructure needed to develop end-user debugger ap-
+plications).
+
+Integration of other scripting languages has to be done through
+UNO interfaces that provide JPDA-like features. The development
+environment of the language needs similar degree of cooperation
+as between the JVM and the Java debugger for this.
+
+5. GUI building
+---------------
+
+An important feature of an IDE is a GUI builder. Modern script
+environments include GUI builders. In the language agnostic con-
+text the main issues are whether a language independent GUI
+building framework is feasible (effort), and what effort will
+this put on developers to learn yet another UI API. Alternatively
+the GUI builder can be deferred to the individual language imple-
+mentations. The possibility to achieve similar look and feel to
+StarOffice is important in this case.
Propchange: incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/ide.txt
------------------------------------------------------------------------------
svn:eol-style = native
Added: incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/index.html
URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/index.html?rev=1206895&view=auto
==============================================================================
--- incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/index.html (added)
+++ incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/index.html Sun Nov 27 22:49:46 2011
@@ -0,0 +1,120 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html>
+<head><title>Language Independent Scripting Framework</title>
+<meta HTTP-EQUIV="content-type" CONTENT="text/html; charset=UTF-8"/>
+</head>
+<body>
+
+<h1>Language Independent Scripting Framework</h1>
+
+<h3>Nov 2002 - The Scripting Framework has now moved to the Application
+Framework project. The pages you find here are kept only for historical
+purposes. For up to date information on the project see
+<a href="http://framework.openoffice.org/scripting/index.html">
+the current Scripting Framework home page</a>.
+</h3>
+
+<p>This project is about enabling OpenOffice to be scripted in multiple
+scripting languages.. This page is to be used as a repository of information
+ relating to this project.<br/>
+ <br/>A team has been put together specifically for providing a language-agnostic
+ scripting framework for StarOffice. </p>
+<p>The team is in the process of defining the architecture and high level
+design for the scripting framework. The steps for this are:<br/>
+- provide a high level architecture (<a href="ArchDoc.20020618.sxw">Architecture Document</a>
+)<br/>
+- brainstorm possible user stories and compile them into a product requirements document (<a href="ProdReq.sxc">Product Requirements</a>
+)<br/>
+- analysis of major technical scripting framework issues (<a href="scripting-behaviour.sxw">Functional Areas, Interactions, Behaviour</a>
+)<br/>
+- provide high level design and interfaces for binding, invocation, naming, storage and IDE integration (in progress)<br/>
+- a number of research documents about the scripting framework issues, StarOffice areas involved and prototype are below</p>
+
+
+<p>Comments etc. (on the dev@udk.openoffice.org mailing list) will
+be really appreciated.</p>
+
+
+<p><b><font size="5">Documentation</font></b></p>
+<p><font size="5"><small>Architecture, high level design, product requirements<br/>
+</small><br/>
+</font></p>
+
+
+<table width="100%" cellspacing="1" cellpadding="4">
+ <tbody>
+ <tr>
+ <td bgcolor="#f0f0f0" valign="top"><a href="ArchDoc.20020618.sxw">Architecture Document</a></td>
+ <td bgcolor="#f0f0f0" valign="top">Language Agnostic Scripting
+ Framework high level architecture. </td>
+ </tr>
+ <tr>
+ <td bgcolor="#f0f0f0" valign="top"><a href="DesignDoc/">Design Document</a> <font color="#ff0000">New!</font></td>
+ <td bgcolor="#f0f0f0" valign="top">An initial design document containing class & interaction diagrams, proposals for the file structure, suggestions for the language-specific and logical names, DTD and XML for the script deployment and registry, and links to the proposed IDL files. </td>
+ </tr>
+ <tr>
+ <td bgcolor="#f0f0f0" valign="top"><a href="ProdReq.sxc">Product
+Requirements</a><br/>
+ </td>
+ <td bgcolor="#f0f0f0" valign="top">Product requirements (in
+ spreadsheet form). It contains the first cut of use cases grouped according
+ to associated user roles, specific product requirements and rough priorities
+ for implementation.<br/>
+ </td>
+ </tr><tr>
+ <td valign="top" bgcolor="#f0f0f0"><a href="scripting-behaviour.sxw">Functional areas, Interactions, Behaviour</a>
+ <br/>
+ </td>
+ <td valign="top" bgcolor="#f0f0f0">Analysis of major technical scripting framework issues.<br/>
+ </td>
+ </tr>
+
+
+
+
+
+</tbody>
+</table>
+ <br/>
+ <br/>
+<big>Research, prototype</big><br/>
+<br/>
+<table width="100%" bgcolor="#ffffff" cellspacing="1" cellpadding="4">
+<tbody><tr><td bgcolor="#f0f0f0" valign="top"><a href="JScriptWP.html">Java Scripting Framework</a></td><td bgcolor="#f0f0f0" valign="top">A document discussing
+some of the issues relating to a Java implementation of the Scripting
+Framework.</td></tr><tr><td bgcolor="#f0f0f0" valign="top"><a href="ProblemsIssues.html">Framework Problems & Issues</a> (Overview)<br/><ul><li><a href="code-management.html">Code management</a><br/></li><li><a href="thread-management.html">Thread management</a></li><li><a href="persistence.html">Persistence of script data</a></li><li><a href="symbol-resolution.html">Symbol/Dependency Resolution</a></li><li><a href="ide.txt">IDE requirements</a></li></ul></td><td bgcolor="#f0f0f0" valign="top">A collation of some
+of the main problem in the areas that need to be provided by the Scripting
+ Framework.<br/></td></tr><tr><td bgcolor="#f0f0f0" valign="top">Proposals for solutions<br/><ul><li><a href="BindingUI.html">Binding & binding UI</a></li><li><a href="ThreadingSoln.html">Threading</a></li><li><a href="StorageSolution.html">Script Storage<br/>
+ </a></li><li><a href="IDEIntegration.html">IDE Integration</a></li>
+</ul></td><td bgcolor="#f0f0f0" valign="top">Elaborations & proposals on
+some of the problem areas mentioned above.</td></tr></tbody>
+</table>
+<br/>
+
+<p><b><font size="5">Old Documentation</font></b> <br/>
+ </p>
+
+<table width="100%" bgcolor="#f0f0f0" cellspacing="1" cellpadding="4">
+ <tbody>
+ <tr>
+ <td bgcolor="#f0f0f0" valign="top"><a href="arch.txt">Architecture
+ Document</a></td>
+ <td bgcolor="#f0f0f0" valign="top">Language Agnostic Scripting
+ Framework architecture (deprecated).</td>
+ </tr>
+ <tr>
+ <td bgcolor="#f0f0f0" valign="top"><a href="archdiag.pdf">Architecture
+ Diagram</a></td>
+ <td bgcolor="#f0f0f0" valign="top">Scripting Framework architecture
+ diagram (PDF) (deprecated).</td>
+ </tr><tr>
+ <td valign="top" bgcolor="#f0f0f0"><a href="Services-and-interfaces.html">Services & Interfaces</a>
+ </td>
+ <td valign="top">A very basic first attempt
+ to define the necessary services & interfaces.</td>
+ </tr>
+
+
+ </tbody>
+</table>
+</body></html>
Propchange: incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/index.html
------------------------------------------------------------------------------
svn:eol-style = native
|