Compound models are working fine with generics (in 2.0)
Link can also have a model object (that you use when you click on the link)
But the problem is that warnings should be easier to disable for certain
situations..
Like the markupcontainter when you don't use the model at all..
for example
I think it is time to close the vote and count our blessings. As Al is
now under water, surfing or generally having a great time, I call the
vote.
7 +1 binding votes,
According to me we have 4 abstainees, and no non-binding votes.
This wraps it: we will drop the constructor change and migrate
Hi,
In the current implementation, going from setVisible(false) to
setVisible(true) in ajax does not work, The current workaround of this
bug is to surround the element with an other and to rerender the
surounding element. I found this way not very smart and too frustating
for the user. We
Johan Compagner a écrit :
But your patch doesn't do much with style i believe?
It only generates a span tag where the component would be?
Sorry I made a mistake in the attachement : Here is the right one
https://issues.apache.org/jira/secure/attachment/12353648/component-real.txt
Is that
Johan Compagner a écrit :
Also always just rendering the component but use the style to make in
invisible
could be a security problem. So that can't be the default.
What do you mean by security problem?
If the the component that is set to none visible is none visible
because of
So you mean:
Label l = Label(foo, hello);
renders:
span wicket:id=foohello/span
... some ajax stuff, or a normal page render:
l.setVisible(false);
renders:
span wicket:id=foo style=display:none/span
?
This can and will break existing clients in a very nasty manner,
because the
Martijn Dashorst wrote:
So you mean:
Label l = Label(foo, hello);
renders:
span wicket:id=foohello/span
... some ajax stuff, or a normal page render:
l.setVisible(false);
renders:
span wicket:id=foo style=display:none/span
not @wicket:id, but just @id, because the Label should
Frédéric Bertin a écrit :
Martijn Dashorst wrote:
So you mean:
Label l = Label(foo, hello);
renders:
span wicket:id=foohello/span
... some ajax stuff, or a normal page render:
l.setVisible(false);
renders:
span wicket:id=foo style=display:none/span
not @wicket:id, but just @id,
Will it? This seems to be actually quite a smart workaround. How
exactly will this break existing clients? Only thing i'm concerned
about is the validity of output markup. but imho when we preserve the
original tag names, e.g. td will render as td, it should be all right.
-Matej
On 3/19/07,
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.
I *strongly*
Indeed, it wil fail. but I kind of fail to see practical value of this
behavior. To me it looks much more useful to be able to
setVisible(false) and later setVisible(true), without having to worry
about wrapping the element (which can be rather tricky with element
like td).
Perhaps we could have
Martijn Dashorst a écrit :
Currently everybody assumes (correctly) that the element is completely
removed (Ajax and non-Ajax)
Yes of course, but it is the same for all workarounds ;)
When to change servlet to filter, users have to change their web xml.
Each time you change something users have
it seems taht this kind of construction is used to make workaround of
the bug. Is'n it?
First, what bug? I don't know that this is a bug? I thought we are
discussing a feature here. Secondly, this is not a workaround, but
creating client side code based on a API contract: setVisible(false)
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
Unlike wrapping components in webmarkupcontainer, this should work for
all tags, including td, tr, etc.
On 3/19/07, Johan Compagner [EMAIL PROTECTED] wrote:
yeah i could live with this solution, if it works for all kind of tags.
johan
On 3/19/07, Matej Knopp [EMAIL PROTECTED] wrote:
I don't think current behavior is the best one. Even if it can be
corrent, it lacks convenience.
I suggest a flag on web markup container, that could change the way
invisible component is rendered. Default could be, that it's not
rendered at all. So it would not break any code. You could change
WebMarkupContainer isn't the right choice i think
Then we miss Label (which is a WebComponent)
johan
On 3/19/07, Matej Knopp [EMAIL PROTECTED] wrote:
I don't think current behavior is the best one. Even if it can be
corrent, it lacks convenience.
I suggest a flag on web markup container,
Martijn Dashorst wrote:
it seems taht this kind of construction is used to make workaround of
the bug. Is'n it?
First, what bug? I don't know that this is a bug? I thought we are
discussing a feature here. Secondly, this is not a workaround, but
creating client side code based on a API
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,
On 3/19/07, Matej Knopp [EMAIL PROTECTED] wrote:
But why can't it be per component setting? Why can't we have a flag for this?
It can, but having to set it per component will require you to do it
everywhere. This might make the change less interesting, and less
consistent. If you make it an
I wanted to say on having this behavior _on_ by default of course :)
On 3/19/07, Matej Knopp [EMAIL PROTECTED] wrote:
Well, I'm also -1 for having this behavior off for default.
But, i think it can be quite useful for couple of cases, therefore i
think there should be support for that.
I think
Igor Vaynberg wrote:
im not a big fan of having an application-wide setting for this. it will
make it harder to integrate with 3rd party components that werent written
with the setting in mind because it pretty much gives you an option of
ignoring it by assuming a default.
better make it
On 3/19/07, Frédéric Bertin [EMAIL PROTECTED] wrote:
setOutputMarkupId(true), because it is simply useless, no?
no that the thing it is not useless. all its saying is that i want the id
output when the component tag renders. it says nothing about the situation
when the component is not
hrm
this name is still bad
maybe setoutputtagplaceholder() is better
it needs to communicate that the tag is still there even though the
component is invisible
-igor
On 3/19/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
what you need is a different method. instead of
As I have explained in my previous mails, and as Igor did in his
messages, you can query the dom for existence of an element:
document.getElementById('foo') == null
The following is legal, and (except for the random bit) a common idiom.
new Label(foo, Hello, World) { public boolean isVisible()
OK,
I've extracted a new wicket-portlets project and it is available here:
*
http://wicket-stuff.svn.sf.net/svnroot/wicket-stuff/branches/wicket-1.3/wicket-portlets
*
http://wicket-stuff.svn.sf.net/svnroot/wicket-stuff/branches/wicket-1.3/wicket-portlet-examples/
I also updated our migration
+1, non-binding.
On 3/19/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
+1
-igor
On 3/19/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
hibernate 3.2 has switched from using an int to a long for returntype of
their count queries. jpa also uses a long. so i figure its time to
switch
idataprovider
+1
Eelco
On 3/19/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
hibernate 3.2 has switched from using an int to a long for returntype of
their count queries. jpa also uses a long. so i figure its time to switch
idataprovider to the long as well so that it maps nicely. since we have
broken 1.3
Igor Vaynberg wrote:
As a user, I want to refresh my component with Ajax. I don't care if, to
achieve that, Wicket needs a tag, an id, or anything else.
which is what i proposed below in my code snippet
yes, indeed. My point was just about giving methods a feature-related
name
+1
I'm going with the crowd
On 3/20/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
+1
Eelco
On 3/19/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
hibernate 3.2 has switched from using an int to a long for returntype of
their count queries. jpa also uses a long. so i figure its time to switch
It's not that I don't like generics -- I just don't think Component
makes sense as a generic class because it seems like the majority of
use cases don't call for specifying a model type.
Let me ask you, do you specify the type for form components even when
you're using a
+1
Frank
On 3/19/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
hibernate 3.2 has switched from using an int to a long for returntype of
their count queries. jpa also uses a long. so i figure its time to switch
idataprovider to the long as well so that it maps nicely. since we have
broken 1.3
On Mar 19, 2007, at 12:58 AM, Eelco Hillenius wrote:
Do you have an idea that works without having to generify Component?
Not sure if you would put this in the idea that works category, but
I was thinking of something like this:
public class Component {
private IModel model;
33 matches
Mail list logo
