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 :-( ).
Bye and thanks,
Ariel.
--
Ariel Constenla-Haile
La Plata, Argentina
[EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.arielconstenlahaile.com.ar/ooo/
"Aus der Kriegsschule des Lebens
- Was mich nicht umbringt,
macht mich härter."
Nietzsche Götzendämmerung, Sprüche und Pfeile, 8.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
