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
...
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!
Ciao
Frank
--
- Frank Schönheit, Software Engineer [EMAIL PROTECTED] -
- Sun Microsystems http://www.sun.com/staroffice -
- OpenOffice.org Base http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
