incubator-ooo-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ksch...@apache.org
Subject svn commit: r1206895 [5/12] - in /incubator/ooo/ooo-site/trunk/content/udk/common: ./ man/ man/concept/ man/draft/ man/draft/scripting/ man/draft/scripting/DesignDoc/ man/images/ man/spec/ man/tasks/ man/tutorial/
Date Sun, 27 Nov 2011 22:50:08 GMT
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>&lt;?xml
+version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&gt;
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>&lt;!DOCTYPE
+accel:acceleratorlist PUBLIC &quot;-//OpenOffice.org//DTD
+OfficeDocument 1.0//EN&quot; &quot;accelerator.dtd&quot;&gt;
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>&lt;accel:acceleratorlist
+xmlns:accel=&quot;http://openoffice.org/2001/accel&quot;
+xmlns:xlink=&quot;http://www.w3.org/1999/xlink&quot;&gt;
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>
+  ...
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>
+  &lt;accel:item accel:code=&quot;KEY_F10&quot;
+xlink:href=&quot;macro:///Standard.Module1.Alexis()&quot;/&gt;
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>
+  ...
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>&lt;/accel:acceleratorlist&gt;
+<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>&lt;!ENTITY
+% boolean	&quot;(true|false)&quot;&gt;
+<BR><BR>
+
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>&lt;!ELEMENT
+accel:acceleratorlist (accel:item*)&gt;
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>&lt;!ATTLIST
+accel:acceleratorlist
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>	xmlns:accel
+CDATA #FIXED &quot;http://openoffice.org/2001/accel&quot;
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>	xmlns:xlink
+CDATA #FIXED &quot;http://www.w3.org/1999/xlink&quot;
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>&gt;
+<BR><BR>
+
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>&lt;!ELEMENT
+accel:item EMPTY&gt;
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>&lt;!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; &quot;false&quot;
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>	accel:mod1
+%boolean; &quot;false&quot;
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>	accel:mod2
+%boolean; &quot;false&quot;
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>	xlink:href
+CDATA #REQUIRED
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>&gt;
+<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>&lt;?xml
+version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&gt;
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>&lt;!DOCTYPE
+library:libraries PUBLIC &quot;-//OpenOffice.org//DTD OfficeDocument
+1.0//EN&quot; &quot;libraries.dtd&quot;&gt;
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>
+&lt;library:libraries
+xmlns:library=&quot;http://openoffice.org/2000/library&quot;
+xmlns:xlink=&quot;http://www.w3.org/1999/xlink&quot;&gt;
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>
+ &lt;library:library library:name=&quot;Standard&quot;
+xlink:href=&quot;file:///home/al91857/StarOffice6.0/user/basic/Standard/script.xlb/&quot;
+xlink:type=&quot;simple&quot; library:link=&quot;false&quot;/&gt;
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>
+ &lt;library:library library:name=&quot;WebWizard&quot;
+xlink:href=&quot;file:///usr/dist/share/staroffice,v6.0/share/basic/WebWizard/script.xlb/&quot;
+xlink:type=&quot;simple&quot; library:link=&quot;true&quot;
+library:readonly=&quot;false&quot;/&gt;
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>
+ ...
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>
+&lt;/library:libraries&gt;
+<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>&lt;!ENTITY
+% boolean &quot;(true|false)&quot;&gt;
+<BR><BR>
+
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>&lt;!ELEMENT
+library:libraries (library:library)*&gt;
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>&lt;!ATTLIST
+library:libraries
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>	xmlns:library
+CDATA #FIXED &quot;http://openoffice.org/2000/library&quot;
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>	xmlns:xlink
+CDATA #FIXED &quot;http://www.w3.org/1999/xlink&quot;
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>&gt;
+<BR><BR>
+
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>&lt;!ELEMENT
+library:library EMPTY&gt;
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>&lt;!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>&gt;
+<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=&quot;Standard&quot;
+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>&lt;?xml
+version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&gt;
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>&lt;!DOCTYPE
+library:library PUBLIC &quot;-//OpenOffice.org//DTD OfficeDocument
+1.0//EN&quot; &quot;library.dtd&quot;&gt;
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>&lt;library:library
+xmlns:library=&quot;http://openoffice.org/2000/library&quot;
+library:name=&quot;Standard&quot; library:readonly=&quot;false&quot;
+library:passwordprotected=&quot;false&quot;&gt;
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>
+&lt;library:element library:name=&quot;Module1&quot;/&gt;
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>&lt;/library:library&gt;
+<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>&lt;!ENTITY
+% boolean &quot;(true|false)&quot;&gt;
+<BR><BR>
+
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>&lt;!ELEMENT
+library:library (library:element)*&gt;
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>&lt;!ATTLIST
+library:library
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>	xmlns:library
+CDATA #FIXED &quot;http://openoffice.org/2000/library&quot;
+<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>&gt;
+<BR><BR>
+
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>&lt;!ELEMENT
+library:element EMPTY&gt;
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>&lt;!ATTLIST
+library:element
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>	library:name
+CDATA #REQUIRED
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>&gt;
+<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>&lt;?xml
+version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&gt;
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>&lt;!DOCTYPE
+script:module PUBLIC &quot;-//OpenOffice.org//DTD OfficeDocument
+1.0//EN&quot; &quot;module.dtd&quot;&gt;
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>&lt;script:module
+xmlns:script=&quot;http://openoffice.org/2000/script&quot;
+script:name=&quot;Module1&quot; script:language=&quot;StarBasic&quot;&gt;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
+&amp;quot;alexis&amp;quot;
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>End
+Sub&lt;/script:module&gt;
+<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>&lt;!ELEMENT
+script:module (#PCDATA)&gt;
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>&lt;!ATTLIST
+script:module
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>	xmlns:script
+CDATA #FIXED &quot;http://openoffice.org/2000/script&quot;
+<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>&gt;
+<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 &nbsp;for &nbsp;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&nbsp;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>&nbsp;module)</li>
+        <li><i>offapi/drafts/com/sun/star/script&nbsp;</i><i>(drafts/com/sun/star/script,
+     </i>needs to be in the <i>offapi </i>&nbsp;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 &nbsp;and include the options <i>--with-jdk-home=&lt;PATH
+   TO JAVA&gt; &nbsp;--with-ant-home=&lt;PATH TO ANT&gt;</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, &nbsp;you will need add all jarfiles
+ under  <i>&lt;PATH  TO ANT&gt;/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 &nbsp;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&nbsp; offapi\drafts\com\sun\star\script\framework&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+   nmake&nbsp;&nbsp; -&nbsp;&nbsp; all oa_scriptf_drafts NULL</i></li>
+        <li><i>oa&nbsp; offapi\drafts\com\sun\star\script\framework\provider&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+   nmake&nbsp;&nbsp; - all oa_sfprovider_drafts NULL</i></li>
+        <li><i>oa&nbsp; offapi\drafts\com\sun\star\script\framework\storage&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+   nmake&nbsp;&nbsp; -&nbsp;&nbsp; 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&nbsp;</li>
+       
+  <ol>
+      <li>$(UCR)$/dcssscriptframework.db \&nbsp;</li>
+      <li>$(UCR)$/dcsssfprovider.db \&nbsp;</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 &nbsp;= &nbsp;$(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&nbsp; unoil\drafts\com\sun\star\script\framework&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+  nmake&nbsp;&nbsp; -&nbsp;&nbsp; all ul_scriptf_drafts ul_ucb ul_frame NUL</i>L&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+        <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>&lt;!-- &lt;pathelement location="${prj}/../unoil/${inpath}/class/unoil.jar"/&gt;
+  --&gt;</li>
+               
+  </ol>
+  <li>Comment out the line in java/build.xml:</li>
+  <ol>
+    <li>&lt;pathelement location="${solar.jar}/unoil.jar"/&gt;<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/&lt;PLATFORM&gt;.plt
+      </i>and <i>$pkg/</i><i>skip_registration (</i>Where <i>&lt;PLATFORM&gt;</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/&lt;platform&gt;/lib </i>to
+      <i>$pkg/</i><i>&lt;PLATFORM&gt;.plt</i></li>
+          <li>Copy in <i>ScriptRuntimeForJava.jar</i> from <i>scripting/&lt;platform&gt;/class</i>
+  into the top level directory,&nbsp;<i>$pkg</i></li>
+    <li>Copy in <i>unoil.jar </i>from <i>$pkg/</i><i>unoil/&lt;platform&gt;/class
+     </i>&nbsp;to      <i>skip_registration</i> directory<br>
+      </li>
+      <li>Merge the following registries from <i>offapi/&lt;platform&gt;/ucr 
+     </i>into one registry called <i>ooscript.rdb</i> under the top level 
+directory,&nbsp;<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,&nbsp;<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&nbsp;<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/&lt;platform&gt;/bin/</i><i>regsingleton</i>
+to your OpenOffice installation under the program directory<br>
+  </li>
+     <li>Execute the following:&nbsp;<font color="#ff0000"></font></li>
+           
+  <ol>
+       <li><i>./regsingleton &lt;OpenOffice Path&gt;/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 &lt;OpenOffice Path&gt;/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> &lt;OpenOffice 
+ Path&gt;/share/registry/data/org/openoffice/Office/</i>, add the following 
+ lines:</li>
+           
+  <ol>
+       <li>&lt;node oor:name="com.sun.star.comp.ScriptProtocolHandler" oor:op="replace"&gt;<br>
+   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
+ &lt;prop oor:name="Protocols"&gt;<br>
+   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
+ &lt;value&gt;script:*&lt;/value&gt;<br>
+   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
+ &lt;/prop&gt;<br>
+   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
+ &lt;/node&gt;<br>
+   Under the HandlerSet Tag</li>
+           
+  </ol>
+     
+</ol>
+   Unzip <i>HighlightTextParcel.sxp</i> from <i>scripting/examples/java </i>into 
+ <i>&lt;OpenOffice Path&gt;/user</i>, this should create a directory under 
+ <i>user </i>&nbsp;called <i>Scripts/java/HighlightText</i><br>
+   <br>
+   Now, run OpenOffice and under the <i>Tools-&gt;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>&lt;OpenOffice&gt;/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.&nbsp;</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.&nbsp;</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 &amp; 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.&nbsp;</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 &amp; 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 &amp; 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 &amp; 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 &amp; Interfaces</a>
+      </td>
+      <td valign="top">A very basic first attempt
+ to  define the necessary services &amp; 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



Mime
View raw message