Gelmiş geçmiş en büyük porno sitemiz olan 2pe de her zaman en kaliteli pornoları sunmayı hedefledik. Diğer video sitemiz olan vuam da ise hd porno ağırlıklı çalışmalara başladık.

    Success! Looks like we've fixed this one. According to our records the fix was applied for EXTGWT-2672 in 3.1 beta.
  1. #1
    Sencha User
    Join Date
    May 2011
    Location
    Netherlands
    Posts
    44
    Vote Rating
    1
    rcbeuker is on a distinguished road

      0  

    Default method ensureHandler() from Loader should be protected

    method ensureHandler() from Loader should be protected


    I want to extend the standard Loader<C, M> (Loader.java) with some extra handers. Therefore i need acces to;

    Code:
      SimpleEventBus ensureHandler() {
        return eventBus == null ? eventBus = new SimpleEventBus() : eventBus;
      }
    Or a least;

    Code:
    private SimpleEventBus eventBus;
    In my opinion method ensureHandler() should be given modifier protected instead of no modifier. This gives subclasses of Loader acces to the eventBus. Of course an extra method;

    Code:
    public void setEventBus(EventBus pEventBus)
    {
       eventBus = pEventBus;
    }
    Is even better

  2. #2
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,716
    Vote Rating
    87
    Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light

      0  

    Default


    Setting an EventBus is a bit of a no-no, since we might change the underlying event structure - as long as we adhere to the addFooHandler declared in any HasFooHandlers interface, we can keep the actual implementation hidden away and mutable without changing dependent code.

    What we are more likely to do is add a protected addHandler(Type, Handler) method, which will itself call ensureHandlers - this lets us decide how to build the handler container (HandlerManager/SimpleEventBus/etc) without making subclasses dependent on the implementation. The fireEvent is already protected in this same way.

    Why do you need this? Can you not build a new event router for your specific events? or invoke fireEvent(...) for existing events? Often times when someone subclasses something like this and adds functionality, it isn't meant to be used as the underlying base class any more - be careful that by subclassing you are only adding functionality, and not changing the nature of the underlying class - if you are, you should be composing, not inheriting.

    I've filed as an issue, and will update it when we change this API.

  3. #3
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,716
    Vote Rating
    87
    Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light

      0  

    Default


    This has been changed in 3.1 to expose both addHandler and fireEvent as protected methods.

Thread Participants: 1

Tags for this Thread