Ariel Constenla-Haile wrote:
Hi Frank, Andrew,
Frank Schönheit - Sun Microsystems Germany escribió:
Hi Andrew,
* concerning the script URI, have you reached a final conclusion
here? I agree with Frank that a adding a new value for the location
parameter isn't the best idea.
Why? What would be wrong with having a location of 'container', for
instance. All the other designators mean exactly what they mean
today, if you open an odb file under an installation that does not
support embedded script libraries in the odb file, it is going to
break- but then it should break.
We would need a balance between a DB-specific, non-scaling notion, and a
future-proof but nearly unusable notion.
"container" is DB specific, in the sense that it means "the macro in the
document which is the parent of the current document". Hmm. What if
there will be more than one hierarchy level next year? Will we introduce
"container_container" then?
On the other hand, does it really make sense to care for multiple
hierarchy levels? Will this ever happen? Or will we make implementations
unnecessary difficult by accounting for it?
Approaching it from the UX side:
Would the following be reasonable?
When you have the macro selector (that is, the tree view displaying your
macros, no matter in which context), you see the complete DB hierarchy:
+- My Macros
+- OpenOffice.org Macros
+- Database Document
+- Forms
| +- Form 1
| | + Library 1
| +- Form 2
| +- Library 2
+- Reports
+- Report 1
...
... this can even be more complex: we all know the DocumentContainer -
DocumentDefinition relationship can be a very complex hierarchical
structure of folders within other folders (... does the "common" user
"use" this feature? in rare occasions I've seen just only one
subfolder... )
That'd be cool, wouldn't it? It would imply a location like
"document/forms/form1" in the URI.
However, does it make sense to execute a macro embedded in report 1,
from within form 1? Probably not.
Okay, forget this.
So, we would need
+- My Macros
+- OpenOffice.org Macros
+- Database Document
+- Current Form/Report
Which looks like we might indeed need one special location type only.
Reading the above tree, I doubt we will ever have a need for a full
location hierarchy, so "location=container" would be sufficient.
On the other hand, there was a time when 640K were considered to be
sufficient for all times, too.
I think I need to also discuss this with some framework people, who know
more about the scripting framework than I do. Which explicitly does
*not* mean you guys should not keep your ideas coming - they really help
getting a picture here!
ok.
Just to add a point: we are talking about the URI to be used by the
scripting framework.
There is also another problem:
what will happen when calling a subroutine/function from within the
odb/forms?
will we be able to call a function located in an embedded
form-document from another embedded form-document (both embedded in
the same odb), or just from form-document to its parent - the
DatabaseDocument?
and the other way around: calling from the parent a function within
its child?
what will be the behavior when calling a macro with the same name
existing in three different places at the time: a module in the
DatabaseDocument,in a form, in the user's library?
I answer myself: these all will be addressed by the same of
implementation solving the URI problem (I guess - I don't know how the
scripting framework works internally, and if it works the same way
with every scripting binding :-( ).
Well, you can do that today.
Lets say I have 'Library1' and 'Library2' each has a 'Module1' and a
method 'Main'
I can differentiate the two Main sub procedures with
Library1.Module1.Main
Library2.Module2.Main
Now lets say I have a 'Form2' and it has a library 'Standard', a
'Module1' and a method 'Main'
You simply have to get a reference to the forms script provider.
Dim aArgs(0) As New com.sun.star.beans.PropertyValue
Dim oForm as variant
Dim oScriptProvider as variant
Dim oMethod as variant
oForm = db.forms.looadfromURL( "Form1", .....)
' get form ScriptProvider
oScriptProvider = oForm.ScriptProvider()
oMethod = oScriptProvider.getScript( _
"vnd.sun.star.script:Standard.Module1.Main?language=Basic&location=*document*")
oMethod.invoke(Array(),Array(),Array())