Re: Validators for lists
No it is a text area giving comma separated input.
Any ways I found what I needed: i.e Validatable: the concrete implementation
of IValidatable which can be used outside wicket components
On Sun, Jul 6, 2008 at 10:25 AM, Johan Compagner [EMAIL PROTECTED]
wrote:
So the list of objects is in this case multiple input fields?
Why do that in a list, just give every email field that validator and
let wicket be the one that iterates of the list. Then you also have
much better feedback to the end user
On 7/5/08, atul singh [EMAIL PROTECTED] wrote:
Can someone please suggest a way to use/extend the current validators to
validate list of objects.
The problem is i have to write code in the following manner and don't
know
if it is a good approach.
EmailAddressValidator validator = EmailAddressValidator.getInstance();
for (final Iterator it =
invitationForm.getEmailList().iterator(); it.hasNext();)
{
validator.validate(new IValidatable()
{
public void error(IValidationError error)
{
form.error(One or More of email ids are not
in
valid format);
}
public Object getValue()
{
return (String)it.next();
}
public boolean isValid()
{
return form.hasError();
}
});
if (form.hasError())
{
break;
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Validators for lists
Can someone please suggest a way to use/extend the current validators to
validate list of objects.
The problem is i have to write code in the following manner and don't know
if it is a good approach.
EmailAddressValidator validator = EmailAddressValidator.getInstance();
for (final Iterator it =
invitationForm.getEmailList().iterator(); it.hasNext();)
{
validator.validate(new IValidatable()
{
public void error(IValidationError error)
{
form.error(One or More of email ids are not in
valid format);
}
public Object getValue()
{
return (String)it.next();
}
public boolean isValid()
{
return form.hasError();
}
});
if (form.hasError())
{
break;
}
}
Re: Weird exceptions. Has anyone seen any exceptions like these
*This is happening on use of ajax tabs...and that too all of them wherever they are in our application.. I remember this happening earlier when there were unclosed img tags:: look at this mail *http://www.mail-archive.com/users@wicket.apache.org/msg15126.html *Is any similar things there I am not aware of? *(Also if we want this exception ignored by shifting to 1.3.4--we probably are trying to ignore what might be going wrong ...I am not so sure about a change in wicket version we use at the moment, nor do we have bandwidth for this) On Mon, Jun 2, 2008 at 12:21 PM, Johan Compagner [EMAIL PROTECTED] wrote: In 1.3.4 this error shouldnt happen, it is just ignored On 6/1/08, atul singh [EMAIL PROTECTED] wrote: Hi, As a result of code integration from various teams we have introduced some change which is causing problems... but the sad part is that we do not know what is happening-- I will loove to know if someone else has seen similar exceptions and how they solved if they were able to:: Also what do these exceptions mean--i mean situation they might happen in?? 1. java.lang.IllegalStateException: No Page found for component [MarkupContainer [Component id = panel, page = No Page, path = at org.apache.wicket.Component.getPage(Component.java:1658) at org.apache.wicket.ajax.AjaxRequestTarget.respondComponent(AjaxRequestTarget.java:689) at org.apache.wicket.ajax.AjaxRequestTarget.respondComponents(AjaxRequestTarget.java:605) at org.apache.wicket.ajax.AjaxRequestTarget.respond(AjaxRequestTarget.java:520) at org.apache.wicket.request.AbstractRequestCycleProcessor.respond(AbstractRequestCycleProcessor.java:104) at org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1172) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feedback message related problem--info,debug etc take string arguments which is not very flexible
I can do that within a day or 2..(Meaning with the patch..).does any core dev see an issue if info,debug etc start taking Serializable as parameter like error().?? Thanks On Mon, Jun 2, 2008 at 10:48 AM, Erik van Oosten [EMAIL PROTECTED] wrote: Hi, Atul, That sounds like a reasonable request to me (I am no core member). Its best to open a new issue in Wicket's jira, preferably with a patch attached. Regards, Erik. atul singh wrote: Hi, I see that only error() feedback takes a serializabel message. This allows me to pass any java object as message and implement custom filtering of messages by components. but info,debug etc take a string and so do not help me in that kind of filtering. Actually what we have is a TabbedWizard thing, a hybrid of TabbedPanel and Wizard. We have such a requirement to target feedback messages to very specific feedback components on any of the tabs. This is also not possible by implementing this logic based on the reporting component. I wanted the implementation to be generic , just based on info encapsulated in the message. Can anyone suggest an alternative? Can the info(),debug() etc method signatures be changed to have such flexibility??? Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
Hello everyone, I feel bad that a vote thread has been converted to one of discussion... At this moment wicket is *for *creating custom components. If these custom component writing gets complicated we will not be able to appreciate wicket as much(as much as we do now).Generics will complicate the *extend* at the moment for new user...I feel(after reading through everything). In core-java , fewer classes aim for extension by user. They rather are end product to be used, to be composed of. The best way still for wicket is *to implement generics partially *and* then start incorporating into OUT-OF-BOX(components less prone to extension) later on in further releases. The fact is that less people can make to wicket core-development team, and then who will maintain the bloat(meaning undesired syntactical features). Who will release non-generics versions for freshers. In Design Patterns I learnt about the open-closed principle. Closed for change and open for extension. Generics forces us to see into a new design pattern---Generify the the most closed only, based on use cases--If there is more of a need of extension of classes by end user AND there is flexibility while extending(wicket is one case which is flexible when you extend)--then wait, do not generify. * On Mon, Jun 2, 2008 at 11:03 PM, Bernard Niset [EMAIL PROTECTED] wrote: Hi all, [X] Can best be done in a limited fashion, where we only generify IModel but not components. I care more about what generifying can do for API clarity (declaring a component to only accept certain models for instance) than static type checking. [X] I might rethink upgrading if my choice doesn't win. I didn't try wicket 1.4 yet, but I read questions and comments from users in this list. My impression so far has been that there has been a small design mistake in the way the current 1.4 implementation has been done. I perceive that IModelT is conceptually correct as a Model can be seen as a container of something (of type T). Writing DropDownChoiceT is a shortcut that does not seem conceptually correct as in this case, the component is not a container of type T but a container of type IModelT. So you should have something like DropDownChoiceIModelT (I know this not valid java). Generifying the Page component is even worse as possibly a page can hold components with different model types and not have a model type on its own. Also, wicket is designed to allow some components not to have model on their own and rely on the model stored in a parent component (very nice and powerful feature). Please note that using generic this way is already possible with wicket 1.3 if you define an interface that would be for instance IMyModelT extends IModel. For instance, I have a generic model defined as DetachableBeanModelK,T where K is the key type and T is the bean type. This type is indeed a container of a key element and of a bean element. I hope it helps, Bernard. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
Point!--but i thought it is intended to extract a survey kind of info(with explanation if one has one) Just that the information here is overflowing with untraceable debates On Tue, Jun 3, 2008 at 12:47 AM, Bernard Niset [EMAIL PROTECTED] wrote: Hi Atul, Please read again the initial post from Eelco. He explicitly wrote: Note that it is not a vote; we only want to get an idea of what you think. and further away: Thanks in advance for everyone participating, and pls feel free to explain yourself further beyond just answering these questions!. Bernard. atul singh a écrit : Hello everyone, I feel bad that a vote thread has been converted to one of discussion... At this moment wicket is *for *creating custom components. If these custom component writing gets complicated we will not be able to appreciate wicket as much(as much as we do now).Generics will complicate the *extend* at the moment for new user...I feel(after reading through everything). In core-java , fewer classes aim for extension by user. They rather are end product to be used, to be composed of. The best way still for wicket is *to implement generics partially *and* then start incorporating into OUT-OF-BOX(components less prone to extension) later on in further releases. The fact is that less people can make to wicket core-development team, and then who will maintain the bloat(meaning undesired syntactical features). Who will release non-generics versions for freshers. In Design Patterns I learnt about the open-closed principle. Closed for change and open for extension. Generics forces us to see into a new design pattern---Generify the the most closed only, based on use cases--If there is more of a need of extension of classes by end user AND there is flexibility while extending(wicket is one case which is flexible when you extend)--then wait, do not generify. * On Mon, Jun 2, 2008 at 11:03 PM, Bernard Niset [EMAIL PROTECTED] wrote: Hi all, [X] Can best be done in a limited fashion, where we only generify IModel but not components. I care more about what generifying can do for API clarity (declaring a component to only accept certain models for instance) than static type checking. [X] I might rethink upgrading if my choice doesn't win. I didn't try wicket 1.4 yet, but I read questions and comments from users in this list. My impression so far has been that there has been a small design mistake in the way the current 1.4 implementation has been done. I perceive that IModelT is conceptually correct as a Model can be seen as a container of something (of type T). Writing DropDownChoiceT is a shortcut that does not seem conceptually correct as in this case, the component is not a container of type T but a container of type IModelT. So you should have something like DropDownChoiceIModelT (I know this not valid java). Generifying the Page component is even worse as possibly a page can hold components with different model types and not have a model type on its own. Also, wicket is designed to allow some components not to have model on their own and rely on the model stored in a parent component (very nice and powerful feature). Please note that using generic this way is already possible with wicket 1.3 if you define an interface that would be for instance IMyModelT extends IModel. For instance, I have a generic model defined as DetachableBeanModelK,T where K is the key type and T is the bean type. This type is indeed a container of a key element and of a bean element. I hope it helps, Bernard. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Weird exceptions. Has anyone seen any exceptions like these
Hi, As a result of code integration from various teams we have introduced some change which is causing problems... but the sad part is that we do not know what is happening-- I will loove to know if someone else has seen similar exceptions and how they solved if they were able to:: Also what do these exceptions mean--i mean situation they might happen in?? 1. java.lang.IllegalStateException: No Page found for component [MarkupContainer [Component id = panel, page = No Page, path = at org.apache.wicket.Component.getPage(Component.java:1658) at org.apache.wicket.ajax.AjaxRequestTarget.respondComponent(AjaxRequestTarget.java:689) at org.apache.wicket.ajax.AjaxRequestTarget.respondComponents(AjaxRequestTarget.java:605) at org.apache.wicket.ajax.AjaxRequestTarget.respond(AjaxRequestTarget.java:520) at org.apache.wicket.request.AbstractRequestCycleProcessor.respond(AbstractRequestCycleProcessor.java:104) at org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1172) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Weird exceptions. Has anyone seen any exceptions like these
Thanks, But i am sure, that is not happening ..I looked at all that code.. Any other suggestions/guesses?? On Mon, Jun 2, 2008 at 12:09 AM, Maurice Marrink [EMAIL PROTECTED] wrote: Are you by any chance replacing components? This could happen if you let the ajax render a component that has been removed from the page. Maurice On Sun, Jun 1, 2008 at 7:32 PM, atul singh [EMAIL PROTECTED] wrote: Hi, As a result of code integration from various teams we have introduced some change which is causing problems... but the sad part is that we do not know what is happening-- I will loove to know if someone else has seen similar exceptions and how they solved if they were able to:: Also what do these exceptions mean--i mean situation they might happen in?? 1. java.lang.IllegalStateException: No Page found for component [MarkupContainer [Component id = panel, page = No Page, path = at org.apache.wicket.Component.getPage(Component.java:1658) at org.apache.wicket.ajax.AjaxRequestTarget.respondComponent(AjaxRequestTarget.java:689) at org.apache.wicket.ajax.AjaxRequestTarget.respondComponents(AjaxRequestTarget.java:605) at org.apache.wicket.ajax.AjaxRequestTarget.respond(AjaxRequestTarget.java:520) at org.apache.wicket.request.AbstractRequestCycleProcessor.respond(AbstractRequestCycleProcessor.java:104) at org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1172) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
1) [ X] Can best be done in a limited fashion, where we only generify IModel but not components. I care more about what generifying can do for API clarity (declaring a component to only accept certain models for instance) than static type checking. *Reason::* I think generifying data-structure/models is what is sustainable. Components can become too complicated when gentrified..and who know how far wicket wants to go!! 2) [X] I definitively won't be using 1.4. if Wicket doesn't go for my preference. On Mon, Jun 2, 2008 at 2:14 AM, Eelco Hillenius [EMAIL PROTECTED] wrote: Hi all, We have had several threads in this and the dev list, and some discussions in the public on how to incorporate generics in Wicket. I'd like to use this thread to gather the opinions of as many regular Wicket users as we can. Please help us get an impression of what our users think about the issue by completing this simple survey. Note that it is not a vote; we only want to get an idea of what you think. 1) Generifying* Wicket [ ] Can best be done like currently in the 1.4 branch, where models and components are both generified. I care most about the improved static type checking generified models and components give Wicket. [ ] Can best be done in a limited fashion, where we only generify IModel but not components. I care more about what generifying can do for API clarity (declaring a component to only accept certain models for instance) than static type checking. [ ] Should be avoided, I prefer the way 1.3 works. Because... (fill in your opinion here). [ ] (anything other than these choices?) 2) How strongly do you feel about your choice above? [ ] Whatever choice ultimately made, I'll happily convert/ start using 1.4 and up. [ ] I might rethink upgrading if my choice doesn't win. [ ] I definitively won't be using 1.4. if Wicket doesn't go for my preference. Thanks in advance for everyone participating, and pls feel free to explain yourself further beyond just answering these questions! Eelco p.s. I suggest that the core devs and most active participants and previous discussions wait a few days before giving their opinions so that we don't flood the thread right from the start. * Parameterizing would probably be the better word to use, but generifying seems to be the word that many people use. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: (Class? extends Page?) casting troubles
As a java user I never missed generics. Following opinion is just what i feel... a) ClassCastExceptions never wasted my time more than a few minutes. b)Also the advantage of code that spoke for itself could only be achieved through a good developer (generics is not the cure to this, and many can achieve this to some extent without generics). c)One should look at this aspect for new features in wicket-- generics included:: time spent on solving a problem by the end user VS avoiding it by providing an out-of-box solution. IMO generics support IS NOT REQUIRED based on above factor, and the time spent can be invested on some better solutions/problems/use-cases. On Sat, May 24, 2008 at 6:47 PM, Gwyn Evans [EMAIL PROTECTED] wrote: On Sat, May 24, 2008 at 11:42 AM, John Patterson [EMAIL PROTECTED] wrote: The reason I put LinkGeneric rather than GenericLink was simply so that the two options would appear next to each other in code completions. But of course in English GenericLink is more correct. Good point regarding completions. Anyway, flexible, english is! Hmm. /Gwyn - http://www.yodaspeak.co.uk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AbstractDefaultAjaxBehavior ....shows the ajax indicator even if precondition script returns false.
*https://issues.apache.org/jira/browse/WICKET-1550* On Thu, Apr 17, 2008 at 7:48 AM, Igor Vaynberg [EMAIL PROTECTED] wrote: file a bug in jira please -igor On Wed, Apr 16, 2008 at 6:52 PM, atul singh [EMAIL PROTECTED] wrote: AbstractDefaultAjaxBehavior shows the ajax indicator even if precondition script returns false. That means no call will be made actually to the server right(And hence no indicator should be shown). I know i can have my own implementation to get this, but i wanted to use IAjaxIndicatorAware Should i file a bug about this?? (In my particular scenario it keeps showing all the time, though i go to the server only when a javascript variable returns true) Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
javascript error in internet explorer
Hi,
I wanted to know about preCallHandlers in wicket-ajax.js .What are they and
How are they related in java code.
Actually I am facing a problem in internet explorer. The ajax get call give
error after Invoking pre-call handler(s)..
It gives an error in the highlighted portion and then all ajax stops
working, because this get call did not return.
The error says--invalid argument
I will really appreciate any help. Also if anyone know a javascript
debugger/debugging technique for internet explorer, please let me know, so i
will be able to do something about this :(..
Thanks
doGet: function() {
if (this.precondition()) {
this.transport = Wicket.Ajax.getTransport();
var url = this.createUrl();
this.log(GET, url);
Wicket.Ajax.invokePreCallHandlers();
* var t = this.transport;**
if (t != null) {
if (Wicket.Browser.isGecko()) {
var href = document.location.href;
var lastIndexOf = href.lastIndexOf('/');
if (lastIndexOf 0)
{
url = href.substring(0,lastIndexOf+1) + url;
}
}
t.open(GET, url, this.async);
t.onreadystatechange = this.stateChangeCallback.bind(this);
// set a special flag to allow server distinguish between
ajax and non-ajax requests
t.setRequestHeader(Wicket-Ajax, true);
t.setRequestHeader(Wicket-FocusedElementId,
Wicket.Focus.lastFocusId || );
t.setRequestHeader(Accept, text/xml);
t.send(null);
return true;*
} else {
this.failure();
return false;
}
} else {
Wicket.Log.info(Ajax GET stopped because of precondition check,
url: + this.url);
this.done();
return true;
}
}
AbstractDefaultAjaxBehavior ....shows the ajax indicator even if precondition script returns false.
AbstractDefaultAjaxBehavior shows the ajax indicator even if precondition script returns false. That means no call will be made actually to the server right(And hence no indicator should be shown). I know i can have my own implementation to get this, but i wanted to use IAjaxIndicatorAware Should i file a bug about this?? (In my particular scenario it keeps showing all the time, though i go to the server only when a javascript variable returns true) Thanks
Re: CheckGroupSelector problem
But I feel this should be the default behavior of the selector check-box.Don't you think so? On Sun, Apr 13, 2008 at 7:58 AM, Ryan Holmes [EMAIL PROTECTED] wrote: Looks like CheckGroupSelector does not have a model. You could create a behavior (e.g. by subclassing AbstractBehavior) that would initialize the CheckGroupSelector based on its Check components. In your behavior's renderHead(IHeaderResponse) method, you could render onLoad or onDomReady JavaScript that would iterate over the Check elements and set a flag if any of them are not checked. You would then set the CheckGroupSelector's 'checked' value based on that flag. See CheckGroupSelector.onComponentTag(ComponentTag) for an example of the main JavaScript involved (i.e. finding and iterating through the Check elements). -Ryan On Thu, Apr 10, 2008 at 10:22 AM, atul singh [EMAIL PROTECTED] wrote: I am facing an issue with CheckGroupSelector. CheckGroupSelector is not showing itself selected, though all of the Check's in the CheckGroup come pre-selected based on the underlying model i am setting up. (That means I have the CheckGroup's list model already populated with all individual Check's models). Is this because CheckGroupSelector does not have a model for itself? OR am I missing something???
Re: FeedbackPanel ul has no class
I find the class attribute feedbackPanelERROR in my error feedback for
wicket1.3.0 beta2
Does this mean that this was removed from feedback panel in further
version..?
On Sun, Apr 6, 2008 at 2:56 AM, Matthew Young [EMAIL PROTECTED] wrote:
Jira added: https://issues.apache.org/jira/browse/WICKET-1485
On Sat, Apr 5, 2008 at 2:11 PM, Igor Vaynberg [EMAIL PROTECTED]
wrote:
you can just subclass the panel and provide your own markup with the
class on the ul. also add a jira issue to have it added to the core
panel
-igor
On Sat, Apr 5, 2008 at 2:08 PM, Matthew Young [EMAIL PROTECTED] wrote:
The book is incorrect. There is no class attribute in the ul tag
and
there is no way to add one through FeedbackPanel class. But you can
do
this:
div class=feedbackPanel wicket:id=feedbackF/div
and style the feedback ul:
.feedbackPanel ul {
etc etc
}
On Sat, Apr 5, 2008 at 12:57 PM, Zach Cox [EMAIL PROTECTED] wrote:
In the latest early access version of Wicket in Action, page 202,
it
gives this as the markup that FeedbackPanel produces:
ul class=feedbackPanel
li class=feedbackPanelERROR
span class=feedbackPanelERRORField 'name' is
required./span
/li
/ul
However, in real usage the ul element has no class attribute. Is
this
a bug in Wicket 1.3.2 or am I missing something?
Thanks,
Zach
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
unclosed img src= leading to trouble
I by mistake had this tag *img src=* left in my markup. I was experiencing a lot of other issues because of this, and I don't know why. The problems were the following:: 1. An ajax link ,when clicked, not found on its page org.apache.wicket.WicketRuntimeException: component somewicketpath:link not found on page somepage listener interface = [RequestListenerInterface name=IBehaviorListener, method=public abstract void org.apache.wicket.behavior.IBehaviorListener.onRequest()] at org.apache.wicket.request.AbstractRequestCycleProcessor.resolveListenerInterfaceTarget (AbstractRequestCycleProcessor.java:394) at org.apache.wicket.request.AbstractRequestCycleProcessor.resolveRenderedPage( AbstractRequestCycleProcessor.java:440) at org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve( WebRequestCycleProcessor.java:139) 2. When repainting a component via ajax--markup id of my html element not the same as what is expected by ajax repaint. 3. Similar issues as if there was something wrong going on, *(And wicket was not complaining anything).* Does anyone have an idea on what might be happening. If required I can send across a small quick start.( this can be simulated very easily by adding img src= ).
Re: Planning Wicket Next Generation
java 5 now definitely On Sun, Mar 16, 2008 at 7:48 PM, James Carman [EMAIL PROTECTED] wrote: On 3/16/08, Maarten Bosteels [EMAIL PROTECTED] wrote: +1 for moving to java 5 +1 for moving to Java 5 *quickly* :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AjaxBehaviour how to question
Thank you for the isTemporary() suggestion.. . BTW before i got your reply i
tried implementing following way, by extending AbstractBehavior , not sure
if this is a good way..
@Override
public void onRendered(Component component) {
IRequestTarget reqTarget = RequestCycle.get()
.getRequestTarget();
if (reqTarget!=null reqTarget instanceof AjaxRequestTarget) {
AjaxRequestTarget ajaxTarget = (AjaxRequestTarget)
RequestCycle
.get().getRequestTarget();
if (ajaxTarget != null) {
ajaxTarget.appendJavascript(new Effect.Fade($('
+ component.getMarkupId() + ')););
}
}
}
Is it possible to have a chaining behaviour class in wicket which is not a
request listener??
On Mon, Mar 10, 2008 at 12:11 PM, Igor Vaynberg [EMAIL PROTECTED]
wrote:
there are two ways to do it:
either use ajaxrequesttarget.appendjavascript() instead of behavior
or write a behavior that uses renderhead() to output the javascript
and override istemporary to return true - that way it is removed at
the end of the request.
-igor
On Sun, Mar 9, 2008 at 6:39 PM, atul singh [EMAIL PROTECTED] wrote:
How can i write an ajax behaviour which does not have its own callback,
but
just appends javascript to an existing AjaxRequestTarget.
I want this so that i can write a fading feed back panel, which will be
added to AjaxRequestTarget of an ajax form submission.
What I want is something like this::
*the behaviour---*
public class AjaxFadeBehaviour extends AbstractAjaxBehavior{
private IModel fadingNeededIModel;
public AjaxFadeBehaviour() {
super();
}
/**
* Use a boolean value wrapped in an IModel to know if fading effect
is
needed.
* This can be useful in situations for example when info messages
need
to fade away while error messages need not.
* @param fadingNeededIModel
*/
public AjaxFadeBehaviour(IModel fadingNeededIModel) {
super();
this.fadingNeededIModel = fadingNeededIModel;
}
public void onRequest() {
System.out.println(on request called);
if(fadingNeededIModel!=null){
if(Strings.isTrue((String) fadingNeededIModel.getObject()))
((AjaxRequestTarget)RequestCycle.get().getRequestTarget()).appendJavascript(new
Effect.Fade($('
+ getComponent().getMarkupId() + ')););
}
}
}
*the feedback component ---
*public class AjaxFadingFeedbackPanel extends FeedbackPanel{
public AjaxFadingFeedbackPanel(String id, IFeedbackMessageFilter
filter)
{
super(id, filter);
setOutputMarkupId(true);
final AbstractReadOnlyModel fadingNeededModel=new
AbstractReadOnlyModel(){
@Override
public Object getObject() {
return anyMessage(FeedbackMessage.INFO);
}
};
add(new AjaxFadeBehaviour(fadingNeededModel));
}
public AjaxFadingFeedbackPanel(String id) {
this(id,null);
}
}
I am not able to achieve this because onRequest() does not get called
for
AjaxFadeBehaviour.
I am confused about which class I should extend to achieve this??
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: AjaxBehaviour how to question
Also, does returning true for isTemporary re-render any javascript resource
reference??
On Mon, Mar 10, 2008 at 4:30 PM, atul singh [EMAIL PROTECTED] wrote:
Thank you for the isTemporary() suggestion.. . BTW before i got your reply
i tried implementing following way, by extending AbstractBehavior , not sure
if this is a good way..
@Override
public void onRendered(Component component) {
IRequestTarget reqTarget = RequestCycle.get()
.getRequestTarget();
if (reqTarget!=null reqTarget instanceof AjaxRequestTarget) {
AjaxRequestTarget ajaxTarget = (AjaxRequestTarget)
RequestCycle
.get().getRequestTarget();
if (ajaxTarget != null) {
ajaxTarget.appendJavascript(new Effect.Fade($('
+ component.getMarkupId() + ')););
}
}
}
Is it possible to have a chaining behaviour class in wicket which is not a
request listener??
On Mon, Mar 10, 2008 at 12:11 PM, Igor Vaynberg [EMAIL PROTECTED]
wrote:
there are two ways to do it:
either use ajaxrequesttarget.appendjavascript() instead of behavior
or write a behavior that uses renderhead() to output the javascript
and override istemporary to return true - that way it is removed at
the end of the request.
-igor
On Sun, Mar 9, 2008 at 6:39 PM, atul singh [EMAIL PROTECTED]
wrote:
How can i write an ajax behaviour which does not have its own
callback, but
just appends javascript to an existing AjaxRequestTarget.
I want this so that i can write a fading feed back panel, which will
be
added to AjaxRequestTarget of an ajax form submission.
What I want is something like this::
*the behaviour---*
public class AjaxFadeBehaviour extends AbstractAjaxBehavior{
private IModel fadingNeededIModel;
public AjaxFadeBehaviour() {
super();
}
/**
* Use a boolean value wrapped in an IModel to know if fading
effect is
needed.
* This can be useful in situations for example when info messages
need
to fade away while error messages need not.
* @param fadingNeededIModel
*/
public AjaxFadeBehaviour(IModel fadingNeededIModel) {
super();
this.fadingNeededIModel = fadingNeededIModel;
}
public void onRequest() {
System.out.println(on request called);
if(fadingNeededIModel!=null){
if(Strings.isTrue((String) fadingNeededIModel.getObject
()))
((AjaxRequestTarget)RequestCycle.get().getRequestTarget()).appendJavascript(new
Effect.Fade($('
+ getComponent().getMarkupId() + ')););
}
}
}
*the feedback component ---
*public class AjaxFadingFeedbackPanel extends FeedbackPanel{
public AjaxFadingFeedbackPanel(String id, IFeedbackMessageFilter
filter)
{
super(id, filter);
setOutputMarkupId(true);
final AbstractReadOnlyModel fadingNeededModel=new
AbstractReadOnlyModel(){
@Override
public Object getObject() {
return anyMessage(FeedbackMessage.INFO);
}
};
add(new AjaxFadeBehaviour(fadingNeededModel));
}
public AjaxFadingFeedbackPanel(String id) {
this(id,null);
}
}
I am not able to achieve this because onRequest() does not get called
for
AjaxFadeBehaviour.
I am confused about which class I should extend to achieve this??
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Confine feedback messages to a panel
hi, I have an ajax checkbox, which when checked, i show a feedback at the top of the panel. Due to this event another panel on the same page is repainted and made visible. The problem is I see the feedback message in the feedback component present in the other panel as well. I feel this is because the feedback messages are shared in the session?? I thought I will be able to google out the solution, but could not find anything...Any suggestion about this problem ??
AjaxBehaviour how to question
How can i write an ajax behaviour which does not have its own callback, but
just appends javascript to an existing AjaxRequestTarget.
I want this so that i can write a fading feed back panel, which will be
added to AjaxRequestTarget of an ajax form submission.
What I want is something like this::
*the behaviour---*
public class AjaxFadeBehaviour extends AbstractAjaxBehavior{
private IModel fadingNeededIModel;
public AjaxFadeBehaviour() {
super();
}
/**
* Use a boolean value wrapped in an IModel to know if fading effect is
needed.
* This can be useful in situations for example when info messages need
to fade away while error messages need not.
* @param fadingNeededIModel
*/
public AjaxFadeBehaviour(IModel fadingNeededIModel) {
super();
this.fadingNeededIModel = fadingNeededIModel;
}
public void onRequest() {
System.out.println(on request called);
if(fadingNeededIModel!=null){
if(Strings.isTrue((String) fadingNeededIModel.getObject()))
((AjaxRequestTarget)RequestCycle.get().getRequestTarget()).appendJavascript(new
Effect.Fade($('
+ getComponent().getMarkupId() + ')););
}
}
}
*the feedback component ---
*public class AjaxFadingFeedbackPanel extends FeedbackPanel{
public AjaxFadingFeedbackPanel(String id, IFeedbackMessageFilter filter)
{
super(id, filter);
setOutputMarkupId(true);
final AbstractReadOnlyModel fadingNeededModel=new
AbstractReadOnlyModel(){
@Override
public Object getObject() {
return anyMessage(FeedbackMessage.INFO);
}
};
add(new AjaxFadeBehaviour(fadingNeededModel));
}
public AjaxFadingFeedbackPanel(String id) {
this(id,null);
}
}
I am not able to achieve this because onRequest() does not get called for
AjaxFadeBehaviour.
I am confused about which class I should extend to achieve this??
Re: CompoundModel based on proxies
I feel this approach does NOT solve a problem.Its just an alternative .. On Tue, Feb 26, 2008 at 4:48 PM, Matej Knopp [EMAIL PROTECTED] wrote: We've reworked the implementation a bit,it works like this: SafePropertyModelPerson p = new SafePropertyModelPerson(new Person()); TextField field = new TextField(name, p.bind(p.property ().getFirstName())); It's attached to the JIRA issue: https://issues.apache.org/jira/browse/WICKET-1327 -Matej On Tue, Feb 26, 2008 at 11:32 AM, Sebastiaan van Erk [EMAIL PROTECTED] wrote: Matej Knopp wrote: Hi, On Tue, Feb 26, 2008 at 11:13 AM, Sebastiaan van Erk [EMAIL PROTECTED] wrote: Matej Knopp wrote: model.getFirstName() can't really return IModel, if Customer.getFirstName() returns string. Anyway, I like the idea, but I don't like the syntax. instead of one line [add(new TextField(id, model).setRequred(true)) ] you have now three separate lines. So I was thinking of something more like SafePropertyModelCustomer model = new SafePropertyModelCustomer(customer); add(new TextField(tf, model.bind(model.proxy ().getCustomerName() )).setRequired(true)); This way you can have it one one line. -Matej So proxy() returns a Customer proxy? And model.bind() takes an Object argument (considering we don't know in advance what type getCustomerName() returns)... What about primitive types? Overload bind() for those as well? Well, the return object is not important at all. What is important is the getCustomerName() call. That marks somewhere in the model that last accessed property was called customerName. and then immediately after this model.bind takes this information. OK, that's what I described. :-) And I was being stupid with respect to the overloading. If bind takes an object as argument, then overloading will not be necessary due to autoboxing. :-) And the call to getCustomerName() has the side effect of setting a model object somewhere (e.g., in an instance field of model) which model.bind() can subsequently return? Model bind will return a model (variation of propertymodel probably). It will take the information that getCustomerName call on proxy provided. Ok, so the proxy remembers which getter was called last, and you use that to construct the model in bind(). Of course. Very interesting. I don't like the proxy() method name though. If you call it something like property() it will look more like you're binding to a property of Customer: Well, the naming can certainly be improved. I'm not sure about property() though. Well, we can discuss this more anyway. model.bind(model.property().getCustomerName()) Neither am I. :-) For one, it's quite long. But on the other hand, you do bind to a model property, and so it reads ok. I think that proxies should be invisible for general users, so they shouldn't have to understand the magic going on here, nor that proxies are involved. VERY neat idea though... :-) Thanks. What I really like about this solution is that it can be implemented completely separately from wicket-core, so you can just put it in it's own project. :-) Regards, Sebastiaan -Matej Regards, Sebastiaan On Fri, Feb 8, 2008 at 6:17 PM, Johan Compagner [EMAIL PROTECTED] wrote: don't worry about creating the models That will happen anyway in 1.3 (that needs to be done for example to get the right object especially when we generify stuff) see CompoundPropertyModel.wrapOnInheritance() joan On Feb 8, 2008 5:41 PM, Scott Swank [EMAIL PROTECTED] wrote: Interesting. So model.getFirstName() would return a PropetyModel based on the results of proxy.eval()? If I understand you correctly that creates many models (one per component) instead of reusing a single model, but that may well not be the end of the world. Or does getFirstName() return a CompoundModel that is properly bound this this component? Intriguing none the less. I hadn't considered this option, but I'm going to play with it a bit. I rather like that direction. On Feb 8, 2008 8:29 AM, Johan Compagner [EMAIL PROTECTED] wrote: i try to look at this this weekend, but i have a quick question I find it a bit verbose can't it be a bit shorter like this (just an example) SharedPropertyModelCustomer model = new SharedPropertyModelCustomer(customer); this.setModel(model); FormComponent firstName = new CustomerNameField(firstName,
Using javascript limits me from having an immersive user interface:Re: Add row to list of items on a page dynamically via ajax without repainting whole list
Thanks for the pointer. I tried to follow what is in the link. http://www.nabble.com/Adding-item-to-ListView-over-Ajax---refresh-only-newest-row-td11272937.html Still I am facing a lot of serious problem. I am trying to generate html for the new row as said using javascript. I add the item manually, and after adding it use its markup id in the html generated using javascript. but I would need the markup id of many of the children of the item also. *Using javascript like this limits me from having an immersive ajax user interface for the row generated using javascript.* Can someone think of a way to achieve this using components?? On Jan 22, 2008 12:31 PM, Peter Thomas [EMAIL PROTECTED] wrote: On 1/22/08, atul singh [EMAIL PROTECTED] wrote: Hi I want to add a new row on my page using ajax, without having to repaint the complete list already being displayed on the page. This i want to reduce the ajax payload;any help on how i can do this? Try this thread: http://www.nabble.com/Adding-item-to-ListView-over-Ajax---refresh-only-newest-row-td11272937.html
Re: Using javascript limits me from having an immersive user interface:Re: Add row to list of items on a page dynamically via ajax without repainting whole list
Sorry for this post ..I think my problem is solved(Once i added the item to ajaxrequesttarget which is what i was forgetting)...I do not need to bother about creating the children of the item using javascript...They are just in place after the page is rendered... On Jan 26, 2008 8:56 PM, atul singh [EMAIL PROTECTED] wrote: Thanks for the pointer. I tried to follow what is in the link. http://www.nabble.com/Adding-item-to-ListView-over-Ajax---refresh-only-newest-row-td11272937.html Still I am facing a lot of serious problem. I am trying to generate html for the new row as said using javascript. I add the item manually, and after adding it use its markup id in the html generated using javascript. but I would need the markup id of many of the children of the item also. *Using javascript like this limits me from having an immersive ajax user interface for the row generated using javascript.* Can someone think of a way to achieve this using components?? On Jan 22, 2008 12:31 PM, Peter Thomas [EMAIL PROTECTED] wrote: On 1/22/08, atul singh [EMAIL PROTECTED] wrote: Hi I want to add a new row on my page using ajax, without having to repaint the complete list already being displayed on the page. This i want to reduce the ajax payload;any help on how i can do this? Try this thread: http://www.nabble.com/Adding-item-to-ListView-over-Ajax---refresh-only-newest-row-td11272937.html
Use of detachable model in pageable view
Hi all, From my analysis it seems that the items which are visible in the current page are the only ones in session. If i have a pagesize of 10 objects and i have 1 users searching, it would mean lot of data in session. Thus I think I should use detachable models in pageable views. I just want to know if i have got anything wrong in concluding this design of mine? (Can i cache data in session , or how much of caching can i support..?)
Add row to list of items on a page dynamically via ajax without repainting whole list
Hi I want to add a new row on my page using ajax, without having to repaint the complete list already being displayed on the page. This i want to reduce the ajax payload;any help on how i can do this?
