Martijn Dashorst wrote:
It is not a bug, but the current way how markup rendering works. It
has been this way since 0.1. It is widely published behavior and
widely used. Introducing this will create bugs in existing
applications, that are hard to track.

And please, don't give me JavaScript lessons, thank you very much, I
find that very condescending.
I'm sorry, it really wasn't my intention. What I tried to point out by writing this is the semantic difference between visibility and rendering. The more I think about this, the more I find that the solution is similar to the distinction made in CSS between visibility (hidden|visible) and display (none|block). What is currently implemented in Wicket using setVisible is similar to display (none|block), because the component is not rendered in the markup at all. And it is implemented in a non-reversible way. What I need is more something similar to visibility(hidden|visible), because the component needs to be rendered in the markup (not completely, a tag with an @id is enough). And the implementation needs to be reversible.

wdyt?

I understand you find this solution very
elegant and perfect for *YOUR* usecase. As a framework
builder/maintainer I have to weigh existing investments as well. I
don't take breaking existing applications lightly.

*IF* we were to adopt this, it should not be the default (because it
breaks existing applications), and it should be an application setting
to turn it on, or a page setting (which inherits the application
setting?). I think that making it a WMC specific setting will mitigate
the advantages of this approach.

As for the migration guides, these are usually properly ignored. If
you can fail fast, then we should do that. Typically we use changes in
API and @deprecation for that. This change doesn't have any of those
safeguards.

Martijn


On 3/19/07, Frédéric Bertin <[EMAIL PROTECTED]> wrote:
Martijn Dashorst wrote:
> Currently everybody assumes (correctly) that the element is completely
> removed (Ajax and non-Ajax), i.e. not present in the final markup.
> This means that scripts that iterate through the dom, or check for the
> document.getElementById() == null will fail if we implement this.
then you'll have to check for document.getElementById().style.display ==
"none"
it's a bit longer to write, but it is semantically better. Indeed it
checks a component *visibility*, and not its existence.

When I do setVisible(false), I expect setVisible(true) to work if called
later, in ajax or not. Currently, it doesn't work in Ajax. Don't you
think it is a real bug?
If yes, I don't think breaking such scripts should be used as a pretext
not to fix bugs ;-)


Fred





--
Frédéric BERTIN
Contrôle industriel
ANYWARE TECHNOLOGIES
Tél (direct) : +33 (0)5.61.00.06.41
Tél (standard) : +33 (0)5.61.00.52.90
Fax : +33 (0)5 61 00 51 46
http://www.anyware-tech.com

Reply via email to