On Mar 20, 2007, at 12:35 AM, Stefan Lindner wrote:
So the component developert must be very disciplined because the
local variable "model" ist not generic. You can assign whatever
IModel you want to the local "model". And the "return this.model"
line will cause a warning.
The "return this
So the component developert must be very disciplined because the local variable
"model" ist not generic. You can assign whatever IModel you want to the local
"model". And the "return this.model" line will cause a warning.
In most cases it makes sense to have Generic components.
Stefan Lindner
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;
+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 a
what about the cases where it is very nice to have?
ListView(String,IModel,IModel>)
or
DropDownChoice(String,IModel,IModel>,IChoiceRenderer)
im not arguing for or against, but there are cases where it is very nice to
have them, especially for newbies. when a newbie looks at the above they
know
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 CompoundPropertyMod
+1
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 already,
+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 swit
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 (setAjaxRefre
+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 al
+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
> idatap
+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 to the long as well so that it maps nicely. since we have
broken 1.3 al
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 already, we might as well do it now.
-igor
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
BIG +1 from me on this post!
especially as everyone can set his compiler to ignore the generics when he
dont want them while they save much time for devs that use them
Regards
_
Von: Philip A. Chapman [mailto:[EMAIL PROTECTED]
Gesendet: Montag, 19. März 2007 19:26
An:
On 3/19/07, Frédéric Bertin <[EMAIL PROTECTED]> wrote:
However, from a user point of view, I find it a little bit complicated
and would find really nice to have a higher level method, like
setAjaxRefresheable(true|false),
we should keep the term "ajax" out of the method name. it needs to be m
ok, let's go for it.
However, from a user point of view, I find it a little bit complicated
and would find really nice to have a higher level method, like
setAjaxRefresheable(true|false), which takes care of
tuning all the setOutput* stuff so that a component is *always*
refresheable in ajax,
Guys,
I've used generics with 2.0 at length, and absolutely love them. I am a
huge fan of catching a problem early with compile-time errors rather
than finding out later that I'm returning the wrong type from a model or
that my Formatter is expecting a different type. Yes, for a while the
angle
i like it
the only thing that nicks me is that we have src/src folder, but i guess
that is a maven requirement? if so im ok with it, if we can rename it to
src/mvn it would be better i think.
good job martijn!
-igor
On 3/18/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
All,
I've uploaded
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 isVisibl
you have to get out of your ajax tunnel vision.
take the datepicker example. it needs the outputmarkupid(true) so that it
can tie the datepicker js to the textfield. but when the datepicker is not
visible why should an empty tag still be there?
-igor
On 3/19/07, Vincent Demay <[EMAIL PROTECTED
Igor Vaynberg a écrit :
no its not.
what i am trying to say is that setoutputmarkupid should be
independent from
this behavior. you are really making the meaning of
setoutputmarkupid(true)
ambiguous. all it is saying is that when the tag is rendered i want it to
include the id attribute, you
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 setoutputmarkupid(tr
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 visi
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 explici
no its not.
what i am trying to say is that setoutputmarkupid should be independent from
this behavior. you are really making the meaning of setoutputmarkupid(true)
ambiguous. all it is saying is that when the tag is rendered i want it to
include the id attribute, you are changing that meaning to
Igor Vaynberg a écrit :
what you need is a different method. instead of
setoutputmarkupid(true) you
need something that will do
setoutputmarkuptag(boolean b) {
if (b) {
setoutputmarkupid(true);
setflag(outputmarkuptag,true);
} else {
setflag(outputmarkuptag,false);
//not
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 explicit, and it doesnt add a
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 th
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 what we need is an application setting, for default behavior,
and then a getter for each component.
e.g. boolean Compone
what you need is a different method. instead of setoutputmarkupid(true) you
need something that will do
setoutputmarkuptag(boolean b) {
if (b) {
setoutputmarkupid(true);
setflag(outputmarkuptag,true);
} else {
setflag(outputmarkuptag,false);
//not sure if we should undo set
I don't like it. I don't think deprecating set/isVisible is the way to
go. Plus there are other reasons: As now we use one flag for visible
status. With your approach you'd require an enum, int, byte or
something similiar, that takes more space then just one bit in flags.
I think we can just make
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 lesso
Frédéric Bertin a écrit :
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 c
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
But why can't it be "per component" setting? Why can't we have a flag for this?
On 3/19/07, Martijn Dashorst <[EMAIL PROTECTED]> 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 th
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,
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 contract
Martijn Dashorst a écrit :
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 contr
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,
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
Unlike wrapping components in webmarkupcontainer, this should work for
all tags, including 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:
>
> Indeed, it wil fail. but I kind of fail to see practical value
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
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)
remov
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:
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 setVisibl
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 t
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
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* discourag
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, Mart
Frédéric Bertin a écrit :
Martijn Dashorst wrote:
So you mean:
Label l = Label("foo", "hello");
renders:
hello
... some ajax stuff, or a normal page render:
l.setVisible(false);
renders:
not @wicket:id, but just @id, because the Label should have
setOutputMarkupId(true) to be re
Martijn Dashorst wrote:
So you mean:
Label l = Label("foo", "hello");
renders:
hello
... some ajax stuff, or a normal page render:
l.setVisible(false);
renders:
not @wicket:id, but just @id, because the Label should have
setOutputMarkupId(true) to be refreshed with ajax
Fred
So you mean:
Label l = Label("foo", "hello");
renders:
hello
... some ajax stuff, or a normal page render:
l.setVisible(false);
renders:
?
This can and will break existing clients in a very nasty manner,
because the markup id is still present in the final markup.
Martijn
On 3/19
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
secu
> 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
security
So it has data that neve
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 allo
Ok i just converted everything to the new repository structure.
I have to fix some unit test but then i can commit the model change.
johan
On 3/19/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
I think it is time to close the vote and count our blessings. As Al is
now under water, surfing or
But your patch doesn't do much with style i believe?
It only generates a span tag where the component would be?
Is that allowed every where?
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.
But i do like to
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
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 a
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 th
60 matches
Mail list logo
