What are these use cases? You see, because I've never changed markup attributes in the constructor, and I never missed that, and because I only see the 'id' being changed in the constructor, was the reason for simplyfing the implementation. If there are good reason for changing markup attributes in the constructor, than should try to keep the logic, but may be re-write the implementataion.
In that sense getMarkupId(), getOutputMarkupId() and setOutputMarkupId() is the only use case I'm aware of. And when I looked at these 3 methods today and on all the other methods we have in Component, I was worndering if the same logic can not be implemented with just getMarkupId(boolean createIfRequired). Juergen On 10/2/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> Any yes, getMarkupAttributes() would be a read-only map. Then we have to rewrite some pieces of Wicket In Action again :/ Ok, if you guys think it's better like that... I think it's a shame that we're back to using attribute modifiers and overriding onComponentTag again; adjusting attributes in the constructor was nice functionality imo. Eelco
