see my previous mail (i aksed the same thing to eelco)
just don't add the behavior to the behaviors
just in render also walk over the validators and get the behavior if it
has
one.
then if you remove the validator everything is gone.
but where do you keep the reference? if you create a new
Hi
Xavier Hanin a écrit :
Hey there,
I have a question about the data proxy set to true in CometdEvent:
what
is it used for? Indeed I would like to get rid of CometdEvent, to make
implementation switch very easy, but I'm not sure if all cometd events
should always have this property set, or
You may want to have a look at the unit tests for FormTester:
org.apache.wicket.util.tester.apps_4.FormTesterTest
org.apache.wicket.util.tester.WicketTesterTest
And if you can extend them to cover your usecase, that would be
great too!
--
Jean-Baptiste Quenot
aka John Banana Qwerty
Xavier Hanin a écrit :
On 5/11/07, Vincent Demay [EMAIL PROTECTED] wrote:
Hi
Xavier Hanin a écrit :
Hey there,
I have a question about the data proxy set to true in CometdEvent:
what
is it used for? Indeed I would like to get rid of CometdEvent, to make
implementation switch very easy,
On 5/11/07, Vincent Demay [EMAIL PROTECTED] wrote:
Xavier Hanin a écrit :
On 5/11/07, Vincent Demay [EMAIL PROTECTED] wrote:
Hi
Xavier Hanin a écrit :
Hey there,
I have a question about the data proxy set to true in
CometdEvent:
what
is it used for? Indeed I would like to get rid
On 5/11/07, Vincent Demay [EMAIL PROTECTED] wrote:
Hi
Xavier Hanin a écrit :
Hey there,
I have a question about the data proxy set to true in CometdEvent:
what
is it used for? Indeed I would like to get rid of CometdEvent, to make
implementation switch very easy, but I'm not sure if all
We have a bit of a stalemate currently in how we'll support validators
that are or contribute behaviors.
First, why would we want such behaviors? It is to enable validators to
influence what is rendered so that they can e.g. set a maxlength
attribute, add client side javascript validation, or
Eelco Hillenius wrote:
I guess my point is made. I'll back off for a bit and see what other
people have to say about this. Anyone's opinions are welcome, and core
developers, please contribute so that we can make this decision in
consensus.
I wouldn't call it IBehaviorProvider if it's tied
Bruno Borges wrote:
What if we want to have in one IValidator, more than one IBehavior? just
wondering... :)
This could be important and usefull, if in one Validator two _very simple_
behaviors are needed, and they need to be keep separated with each other.
[]'s
We could have a method that
I guess my point is made. I'll back off for a bit and see what other
people have to say about this. Anyone's opinions are welcome, and core
developers, please contribute so that we can make this decision in
consensus.
I wouldn't call it IBehaviorProvider if it's tied into validators. ;-)
Instead of:
public IBehavior newValidationBehavior(Component component)
Have:
public void addBehavior(Component component)
I don't dislike it, but I see one practical problem. If we'd ever
support removing validators, we wouldn't know which behaviors would
have to be removed. So for this
How about enabled/disabled validators (and their behaviors) ? This way, no
counting down is needed and when validatores are disabled, they propagate
this state to behaviors. Removing validators is strange to me, but disabling
them for a while, I think this is more reasonable.
Maybe. Again would
Well, if you feel strongly about this, maybe it is time to open
another discussion about this specifically or (maybe better as we're
having to digest lots of traffic to start with) a JIRA feature
request.
Eelco
On 5/11/07, Bruno Borges [EMAIL PROTECTED] wrote:
Because Wicket is component
Xavier Hanin a écrit :
On 5/11/07, Vincent Demay [EMAIL PROTECTED] wrote:
Xavier Hanin a écrit :
On 5/11/07, Vincent Demay [EMAIL PROTECTED] wrote:
Hi
Xavier Hanin a écrit :
Hey there,
I have a question about the data proxy set to true in
CometdEvent:
what
is it used for? Indeed
Eelco Hillenius wrote:
Cheers. I'd also like to pull in what you proposed in another thread,
which is to introduce a more generic hook. E.g.
public interface IValidationBindListener {
void onAdded(Component component);
void onRemoved(Component component);
}
It would still need to be a
The current solution is simple, but I thought there were objections
because the Validator API is fairly independent of the internal
wicket?
That was not the immediate concern, as classes implementing both
interface would suffer the same problem. However, it is a point that
still needs some
The more I think about this, the more I think that a Validator IS-A
Behavior. Here's why:
* wicket has a very robust behavior infrastructure. The validation
framework is (intentionally) very minimalist
* there are a *million* other java libraries that do validation. If
wicket wants to promote
On 5/11/07, Alastair Maw [EMAIL PROTECTED] wrote:
Eelco Hillenius wrote:
Cheers. I'd also like to pull in what you proposed in another thread,
which is to introduce a more generic hook. E.g.
public interface IValidationBindListener {
void onAdded(Component component);
void
Because Wicket is component based... :) We actually reuse components and
somewhere we want to disable validators. For example: chained components
where one component if selected, must disable another component's validator.
--
Bruno Borges
Summa Technologies Inc.
www.summa-tech.com
(48) 8404-1300
I guess sitting back is not my strongest point :)
I just committed a variant of Al's idea:
/**
* Optional interface for validators ([EMAIL PROTECTED] IValidator} and
* [EMAIL PROTECTED] IFormValidator}) that can react to validators being added
to a
* component.
* p
* Implementation note:
in ServletWebRequest: public String getRelativePathPrefixToWicketHandler()
we create the relative prefix path based on the current request path (and
some other attributes if set)
my chat log:
[17:52 (11-05 )] jcompagner: the url i go to is a bookmarkable one like
so why is it onadded() here and bind() in ibehavior?
-igor
On 5/11/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
I guess sitting back is not my strongest point :)
I just committed a variant of Al's idea:
/**
* Optional interface for validators ([EMAIL PROTECTED] IValidator} and
* [EMAIL
huh?
-igor
On 5/11/07, Bruno Borges [EMAIL PROTECTED] wrote:
To follow with onAttach/onDetach (I don't remember if these has -ed)
--
Bruno Borges
Summa Technologies Inc.
www.summa-tech.com
(48) 8404-1300
(11) 3055-2060
On 5/11/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
so why is it
Does Wicket 1.3 beta 1 have a dependency on SLF4J?
I downloaded the beta 1 zip file and I noticed that the SLF4J jar is not
found in the lib folder
apache-wicket-1.3.0-incubating-beta1/lib
Should I expect to see SLF4J jar in the lib folder?
Sean
To follow with onAttach/onDetach (I don't remember if these has -ed)
--
Bruno Borges
Summa Technologies Inc.
www.summa-tech.com
(48) 8404-1300
(11) 3055-2060
On 5/11/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
so why is it onadded() here and bind() in ibehavior?
-igor
On 5/11/07, Eelco
Because components are created in onBeforeRender in list views (it calls
populateItem then), it is necessary for AJAX renderings now to call
beforeRender on every component to be updated before proceeding with the
render.
It looks like AjaxRequestTarget.respondComponent should call before
Does Wicket 1.3 beta 1 have a dependency on SLF4J?
Yep, it does.
I downloaded the beta 1 zip file and I noticed that the SLF4J jar is not
found in the lib folder
apache-wicket-1.3.0-incubating-beta1/lib
Should I expect to see SLF4J jar in the lib folder?
That's for Martijn to answer,
Well, I slept about it for a night, and talked a bit about this with
Al (who basically came up with the new interface) and my conclusion
really is that validators and behaviors shouldn't be mixed at this
stage. Before we allow that, I believe we really need to have a more
solid anwer to what the
Can someone document this in the migration document please? It can
breaks quite a lot of clients if I read this right...
Eelco
On 5/11/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: jonl
Date: Fri May 11 10:18:52 2007
New Revision: 537238
URL:
This discussion came out of the recent hibernate wicket-stuff
activity. For my behaviors/validators/listeners to work, I need to
have visibility into the PropertyModel's internal configuration. In
particular, I need access to the:
* propertyExpression configured for a particular form component
Why limit to getTargetClass() when its possible to return with getTarget()
and do a getTarget().getClass() ?
--
Bruno Borges
Summa Technologies Inc.
www.summa-tech.com
(48) 8404-1300
(11) 3055-2060
On 5/11/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
This discussion came out of the recent
Why limit to getTargetClass() when its possible to return with getTarget()
and do a getTarget().getClass() ?
It's a different intention. I was thinking about the type of the
property, not the target, which is the parent of the property.
Btw, I made getTarget public and final. Team, feel free
On 5/11/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
Why limit to getTargetClass() when its possible to return with getTarget()
and do a getTarget().getClass() ?
I agree with Eelco. There's nothing wrong with exposing the target
and then calling getClass(), it's just not what I needed. I
I'm proposing adding a method to the IComponentInstantiationListener
(or a new interface) that would be invoked when a components model is
bound/attached/whatever.
I'd like to register a component listener that listens to every
component in my application and can configure it appropriately (by
34 matches
Mail list logo
