Wicket
  1. Wicket
  2. WICKET-4160

Make AbstractAutoCompleteRenderer.renderHeader() and .renderFooter() non-final

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.5.1
    • Fix Version/s: 6.2.0
    • Component/s: wicket-extensions
    • Labels:
      None

      Description

      I really love wicket but the times I had to work around final methods just increases towards infinity...
      Could you please make in the following class:
      org.apache.wicket.extensions.ajax.markup.html.autocomplete.AbstractAutoCompleteRenderer
      The methods renderHeader and renderFooter non-final? It is really annoying in order to just customize the appearance I have to write a whole delegate even to an abstract class just to customize that <ul> tag!
      thanks

        Activity

        Hide
        Martin Grigorov added a comment -

        What exactly you need to customize ?
        If we remove final from those two methods then we have to remove final from org.apache.wicket.extensions.ajax.markup.html.autocomplete.AbstractAutoCompleteRenderer.render(T, Response, String) because they are tied. If header/footer doesn't produce <ul> then #render() shouldn't produce <li>s as well.
        Maybe you just need to add some CSS rules in your .css to change the styling.

        Show
        Martin Grigorov added a comment - What exactly you need to customize ? If we remove final from those two methods then we have to remove final from org.apache.wicket.extensions.ajax.markup.html.autocomplete.AbstractAutoCompleteRenderer.render(T, Response, String) because they are tied. If header/footer doesn't produce <ul> then #render() shouldn't produce <li>s as well. Maybe you just need to add some CSS rules in your .css to change the styling.
        Hide
        Matthias Keller added a comment -

        The Problem is that we're limited what we can do with the CSS which is fixed from external; so we need to change the code instead to add a class to the <ul>.
        I see your concern about matching tags but I still think making everything final just because there's a risk of invalid output in case of wrong overrides isn't the right solution - there's lots of places where things can be broken and if it's well documented what is expected from a method then that's always the risk of the subclasser

        Show
        Matthias Keller added a comment - The Problem is that we're limited what we can do with the CSS which is fixed from external; so we need to change the code instead to add a class to the <ul>. I see your concern about matching tags but I still think making everything final just because there's a risk of invalid output in case of wrong overrides isn't the right solution - there's lots of places where things can be broken and if it's well documented what is expected from a method then that's always the risk of the subclasser
        Hide
        Matthias Keller added a comment -

        Thanks for fixing it in 6.2.0 - would it be possible to fix it also in 1.5.x? That would be really great!

        Show
        Matthias Keller added a comment - Thanks for fixing it in 6.2.0 - would it be possible to fix it also in 1.5.x? That would be really great!

          People

          • Assignee:
            Martin Grigorov
            Reporter:
            Matthias Keller
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development