Issue 21150 - Q-PCD Programmability-4: UNO ease of Use
Summary: Q-PCD Programmability-4: UNO ease of Use
Status: CLOSED FIXED
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: OOo 1.0.0
Hardware: Other Other OS
: P4 Trivial (vote)
Target Milestone: OOo 2.0
Assignee: Stephan Bergmann
QA Contact: issues@framework
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-10-14 08:11 UTC by kay.ramme
Modified: 2010-10-23 06:10 UTC (History)
1 user (show)

See Also:
Issue Type: FEATURE
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description kay.ramme 2003-10-14 08:11:03 UTC
Product Requirement 
Simplified OOo API Create Helper classes to ease working with the Office API /
UNO Provide an easier API to enable low skill developers to program OOo Function
is to simplify coding tasks for Java developers using UNO, by providing
appropriate wrapper APIs. Map UNO types to Java language concepts (e.g.
XPropertySet -> PropertySet) Provide a more natural binding of UNO into
programming languages, i.e. eliminating the queryInterface.

Customer Need/Problem
Developers need task oriented high-level APIs that can be mixed with regular UNO
API calls. The goal of these high-level APIs is to make OOo development easier
and much more intuitive. The OOo UNO API has some language concepts that are
similar to some Java concepts. However UNO does not use the respective Java
objects. Its confusing for developers to deal with two independent sets of
objects that fulfill similar tasks. From a Java developers perspective the UNO
API looks clunky and complex. The UNO API should provide interfaces or wrappers
that make OOo development more intuitive for Java developers.

Product Concept
This can be divided into three parts, the first being ease of use of UNO itself,
second is having a smoother language integration and third we need to simplify
the OOo API. The following points are only suggestions and may be used as
starting points:  
UNO ease of use: 
 - remove ?queryInterface? 
 - reduce ?Any? usage   
 - introduce IDL-Templates 
 - introduce IDL-GlobalFunctions 
 - map service concept to concrete types (e.g. Interfaces) 
 - consistent and correct naming  
 - simplified resource management/object lifecycle 
 - support single threaded/not threading aware components 
 - ...  
Enhance Language Integration: 
 - Java   
 - smart mapping of types, classes and interfaces   
 - use ?instanceof? for optional interfaces   
 - support Java semantics were possible   
 - ...  
- C++   
 - support ?new? for Service instantiation   
 - implicitly pass the component context   
 - use ?dynamic casts? for optional interfaces   
 - ...  
Simplify OOo API: 
 - look how other office APIs work 
 - use defaults 
 - use global functions 
 - reuse well-known concepts
Comment 1 kay.ramme 2003-10-14 08:13:22 UTC
.
Comment 2 lutz.hoeger 2003-10-23 07:44:31 UTC
added keyword Q-PCD
Comment 3 kay.ramme 2003-11-11 10:58:56 UTC
Stephan, this is yours :-).
Comment 4 Stephan Bergmann 2003-11-11 12:08:32 UTC
Concentrating on the "UNO ease of use: map service concept to concrete
types (e.g. Interfaces)" part.
Comment 5 Stephan Bergmann 2004-02-10 11:07:20 UTC
In agreement with KR, this task is now only about "UNO ease of use: map service
concept to concrete types (e.g. Interfaces)."  That boils down to:
1  Introduce multiple-inheritance interface types, to serve as a replacement for
abstract UNOIDL service descriptions.  Done, see internal bug #114000#.
2  Expand interface type attributes, to serve as a replacement for UNOIDL
service description properties.
3  Introduce a new UNOIDL "component" construct, to serve as a replacement for
instantiatable UNOIDL service descriptions.  In language bindings, generate code
for such components (e.g., static XSomeInterface
com.sun...SomeComponent.create(XComponentContext)).
4  Update Dev. Guide.
A next big step would be the introduction of generics/templates into UNO.  It is
unclear whether this can be done in the OOo 2.0 timeframe.
Comment 6 Stephan Bergmann 2004-03-17 08:08:18 UTC
See sub issue 26602 for the next incremental step.  Subsequent tasks are:
-  Adapt Java--langugage-binding UNO-type reflection to new UNO features.
-  Adapt auxiliary tools to new type registry (registry/tools, rdbmaker).
-  Add simple generic structs to UNO, that can be used to model maybevoid etc.
properties in the type system.  In C++, map them to templates.  In Java, map
them to Object-polymorphism, with the future option of changing javamaker to
directly generate class files, and use the Java 1.5 generic features in those
class files.
-  Offer helpers in the C++ and Java language bindings that reflectively
implement XPropertySet etc. on top of UNO interface attributes.
-  Retrofit existing udkapi/offapi services/singletons as
(single-)interface--based ones.
-  Update DevGuide.
Comment 7 Stephan Bergmann 2004-06-01 09:34:02 UTC
Fixed.  The last three items of the previous to-do list are tracked by
individual issues:
helpers: issue 29740
retrofitting: issue 29741
DevGuide: issue 29742
Comment 8 Stephan Bergmann 2004-06-01 09:34:32 UTC
closed
Comment 9 Unknown 2010-10-23 06:10:06 UTC
Created attachment 72301