Thank you for reporting this bug. We will make it our priority to review this report.
  1. #1
    Sencha User
    Join Date
    Mar 2013
    Posts
    25
    Vote Rating
    0
    phickey is on a distinguished road

      0  

    Default PropertyAccess generation error

    PropertyAccess generation error


    The PropertyAccess interface does not compile a class per interface. Instead it compiles a subset of a class and tries to reuse previous classes/methods.Here is an example of how this causes severe errors:protected interface AddressDTOProperty extends PropertyAccess<ICRUDObject<AddressDTO>> { @Editor.Path("dTO.type") public ValueProvider<ICRUDObject<AddressDTO>, AddressDTO.TYPE> type();}protected interface EmailDTOProperty extends PropertyAccess<ICRUDObject<EmailDTO>> { @Editor.Path("dTO.type") public ValueProvider<ICRUDObject<EmailDTO>, EmailDTO.TYPE> type();}Please note that the types are different. Instead GWT produces a single class that always returns an AddressDTO.TYPE even if I use the EmailDTOProperty reference in the code. Is there a flag I should set?RegardsPatrick

  2. #2
    Sencha User
    Join Date
    Mar 2013
    Posts
    25
    Vote Rating
    0
    phickey is on a distinguished road

      0  

    Default FIXED THE FORMATTING OF ABOVE QUESTION

    FIXED THE FORMATTING OF ABOVE QUESTION


    The PropertyAccess interface does not compile a class per interface. Instead it compiles a subset of a class and tries to reuse previous classes/methods.Here is an example of how this causes severe errors:

    Code:
    protected interface AddressDTOProperty extends PropertyAccess<ICRUDObject<AddressDTO>> {
    @Editor.Path("dTO.type")
    public ValueProvider<ICRUDObject<AddressDTO>, AddressDTO.TYPE> type();
    }
    
    protected interface EmailDTOProperty extends PropertyAccess<ICRUDObject<EmailDTO>> {
    @Editor.Path("dTO.type")  public ValueProvider<ICRUDObject<EmailDTO>, EmailDTO.TYPE> type(); 
    }
    


    Please note that the types are different. Instead GWT produces a single class that always returns an AddressDTO.TYPE even if I use the EmailDTOProperty reference in the code. Is there a flag I should set?

    RegardsPatrick

  3. #3
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,634
    Vote Rating
    79
    Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice Colin Alworth is just really nice

      0  

    Default


    Can you provide a full runnable test case (with ICRUDObject and AddressDTO/EmailDTO and any other required types included)?

    Also, have you tried to simply define a ProperyAccess<ICRUDObject<T>> instead, probably with some generics to make the TYPE arg make sense? This should enable the generator to effectively build a ValueProvider<ICRUDObject<?>, ?> just once, and use that same object in each case - since Java Generics are erased at runtime (this includes when compiled to JS), this should work just fine.

  4. #4
    Sencha User
    Join Date
    Mar 2013
    Posts
    25
    Vote Rating
    0
    phickey is on a distinguished road

      0  

    Default Adjustments made to the Generators.

    Adjustments made to the Generators.


    Hi Colin,

    I copied the generators provided by Sencha and made some adjustments to the way that they generate the class names for the GWT.create(propertyAccess.class) calls. Here is the snippet, it might be worth while including similar changes to later versions of GXT.

    Code:
                // This code is used to create the providers in GXT. 
                // The class is com.sencha.gxt.data.rebind.PropertyAccessGenerator
                // Previously the constructor of the ValueProviderCreator was not handed the typeName parameter.
                // This variable represents the interface name of the PropertyAccess class created in GXT project.
                JClassType ret = m.getReturnType().isClassOrInterface();
    final AbstractCreator c; if (ret.isAssignableTo(valueProviderInterface)) { c = new ValueProviderCreator(context, l, typeName, m); } else if (ret.isAssignableTo(modelKeyProviderInterface)) { c = new ModelKeyProviderCreator(context, l, m); } else if (ret.isAssignableTo(labelProviderInterface)) { c = new LabelProviderCreator(context, l, m); } else { logger.log(TreeLogger.Type.ERROR, "Method uses a return type that cannot be generated"); throw new UnableToCompleteException(); }
    Then I made the relevant changes to the ValueProviderCreator class so that the names of the classes are generated with a unique name based on the PropertyAccess interface created in a GXT project

    Code:
    @Override
        protected String getSimpleName() {
            // The class is com.sencha.gxt.data.rebind.ValueProviderCreator
            // The propertyAccessClsName is the variable typeName in the ValueProviderCreator.
            // This method ensures that the PropertyAccess class created in the GXT project is always 
            // used to create generated code. Before this change the GXT generators would buffer the 
            // generated classes, and the names where chosen based on the first generic in the ValueProvider
            // return type, so if your return type had multiple levels of generics it would return the old generated
            // code from the buffer and the javascript would not be able to successfully cast the data.
            return propertyAccessClsName.replace('.', '_') + "_" 
                         + Strings.join(path.toArray(new String[path.size()]), "_")
                         + "_ValueProviderImpl";
        }
    We can mark this issue as closed. And if you need more information on the changes please let me know. I do feel there is a necessary change required in the generators (Possibly resolve all of the generics to create the class name).

    Regards,
    Patrick

Thread Participants: 1

film izle

hd film izle

film sitesi

takipci kazanma sitesi

takipci kazanma sitesi

güzel olan herşey

takipci alma sitesi

komik eğlenceli videolar