Hi Frank,
Frank Schönheit escribió:
Hi Ariel,
* concerning the script URI, have you reached a final conclusion here?
no.
...
It will be very likely that users will have subroutines with the same
name in a form and in its parent ODB document. Without adding anything
new, wouldn't it be "logical" if the implementation looks for the macro
pointed to this URI using just the "parental hierarchy"?: first the
parent (of the parent of the parent ... ) of the control == the form
document, *then* its parent == the database document.
I think this approach will be "logical" to the user, without having to
change the URI schema
We had a mechanism like this up to 1.1 (IIRC - or was it even we did
this change before OOo 1.0?). A macro specification was simply something
like "Libarary.Module.Function". If a macro like this was
referred/executed from within a document, then the runtime would first
look into the document's, and, if unsuccessful there, into the
application's Basic.
The problem with this approach is that documents are prone to breakage,
in that if you rename the "inner" function to something else, but by
accident there's a function with the same name in the "outer" scope,
then *some* macro will still be executed (instead of giving an error
message), but probably not the macro you expected.
Thus, we decided to switch to a more explicit notion.
That said, the approach you sketch would work, of course, and there
won't be too many occasions where it really screws your macros up in the
way described above.
But still, it's magic (in this case magic we already decided in the past
is bad), and magic tends to break easily.
I see the point here... magic is no good idea! :-)
* second question, although we talk all the time here about "macros" (my
mistake also on my the report to issue 7612
http://www.openoffice.org/issues/show_bug.cgi?id=76129), will the
implementation support other scripting languages (and my personal
interest: NON scripting ones == Java)? I know that now in OOo embedding
Java and Python has to be done "by hand", so I won't ask you for this
feature ;-) , and I will keep doing it "by hand" (using
TransientDocumentsContentProvider for currently open docs.and
PackageContentProvider when they are closed), so creating the folders
won't be a problem, and using the API OOo will recognize them (no need
here even to touch the manifest);
but will the URIs be recognized by the new implementation (for example
"vnd.sun.star.script:MyJavaFolder.ar.com.arielconstenlahaile.MyPackage.myMethod?language=Java&location=document")?
They should. In general, we plan to use the same components as the other
applications do. In particular, executing a script which is given by URI
is the task of the scripting framework, which is then responsible for
finding the proper script provider, and the like. So, as long as you use
the standard URI notion, everything should work fine.
I wanted to mean: once I embed my Jar (and the parcel-descriptor.xml),
will we be able to see it when trying to bind it to a control's event in
the GUI?
I answer myself: as you are using the same components as the other
apps., we should - in theory - be able to perform event binding via GUI.
There's two uncertainties here:
First, I am not sure whether the various script provider implementations
do some weird and dirty hacks to execute macros. I *know* for sure that
the Basic provider does,
uou that's surprising! I remember your comments about "strange",
"infamous", "stupidly-used" code - now add to the list "weird and dirty".
In this situation, it isn't hard to understand why you are working in it
since April, sure not all the time... but ... it seems like someone, one
day, will have to start doing some sweeping and cleaning in the sources.
Resources are always few, but won't cleaner-up-to-date-pure-UNO code
make your - core developers' - life easier? :-)
and needs to be fixed before it will be able to
execute .odb-embedded macros. I do not know in detail about the others.
Second, the location problem applies here, too: Doesn't matter whether
we invent a new location attribute value, or apply magic (or find
something completely different): In every case, the providers probably
need to be adjusted to care for the new feature. Which might or might
not be difficult - I don't know the provider implementations so far.
Overall, this might be a candidate for a second step. If implementing
support for embedding Java/Python makes the difference between meeting
and not meeting the 3.0 deadline with the whole feature, then we will
not implement it in the first run.
I thought the "macros in ODB" feature was for 2.4, am I wrong? or is it
for 3.0 ? ( I didn't understand the "3.0 deadline" thing :-( )
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]
