Re: [api-dev] Using XDatabaseDocumentUI.loadComponent with BASIC

2009-01-09 Thread Fernand Vanrie

Marc Santhoff wrote:

Am Donnerstag, den 08.01.2009, 16:18 +0100 schrieb Fernand Vanrie:
  

Frank,

Is it also a reasonable RTF to asks that every SubComponent tables, 
Querys etc been protected by a password or a other protection sheme 
(from out the API)



I think you can achieve user rights discrimination by doing so in the
undelying database. It's a standard task for RDBMS.
  
Marc, you are right but when using OO-docs as a frontend-docs then the 
rights are distributed on base of who has acces to the Frontend-doc . 
So here the maker of the frondend-doc must decide wath is accesable 
for the frontend-doc-user . Think at  how spreadsheets are secured.

Greetz Fernand


Drew did and suggested some techniques, search the users and dev lists
(at dba).

HTH,
Marc



-
To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org
For additional commands, e-mail: dev-h...@api.openoffice.org
  



-
To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org
For additional commands, e-mail: dev-h...@api.openoffice.org



Re: [api-dev] Using XDatabaseDocumentUI.loadComponent with BASIC

2009-01-09 Thread Fernand Vanrie

Frank Schönheit - Sun Microsystems Germany wrote:

Hi Fernand,

  
Is it also a reasonable RTF to asks that every SubComponent tables, 
Querys etc been protected by a password or a other protection sheme 
(from out the API)



Not exactly sure ... Do you want to specify a password per
table/query/form/report? If so, what should be covered by this password?
Opening? Editing? using (e.g. using a pwd-protected query in a report)?

I *suppose* it's hard to come up with a consistent concept here. (Sure,
we could use some established concept like access control lists, but
that'd be overkill, for sure).

You see, I fail to see the overall picture how such a feature would look
like, could you elaborate?
  

Think on how Spreadsheets are protected.

DB-doc GUImodifing protection by password
DB-doc-SUBcomponent protection on GUI-USE (simpel: a Table, Query, 
Report, Form  can been used or not)


Greetz

Fernand 

Ciao
Frank

  



-
To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org
For additional commands, e-mail: dev-h...@api.openoffice.org



Re: [api-dev] Using XDatabaseDocumentUI.loadComponent with BASIC

2009-01-09 Thread Frank Schönheit - Sun Microsystems Germany
Hi Fernand,

 You see, I fail to see the overall picture how such a feature would look
 like, could you elaborate?
   
 Think on how Spreadsheets are protected.
 
 DB-doc GUImodifing protection by password
 DB-doc-SUBcomponent protection on GUI-USE (simpel: a Table, Query, 
 Report, Form  can been used or not)

Hmm, I think this comparison doesn't work here ...

When you password-protect a spreadsheet, then the user cannot open it by
any means. Not even by writing a macro to load it.

When you would password-protect, say, a query, then what would you
expect to happen when the user executes a report which uses the query to
fetch the data? Should it also request the password?

So, what exactly would you say should be protected for a query? Opening
it for data entry? That's easy to prevent from the UI, but 3 lines of
Basic code could do it, anyway. Preventing the Basic code approach would
be more difficult.
Even if you do so - 5 lines of Basic code could retrieve the SQL
statement which constitutes the query, and the same 3 lines from before
can display this statement.
Preventing *reading* the SQL statement which constitutes the query would
affect *all* places in Base: Every functionality which directly or
(especially) indirectly uses the query (not only in Base - think about
mail merging) would need to be prepared for access control - quite a
*huge* effort.

So, the bottom line is: Password protection on a per-object basis either
works for the most novice users only, or is extremely expensive to
implement.

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Base   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-
To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org
For additional commands, e-mail: dev-h...@api.openoffice.org



Re: [api-dev] Using XDatabaseDocumentUI.loadComponent with BASIC

2009-01-09 Thread Marc Santhoff
Am Freitag, den 09.01.2009, 09:33 +0100 schrieb Fernand Vanrie:
 Marc Santhoff wrote:
  Am Donnerstag, den 08.01.2009, 16:18 +0100 schrieb Fernand Vanrie:

  Frank,
 
  Is it also a reasonable RTF to asks that every SubComponent tables, 
  Querys etc been protected by a password or a other protection sheme 
  (from out the API)
  
 
  I think you can achieve user rights discrimination by doing so in the
  undelying database. It's a standard task for RDBMS.

 Marc, you are right but when using OO-docs as a frontend-docs then the 
 rights are distributed on base of who has acces to the Frontend-doc . 
 So here the maker of the frondend-doc must decide wath is accesable 
 for the frontend-doc-user . Think at  how spreadsheets are secured.
 Greetz Fernand

I understand your intention, but since it isn't possible to do so it may
be sufficient to let the underlying database reject the execution of
queries and the change or even retrieval of tables (data).

Another approach could be to hide the docs from the gui by removing from
the lists shown, but really don't know if that's possible.

HTH,
Marc



-
To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org
For additional commands, e-mail: dev-h...@api.openoffice.org



[api-dev] Re: [dev] FOSDEM 2009: Call for Papers for our OpenOffice.org DevRoom

2009-01-09 Thread Juergen Schmidt

REMINDER REMINDER REMINDER REMINDER REMINDER REMINDER REMINDER REMINDER

just a friendly reminder that you should send me your proposals until 
tomorrow. I promise some fun in Brussels and Leo will probably guide us 
into a small nice restaurant as last year. Did i mentioned that the 
Belgium beer is excellent ;-)


Juergen

Juergen Schmidt wrote:
FOSDEM - the Free and Open Source Developer's European Meeting - is 
nearly upon us. FOSDEM is the most developer-focused FOSS conference, 
and will take place in Brussels, Belgium on 6th/7th February (not 
forgetting the FOSDEM beer event on the Friday night  :) . Geeks from 
all the major FOSS projects are expected to be there - including 
OpenOffice.org.


If you are an experienced OpenOffice.org developer, we need your help!

OpenOffice.org will have again a DevRoom at FOSDEM. The main goal of the 
DevRoom is to attract developers to work on and with OpenOffice.org. We 
want to show developers that there is nothing magic about OpenOffice.org 
development, and that our active and enthusiastic developer community is 
keen to help newcomers.


We want to help developers get started on the code - by explaining how 
the source code is structured and how our build environment works. We're 
also keen to show developers how to integrate OpenOffice.org in their 
own applications, using interfaces, APIs, components, etc. We want to 
encourage developers to produce exciting new extensions for OpenOffice.org.


If you are able to share your in-depth technical knowledge and 
enthusiasm then please get in touch without delay. We are looking for 
people who can:


- give a 45 minute talk; or
- run 90 or 120 minute workshops

Please send your proposals (see below) to juergen.schmidt (at) sun.com 
as soon as possible - by the end of this week (latest Saturday 10th).


Make it your New Year's Resolution to recruit a new developer in 2009 - 
and help us start the ball rolling at FOSDEM in February.


Proposals
=
Your proposal should include
- a title
- a short abstract
- your full name
- a short bio of you and ideally your role in the OpenOffice.org project
- request for sponsorship (travel, lodging)

We know that we are again a little bit late this year and that it is 
short-time. But we promise to improve it next year ;-)



Thanks in advance

Juergen


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org




-
To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org
For additional commands, e-mail: dev-h...@api.openoffice.org



Re: [api-dev] XComponentLoader.ComponentFromURL throws IllegalArgumentException: URL seems to be an unsupported one.

2009-01-09 Thread Andreas Schlüns

Hi Albert,

Why do you load the file using private:stream instead of using the 
original file:///-URL ? Let OOo do that stream stuff internaly. Loading 
via stream is supported but detection of pure streams without any hint 
about the URL or the mime type will fail very often ... especialy if 
ambigous formats like Text/Html or XML will be used :-)


Regards
Andreas


Hi Albert,

your code works fine for me. Of course, I used only a simple odt 
document. Perhaps the filter for loading the docx document cannot be 
determined. You can add this to the properties for loadComponentFromUrl, 
the name of the property is FilterName, the value the name of the filter 
you'd like to use.


Regards, Steffen


Albert Law wrote:

Hi,
Me, again.  :)

I'm having problems with XComponentLoader.ComponentFromURL where it is 
loading from an XinputStream.  I'm a bit paranoid and don't
want this to be a reoccurance of bug 75191 ( 
http://www.openoffice.org/issues/show_bug.cgi?id=75191 ).  Can anyone 
see what I could

have possibly done wrong in the following code?  Thanks!

ps: The ultimate goal is to load from a byte[].  This seemed to be a 
good first step.


pps: Nothing is null and the file does exist.  In fact, I have 
successfully loaded from a URL via XComponent xComponent =
xComponentLoader.loadComponentFromURL(file:///c:/test.docx, 
_blank, 0, loadProps); where loadProps is empty.


ppps: I'm using the most recent version of everything.


[begin]
XComponentContext xContext = Bootstrap.bootstrap();
XMultiComponentFactory xServiceManager = xContext.getServiceManager();
Object desktop = 
xServiceManager.createInstanceWithContext(com.sun.star.frame.Desktop, 
xContext);
XComponentLoader xComponentLoader = 
(XComponentLoader)UnoRuntime.queryInterface(XComponentLoader.class, 
desktop);
XSimpleFileAccess xSimpleFileAccess = 
(XSimpleFileAccess)UnoRuntime.queryInterface(XSimpleFileAccess.class,
xServiceManager.createInstanceWithContext(com.sun.star.ucb.SimpleFileAccess, 
xContext));
XInputStream xInputStream = 
xSimpleFileAccess.openFileRead(file:///c:/test.docx);

PropertyValue[] loadProps = new PropertyValue[1];
loadProps[0] = new PropertyValue();
loadProps[0].Name = InputStream;
loadProps[0].Value = xInputStream;
XComponent xComponent = 
xComponentLoader.loadComponentFromURL(private:stream, _blank, 0, 
loadProps);

[end]


leads to (line numbers are off, of course):
com.sun.star.lang.IllegalArgumentException: URL seems to be an 
unsupported one.
at 
com.sun.star.lib.uno.environments.remote.Job.remoteUnoRequestRaisedException(Job.java:182) 

at 
com.sun.star.lib.uno.environments.remote.Job.execute(Job.java:148)
at 
com.sun.star.lib.uno.environments.remote.JobQueue.enter(JobQueue.java:344) 

at 
com.sun.star.lib.uno.environments.remote.JobQueue.enter(JobQueue.java:313) 

at 
com.sun.star.lib.uno.environments.remote.JavaThreadPool.enter(JavaThreadPool.java:101) 

at 
com.sun.star.lib.uno.bridges.java_remote.java_remote_bridge.sendRequest(java_remote_bridge.java:652) 

at 
com.sun.star.lib.uno.bridges.java_remote.ProxyFactory$Handler.request(ProxyFactory.java:154) 

at 
com.sun.star.lib.uno.bridges.java_remote.ProxyFactory$Handler.invoke(ProxyFactory.java:136) 


at $Proxy3.loadComponentFromURL(Unknown Source)
at com.snowbound.testOOUno.main(testOOUno.java:223)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 

at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) 


at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.star.lib.loader.Loader.main(Loader.java:144)





-
Albert


-
To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org
For additional commands, e-mail: dev-h...@api.openoffice.org




-
To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org
For additional commands, e-mail: dev-h...@api.openoffice.org



-
To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org
For additional commands, e-mail: dev-h...@api.openoffice.org



RE: [api-dev] XComponentLoader.ComponentFromURL throws IllegalArgumentException: URL seems to be an unsupported one.

2009-01-09 Thread Albert Law
Hi Andreas,

I am using this method as it is good way to later integrate a
solution that will load from a byte array.  Am I going about this the
wrong way?  How should I load a DOCX file which is stored in a Java
byte array into an OO XComponent?  Do I even need an XComponent?



-
Albert

-Original Message-
From: Andreas Schlüns [mailto:andreas.schlu...@sun.com] 
Sent: Friday, January 09, 2009 06:15
To: dev@api.openoffice.org
Subject: Re: [api-dev] XComponentLoader.ComponentFromURL throws 
IllegalArgumentException: URL seems to be an unsupported one.

Hi Albert,

Why do you load the file using private:stream instead of using the 
original file:///-URL ? Let OOo do that stream stuff internaly. Loading 
via stream is supported but detection of pure streams without any hint 
about the URL or the mime type will fail very often ... especialy if 
ambigous formats like Text/Html or XML will be used :-)

Regards
Andreas

 Hi Albert,
 
 your code works fine for me. Of course, I used only a simple odt 
 document. Perhaps the filter for loading the docx document cannot be 
 determined. You can add this to the properties for loadComponentFromUrl, 
 the name of the property is FilterName, the value the name of the filter 
 you'd like to use.
 
 Regards, Steffen
 
 
 Albert Law wrote:
 Hi,
 Me, again.  :)

 I'm having problems with XComponentLoader.ComponentFromURL where it is 
 loading from an XinputStream.  I'm a bit paranoid and don't
 want this to be a reoccurance of bug 75191 ( 
 http://www.openoffice.org/issues/show_bug.cgi?id=75191 ).  Can anyone 
 see what I could
 have possibly done wrong in the following code?  Thanks!

 ps: The ultimate goal is to load from a byte[].  This seemed to be a 
 good first step.

 pps: Nothing is null and the file does exist.  In fact, I have 
 successfully loaded from a URL via XComponent xComponent =
 xComponentLoader.loadComponentFromURL(file:///c:/test.docx, 
 _blank, 0, loadProps); where loadProps is empty.

 ppps: I'm using the most recent version of everything.


 [begin]
 XComponentContext xContext = Bootstrap.bootstrap();
 XMultiComponentFactory xServiceManager = xContext.getServiceManager();
 Object desktop = 
 xServiceManager.createInstanceWithContext(com.sun.star.frame.Desktop, 
 xContext);
 XComponentLoader xComponentLoader = 
 (XComponentLoader)UnoRuntime.queryInterface(XComponentLoader.class, 
 desktop);
 XSimpleFileAccess xSimpleFileAccess = 
 (XSimpleFileAccess)UnoRuntime.queryInterface(XSimpleFileAccess.class,
 xServiceManager.createInstanceWithContext(com.sun.star.ucb.SimpleFileAccess,
  
 xContext));
 XInputStream xInputStream = 
 xSimpleFileAccess.openFileRead(file:///c:/test.docx);
 PropertyValue[] loadProps = new PropertyValue[1];
 loadProps[0] = new PropertyValue();
 loadProps[0].Name = InputStream;
 loadProps[0].Value = xInputStream;
 XComponent xComponent = 
 xComponentLoader.loadComponentFromURL(private:stream, _blank, 0, 
 loadProps);
 [end]


 leads to (line numbers are off, of course):
 com.sun.star.lang.IllegalArgumentException: URL seems to be an 
 unsupported one.
 at 
 com.sun.star.lib.uno.environments.remote.Job.remoteUnoRequestRaisedException(Job.java:182)
  

 at 
 com.sun.star.lib.uno.environments.remote.Job.execute(Job.java:148)
 at 
 com.sun.star.lib.uno.environments.remote.JobQueue.enter(JobQueue.java:344) 

 at 
 com.sun.star.lib.uno.environments.remote.JobQueue.enter(JobQueue.java:313) 

 at 
 com.sun.star.lib.uno.environments.remote.JavaThreadPool.enter(JavaThreadPool.java:101)
  

 at 
 com.sun.star.lib.uno.bridges.java_remote.java_remote_bridge.sendRequest(java_remote_bridge.java:652)
  

 at 
 com.sun.star.lib.uno.bridges.java_remote.ProxyFactory$Handler.request(ProxyFactory.java:154)
  

 at 
 com.sun.star.lib.uno.bridges.java_remote.ProxyFactory$Handler.invoke(ProxyFactory.java:136)
  

 at $Proxy3.loadComponentFromURL(Unknown Source)
 at com.snowbound.testOOUno.main(testOOUno.java:223)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
  

 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
  

 at java.lang.reflect.Method.invoke(Method.java:597)
 at com.sun.star.lib.loader.Loader.main(Loader.java:144)





 -
 Albert


 -
 To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org
 For additional commands, e-mail: dev-h...@api.openoffice.org


 
 -
 To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org
 For additional commands, e-mail: dev-h...@api.openoffice.org
 

-
To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org
For additional commands, e-mail: 

Re: [api-dev] Re: [dev] FOSDEM 2009: Call for Papers for our OpenOffice.org DevRoom

2009-01-09 Thread Alain Rist

Hi Juergen,

Just posted Integrate the OpenOffice.org power in a WTL (or other native 
WIN32) application at http://www.codeproject.com/KB/wtl/Wtl_OOo.aspx.


If it is of interest to you, I can make a presentation.

cheers,
Alain


- Original Message - 
From: Juergen Schmidt juergen.schm...@sun.com

To: d...@openoffice.org
Cc: dev@api.openoffice.org; d...@extensions.openoffice.org; 
d...@marketing.openoffice.org; confere...@marketing.openoffice.org; 
disc...@openoffice.org

Sent: Friday, January 09, 2009 10:50 AM
Subject: [api-dev] Re: [dev] FOSDEM 2009: Call for Papers for our 
OpenOffice.org DevRoom




REMINDER REMINDER REMINDER REMINDER REMINDER REMINDER REMINDER REMINDER

just a friendly reminder that you should send me your proposals until 
tomorrow. I promise some fun in Brussels and Leo will probably guide us 
into a small nice restaurant as last year. Did i mentioned that the 
Belgium beer is excellent ;-)


Juergen

Juergen Schmidt wrote:
FOSDEM - the Free and Open Source Developer's European Meeting - is 
nearly upon us. FOSDEM is the most developer-focused FOSS conference, and 
will take place in Brussels, Belgium on 6th/7th February (not forgetting 
the FOSDEM beer event on the Friday night  :) . Geeks from all the major 
FOSS projects are expected to be there - including OpenOffice.org.


If you are an experienced OpenOffice.org developer, we need your help!

OpenOffice.org will have again a DevRoom at FOSDEM. The main goal of the 
DevRoom is to attract developers to work on and with OpenOffice.org. We 
want to show developers that there is nothing magic about OpenOffice.org 
development, and that our active and enthusiastic developer community is 
keen to help newcomers.


We want to help developers get started on the code - by explaining how 
the source code is structured and how our build environment works. We're 
also keen to show developers how to integrate OpenOffice.org in their own 
applications, using interfaces, APIs, components, etc. We want to 
encourage developers to produce exciting new extensions for 
OpenOffice.org.


If you are able to share your in-depth technical knowledge and enthusiasm 
then please get in touch without delay. We are looking for people who 
can:


- give a 45 minute talk; or
- run 90 or 120 minute workshops

Please send your proposals (see below) to juergen.schmidt (at) sun.com as 
soon as possible - by the end of this week (latest Saturday 10th).


Make it your New Year's Resolution to recruit a new developer in 2009 - 
and help us start the ball rolling at FOSDEM in February.


Proposals
=
Your proposal should include
- a title
- a short abstract
- your full name
- a short bio of you and ideally your role in the OpenOffice.org project
- request for sponsorship (travel, lodging)

We know that we are again a little bit late this year and that it is 
short-time. But we promise to improve it next year ;-)



Thanks in advance

Juergen


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org




-
To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org
For additional commands, e-mail: dev-h...@api.openoffice.org





-
To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org
For additional commands, e-mail: dev-h...@api.openoffice.org