Igor Vaynberg wrote:
> while the css definition of the class is a design issue, i disagree that
> the application of it is. in my view the code SHOULD decide what class
> to apply if it is decided dynamically.
that mens communicating design information between the web designer and the developer. as i see it the process of developing pages with wicket is:
1. the designer creates a pure html page
2. the developer sprinkles wicket:id attributes and writes the java code
if the developer has to know what css class names to use, it creates a tighter binding between html and java, which i want to avoid
but the developer has to know the class name anyways because they are writing the code that decides if the row is even or odd, so they already need to know that something different is going to happen. this kind of information needs to be shared between the developers and the designers, there is no way around it with any framework.
i would make the class names java constants, that would make them easier to maintain if the actual class name changes over time.
all i want is a way of alternating the child elements that are selected, rather than the attribute values that are modified.
i dont quite understand what you mean here. i already explained that there has to be 1:1 link between markup and java components. so the way to "select" is to add all children and hide the ones that are not needed. but it isnt the greates approach to use.
another approach would be to use panels. you can break out the <tr class="even"> .. </tr> into EvenRowPanel.html and <tr class="odd"> ... </tr> into OddRowPanel.html and then in your code:
if (row%2==0) { item.add(new EvenRowPanel("panel")); } else { item.add(new OddRowPanel("panel"); }
but you still face the fact that you need to duplicate the markup, so for n choices you have n identical markup fragments. is it really worth it?
-Igor
-Igor
