Using sap.m.TablePersoProvider abstract class

hi all,
i have to use a table personalization. i have seen in the API that i can use the TablePersoProvider.
but this is an abstract class.
how I am able to use this abstract class in Javascript?
Best Regards,
Alexander

Hi Mario,
Good idea, really! It'll make your life easier any time you need to work with Characteristics. But...
I wouldn't use that class if I were you... On our ECC 6.0 it's "Released Internally" (Class Properties > General Data). This means it's released only for internal use of SAP, not for customers.
You can still build the framework implementing Characteristics BAPIs.
Regards,
Andres.

Similar Messages

  • When to use interface and when Abstract Class?

    In a recent interview I was asked "When to use interface and when Abstract Class?" Explain with an example.
    Also in what situations a class should be made final(real time example)

    Interface is a pure contract with no implementation. Typically used to define a communication contract between two different sub-systems. Example EJB home interface. This also allows the design to change as long as the contract is met.
    Abstract class is when there exists a lot of common functionality already known and can be coded. However, a few unknowns exists (typically about data) for which abstract methods need to be defined and implemented by the sub class.
    Example: Consider a workflow engine. A great example for abstract class. The workflow process has lot of common code that is independent of the workflow type (vendor flow, contract flow, payment flow etc). However, certain decisions on the route to take will depend on value of data being submitted. So the base class will define a abstract Data getData() method and proceed assuming data will come. The implementing subclass will provide the actual logic for getting the data.
    Also see the "Template" design pattern.
    Note: To some extent the common code design drives the behavior of the abstract methods. So if the design changes then so "might" the behavior expected from the abstract methods.

  • How to use function of an abstract class??

    Hi all,
    I want to use the format(object obj) function of the package java.text.Format. But as the Format class is an abstract class i could not instantiate it, so that i can call the format(object obj) method using the dot(.) operator.
    I know what is an abstract class. i've studied and tried to understand. as everybody knows, studied the perfect example(because i've read it in all the abstract class tutorial, books) of the Shape class. But still i dont understand how am i going to use that format(object obj) method. Please help me..

    Instead of using the abstract class Format use the
    concrete classes DecimalFormat
    SimpleDateFormat etc check java.text APIS
    http://java.sun.com/j2se/1.4.2/docs/api
    Hi!! Thanks both of you.
    If Sun has a abstract class then there must be a
    concrete class which extends that abstract class .It
    is always better to check the APIWhat do you mean by this line. Is it true for all the abstract classes in the jdk?

  • Using common methods with abstract classes

    hello everyone, i wanted to know if it is bad practice (i imagine it is) to place methods which will be used by multiple classes (computational methods) in an abstract class and mark them as static. When i do this they are always project wide utility classes which dont need an instantiation. When using any of these methods which are common to a project i can then just use..
    Type result = ClassName.DoStaticMethod(...);Thanks for any input,
    Dori
    Edited by: Sir_Dori on Dec 8, 2008 2:01 AM

    Depends on what the methods are meant to do, but I wouldn't make the class abstract. I would instead declare it to be final and have a private constructor.
    Kaj
    Ps. Take a look at the java.lang.Match class.

  • A Singleton variable in an Abstract Class

    Hello there people
    I have a quick question. I have made an abstract class in which I want to put an identifier (ID) int to be incremented whenever I make any of the concrete class instances that extend this abstract class.
    whould that declairation be as follows?:
    public static int IDAdditionally, I have a quick question about abstract constructors. If constructors are defined in the concrete classes, are their declairations needed in the abstract class?
    and finally, if I wanted to use the int ID (as mentioned above) then would I have to use constructor from the abstract class?
    thanks in advance for the help

    I think the OP would want a constructor in the abstract class to update that variable. Otherwise, he'd have to remember to update it in the constructor for all concrete classes. But, you don't declare constructors for the concrete class in the abstract class. You only declare constructors for the abstract class in the abstract class.

  • Hi all,Interface vs Abstract class

    Hi, All When We are going to use interface or an Abstract class,Can tell exactly
    Thanks in advance

    Interface class is used to contain methods that is to be defined by children classes. And abstract class, even though you can have all methods being abstract, but normally I would use this class for situation such as implement methods that are general enough to be used by the children classes and left others being abstract to be implemented by children classes later. I always think this relationship in a simple way:
    Abstract Class: Animal
    Interface : Leg, Tail, Hair, Feather, Head...
    Children classes: Tiger, Bird, etc.
    Thus, for class Animal class you can have methods such as:
    Abstract: canRoar, canSing, canFly, ...
    Non-abstract: isSleeping, isAlive...
    More example:
    Tiger extends Animal implements Leg, Tail, Head, Hair
    Bird extends Animal implements Leg, Feather, Head
    I could be wrong, correct me if so. Cheers.

  • Method inheritence from abstract classes, and arguments

    I'm trying to do something a little weird. I'm writing a pretty complicated wrapper/adapter for two platforms, and I'd like to have an abstract method passed on to child classes, but with the type of the single argument specified by the child class. Is this possible?
    Example
    public abstract class AbstractParent {
    public abstract void foo([ambiguousType] arg);
    public class ChildOne extends AbstractParent {
    public void foo(TypeA arg) {
    //body
    public class ChildTwo extends AbstractParent {
    public void foo(TypeB arg) {
    //body
    }TypeA and TypeB have no common supertype beyond Object, and I'd rather not just do instanceof checks and throw errors. Does anyone know of a solution? Can I elaborate any better?

    Perhaps you could use generics?
        public abstract class AbstractParent<E> {
            public abstract void foo(E arg);
        public abstract class ChildOne extends AbstractParent<String> {
            public void foo(String arg) {
        public abstract class ChildTwo extends AbstractParent<Integer> {
            public void foo(Integer arg) {
        }

  • EJB question: How to use abstract class in writing a session bean?

    I had written an abstract class which implements the session bean as follow:
    public abstract class LoggingSessionBean implements SessionBean {
    protected SessionContext ctx;
    protected abstract Object editRecord(Object obj) throws Exception;
    public LoggingSessionBean()
    super();
    private final String getBeforeUpdateImage(Object obj) throws Exception {
    // implement the details of extracting the backup image ...
    public void setSessionContext(SessionContext ctx)
    this.ctx = ctx;
    private final void writeThisImageToDatabase(String aStr) {
    // connect to database to write the record ...
    public final Object update(final Object obj) {
    try {
    final String aStr = getBeforeUpdateImage(obj);
    writeThisImageToDatabase(aStr);
    editRecord(obj);
    } catch (Exception e) {
    ctx.setRollbackOnly();
    This abstract class is to write the backup image to the database so that other session beans extending it only need to implement the details in editRecord(Object Obj) and they do not need to take care of the operation of making the backup image.
    However, some several questions for me are:
    1. If I write a class ScheduleSessionBean extending the above abstract class and the according 2 interfaces ScheduleSession and ScheduleSessionHome for this session bean (void update(Object obj); defined in ScheduleSession), do I still need to write the interfaces for LoggingSession and LoggingSessionHome?
    2. If I wrote the interface LoggingSession extending EJBObject where it defined the abstract methods "void update(Object obj);" and "void setSessionContext(SessionContext ctx);", that this meant I needed to write the ScheduleSession to implement the Logging Session?
    3. I used OC4J 9.0.4. How can I define the ejb-jar.xml in this case?

    Hi Maggie,
    1. do I still need to write
    the interfaces for LoggingSession and
    LoggingSessionHome?"LoggingSessionBean" can't be a session bean, because it's an abstract class. Therefore there's no point in thinking about the 'home' and 'remote' interfaces.
    2. this
    meant I needed to write the ScheduleSession to
    implement the Logging Session?Again, not really a question worth considering, since "LoggingSessionBean" can't be an EJB.
    3. I used OC4J 9.0.4. How can I define the
    ejb-jar.xml in this case?Same as you define it for any version of OC4J and for any EJB container, for that matter, since the "ejb-jar.xml" file is defined by the EJB specification.
    Let me suggest that you create a "Logging" class as a regular java class, and give your "ScheduleSessionBean" a member that is an instance of the "Logging" class.
    Alternatively, the "ScheduleSessionBean" can extend the "Logging" class and implement the "SessionBean" interface.
    Good Luck,
    Avi.

  • I have used SAP doc mgmt for years. We copied a client and now when I configure a Class to my DMS DIR and go to CV01n Additional Data NONE of the characteristic entry boxes show up. Additional Data is blank.

    I have used SAP doc mgmt for years. We copied a client and now when I configure a Class to my DMS DIR and go to CV01n Additional Data NONE of the characteristic entry boxes show up. Additional Data is blank.
    It appears there must be some high level setting missing in the client. I have checked all authorizations and cannot find a difference between this client and all of the other clients we have. Only this one client does not show the class characteristics in the Additional Data tab.
    Any ideas of why this standard function is not working). It does not matter which DIR I config the 017 class to, nothing shows on Additional Data.

    Hi,
    The issue is resolved. We are working in a sandbox with Class configuration on a DMS issue related to standard class 017. There are no standard settings in SPRO - Cross-Application Components | Maintain Object Types and Class Types | for the object type DRAW that will allow "auto-populating" characteristic values as we do with VC class 300.
    For whatever reason DRAW and class 017 are not configured by SAP in the same manner as class 300 for example.
    We made a config entry for DRAW Class 017 VBAP. Let's just say the system did not like that.
    We are exploring other options.

  • Why use an Abstract Class ?

    I am new to Java and for some reason I can't get my head around why to use an abstract class. I understand that an abstract class is something like:
    public abstract class Food{ // abstract class
    public void eat(){
    // stub
    public class Apple extends Food{
    public void eat(){
    // Eat an apple code
    }So basically the idea above is that you can eat an "apple" but you can't eat "food" because you can't instantiate an abstract class.
    I understand what an abstract class is and how to write one. What I don't understand is why you would use it? It looks to me like I could have just created a normal class called "Food" and just not instantiated it. What are the benefits of using an abstract class?

    807479 wrote:
    I am new to Java and for some reason I can't get my head around why to use an abstract class.One of the first books I ever read about Object-Oriented design contained the following quote from [url http://en.wikipedia.org/wiki/Lucius_Cary,_2nd_Viscount_Falkland]Lord Falkland:
    "When it is not necessary to make a decision, it is necessary +not+ to make a decision."
    It took me quite a while to understand, but it's all about flexibility: As soon as you cast something in stone, you lose the ability to change it later on if something better/more appropriate comes along. Interfaces and abstract classes are all about delaying that decision.
    As jverd said, interfaces allow you to specify what is required without defining the how; and as ErasP said, abstract classes are usually incomplete: ie, they define some of the 'how', but not all of it.
    What is most important about abstract classes though is that they cannot exist on their own: They must be extended by a concrete class that completes the 'how' before they can be instantiated and, as such, they declare the intent of the designer.
    One of the most important uses of abstract classes is as "skeleton implementations" of interfaces, and there are a lot of examples of these in the Java Collections hierarchy. My favourite is probably AbstractList, which contains a skeleton implementation of a List. Because it exists, I can create a class that wraps an array as a List with very little code, viz:public final class ArrayAsList<T>()
       extends AbstractList<T>
       private final T[] values;
       public ArrayAsList(T... values) {
          this.values = values;
       @Override
       public T get(int index) {
          return values[index];
       @Override
       public T set(int index, T element) {
          T value = get(index);
          values[index] = element;
          return value;
       @Override
       public int size() {
          return values.length;
    };and somewhere else, I can use it:   List<String> letters =
          new ArrayAsList<String>("a", "b", "c");or perhaps, more practically:   List<String> words = new ArrayAsList<String>(
          bigTextString.split(" +") );Now that may not seem like a big deal to you, but given all that Lists can do, it's actually a very powerful bit of code. The above example is from "Effective Java" (p.95).
    HIH
    Winston

  • Why use abstract classes?

    Why should I use abstract classes instead of a regular class with empty method bodies? Just better design? Is there some logical or performance based reason?

    Why should I use abstract classes instead of aregular
    class with empty method bodies? Just better design?Is
    there some logical or performance based reason?Because it describes what you're doing.
    If you define a "regular" class with empty message
    bodies, everyone who looks at it will say "WTF is he
    trying to do" or, if they're charitable, "Look,
    Harvey, someone who's trying to make Java look just
    like C++!".
    sigh Maybe answers like THIS are why people keep asking the same question.
    Here's a couple things an abstract class does that a "regular" class with empty methods bodies doesn't:
    1) An abstract class cannot be instantiated.
    2) An abstract class forces it's abstract methods to be implemented.
    If you were to extend a non-abstract class with empty method bodies, you wouldn't have to override the methods... you could just leave them empty. An abstract class forces it.
    There's a lot more reasons... those are a couple obvious ones.

  • When to use abstract classes instead of interfaces with extension methods in C#?

    "Abstract class" and "interface" are similar concepts, with interface being the more abstract of the two. One differentiating factor is that abstract classes provide method implementations for derived classes when needed. In C#, however,
    this differentiating factor has been reduced by the recent introduction of extension methods, which enable implementations to be provided for interface methods. Another differentiating factor is that a class can inherit only one abstract class (i.e., there
    is no multiple inheritance), but it can implement multiple interfaces. This makes interfaces less restrictive and more flexible. So, in C#, when should we use abstract classes
    instead of interfaces with extension methods?
    A notable example of the interface + extension method model is LINQ, where query functionality is provided for any type that implements IEnumerable via
    a multitude of extension methods.

    Hi
    Well I believe Interfaces have more uses in software design. You could decouple your component implementing against interfaces so that
    you have more flexibility on changing your code with less risk. Like Inversion of Control patterns where you can use interfaces and then when you decide you can change the concrete implementation that you want to use. Or other uses for interfaces is you could
    use Interceptors using interfaces (Unity
    Interceptor) to do different things where not all of these is feasible or at least as straightforward using abstract classes.
    Regards
    Aram

  • OC4J 9.0.4 migrate to 10.1.3.1 JSP fails using abstract class for ResultSet

    Consider the following JSP code snipet:
    <%
    com.class.SQLDataSource detail = ((com.class.SQLDataSource)request.getAttribute("AcctList"));
    %>
    <%while detail.next()) {detail.getRow();%>
    <tr ...>
    <td ...><%= detail.getString("ACCT") %></td>
    </tr>
    <%}%>
    blah, blah, blah
    class snipet looks like this:
    public abstarct class SQLDataSource extends serializable {
    private ResultSet resultSet = null;
    private PreparesStatement stmt = null;
    public boolean next() throws SQLException {
    boolean result = getResultSet().next();
    return (result);
    public String getString(String columnName) throws SQLExcpetion {
    return getResultSet().getString(columnName);
    public void execute() throws SQLException {
    -- checks stmt
    -- if null generates resultSet from "AcctList.sql" query
    -- if not null, re-executes as-is stmt for a query only
    protected ResultSet getResultSet() throws SQLException {
    execute(); // see above
    return resultSet;
    The problem:
    <%= detail.getString("ACCT") %> generates a NullPointerException
    Yet, if I add debug statements in the SQLDataSouce class, they conclusively show that resultSet has 1902 rows and I can diplay the contents on these rows (on the console, of course, the JSP still generates a NullPointerException).
    If I "hardcode" the creation of a ResultSet in the JSP, the pages displays properly (not the desired method).
    PLEASE TAKE NOTE: This JSP/Class combination works PERFECTLY in OC4J 9.0.4 using JDeveloper 9.0.5.2. When I deploy the **EXACT SAME** JSP/Class combination in JDeveloper/OC4J 10.1.3.1, I receive the NullPointerException.
    So what this feels like to me (and my VERY limited J2EE experinece) is that the abstract class SQLDataSource has somehow lost/closed/dropped/corrupted resultSet when "returning" to the JSP for display of the contents of resultSet. This is, of course, a laymans explanation of the experienced effect of running this code.
    It makes me wonder if under 10.1.3.1 "something more" must be done so that the (abstract) SQLDataSource class can operate in the same way it did under 9.0.4.
    Last note: this NullPointerException happens whether I deploy to standalone OC4J 10.1.3.1 or if I execute my application withing JDevloper's Embedded OC4J instance.
    Any Assistance on this MOST aggrivating problem would be greatly appreciated.
    Others have yet to solve it in similar posts of mine. Hopefully this more definitive description will help YOU be my personal HERO.
    Ed.

    repost to pique interest

  • When should I use abstract classes and when should I use interfaces?

    Can any body tell me in which scenario we use /we go for Interface and which scenario we go for abstract class, because as per my knowledge what ever thing we can do by using Interface that thing can also done through abstract class i mean to say that the
    behavior of the two class.
    And other thing i also want to know that which concept comes first into the programming abstract class or Interface.
    S.K Nayak

    The main differences between an abstract class and an interface:
    Abstract
    An abstract class can contain actual working code (default functionality), and can have either virtual or abstract method.
    An abstract class must be sub-classed and only the sub-classes can be instantiated. Abstract methods must be implemented in the sub-class. Virtual methods may be overridden in the sub-class (although virtual methods typically contain code, you still may
    need/want to override them). A good use for an abstract class is if you want to implement the majority of the functionality that a class will need, but individual sub-classes may need slightly different additional functioality.
    Interface
    An interface only contains the method signatures (method name and parameters), there is no code and it is not a class.
    An interface must be implemented by a class. An interface is not a class and so it cannot be sub-classed. It can only be implemented by a class. When a class implements an interface, it must have code in it for each method in the interface's definition.
    I have a blog post about interfaces:
    http://geek-goddess-bonnie.blogspot.com/2010/06/program-to-interface.html
    (sorry, I have no blog posts specific to abstract classes)
    ~~Bonnie DeWitt [C# MVP]
    http://geek-goddess-bonnie.blogspot.com

  • Abstract class method polymorphically using constructors?

    how can i have a method defined in an abstract superclass call a constructor of the actual class running the method?
    abstract class A {
    public List getMultple() {
    List l = new ArrayList();
    for (short i=0;i<4;i++) {
    l.add(this());//<obviously this breaks
    return l
    or something like that. A won't run this method, but its children will...and they can call their constructors, but what do i put here to do that?
    i've tried a call back. an abstract method getOne() in the superclass forces each child to define that method and in each of those i return the results of a constructor. that works fine.
    the problem is i want to abstract this method out of each of these children classes cause its the exact same in each one, just using a different constructor to get multiple of each in a list. so if i use this callback method, then i am not saving the number of methods in each class, so why bother at all?
    any ideas?

    I still say you are coming at it from the wrong angle. A super class is not the way to go. What you are doing sounds like something very similar to something I did not too long ago.
    My requirement was that I had tab delimited text files filed with data that I had to parse. Each line would be used to instantiate one object, so a particular file could be used to instantiate, for example, a thousand objects of the same class. There were different types of files corresponding to different classes to instantiate instances of.
    Here is the design I ended up using.
    An object of class DataTextFileReader is instantiated to parse the text file and generate objects. It includes code for going line by line, handling bad lines and generating objects and reports. The constructor:
    public DataTextFileReader(File inputFile, LineParser<T> theLineParser)LineParser is an interface with one method:
    public T read(String line);When you call a load() method of the DataTextFileReader, it does its thing with the aid of the LineParser's read method, to which each line is passed, and stores the generated objects in an ArrayList. This can be returned by using another method. There are other methods for getting the reports, etc.
    Obviously, the LineParser chosen needs to have code appropriate for parsing the lines in question, so you have to choose and instantiate the right one.
    I find this design to work well. I arrived at it after spending hours giving myself headaches trying to come up with a design where there was a superclass roughly equivalent to the DataTextFileReader mentioned above, and classes extending this that fulfilled the duty of the LineParsers mentioned above... rather like what you are trying to do now.
    I did not care for the solution at first because it did not give me the "Ah, I am clever!" sensation I was expecting when I finally cracked the problem using inheritance, but I quickly came to think that it was much better OOD anyway.
    The LineParsers mentioned above are essentially embodiments of the Factory pattern, and I would recommend you do something similar in your case. Obviously your "constructors" all have to be different, so you should make a separate class for each of those. Then you can put the code that performs the query and loops to create loads of objects in another class called something like DatabaseDepopulator, using appropriate generics as in my example. Really it is the same problem, now that I look at it.
    This will also result in better separation of concepts, if you ask me. Why should the class constructor know how to parse a database result query, much less perform the query? It has nothing to do with databases (I presume). That is the job of an interpreter object.
    As a final note, remember... 95% of the time you feel like the language won't let you do what you want, it is because you shouldn't anyway.
    Drake

Maybe you are looking for