Cannot detect ModalWindow cancel

I have a ModalWindow where I need to know if the user saved in the 
WindowClosedCallback or if they chose to click the X to close the 
window.  To do this in Wicket 1.4, I just set a variable on the page 
that the ModalWindow gets in the PageCreator and then check the variable 
in the WindowClosedCallback.  When I try this in Wicket 1.5 it doesn't 
work.  My variable retains the value I initialized it to and not the 
value I updated it to when I submitted the form on the ModalWindow 
page.  I am attaching a quickstart with the 1.5.4 version of Wicket.  
This is where the bug appears.  I updated the POM and a few files to 
test the same code with 1.4.19 and it works.

--

-- 
Jered Myers

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe <at> wicket.apache.org
For additional commands, e-mail: users-help <at> wicket.apache.org

Wicket-Source: Click-through from browser back to Java source

Working on someone else's complex wicket pages can result in a lot of time
spent hunting for components in the source. What if you could click on an
item in the web page and jump straight to the line of Java source that
created it?

The net.ftlines.wicket-source module, plus a couple of plugins, lets you do
just that. There are three parts - a module for your WicketApplication, a
Firefox plugin, and an Eclipse plugin.

1. Wicket module records where in the source code each component is
constructed and saves it in an HTML attribute.
2. Firebug extension displays the html attribute in Firebug's sidebar and
lets you click to open it in Eclipse. (Chrome extension pending.)
3. Eclipse plugin listens for clicks from Firefox and opens the file to
that line of the Java source.

These three pieces together close the circle from wicket components and
html rendering, to the browser, and back to the wicket component source,
speeding work on existing but unfamiliar pages, and making minor wording
tweaks quick and easy.

For more information and installation, check out
https://www.42lines.net/2012/01/31/announcing-wicket-source/

Release 1.5.0_06 is available in maven central.  1.5.0.7-SNAPSHOT contains
a bug fix for ajax components.

Jenny Brown

Re: Wicket-Source: Click-through from browser back to Java source

looks awesome.  can't wait to try it.

--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-Source-Click-through-from-browser-back-to-Java-source-tp4346532p4346698.html
Sent from the Users forum mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe <at> wicket.apache.org
For additional commands, e-mail: users-help <at> wicket.apache.org

Re: Wicket-Source: Click-through from browser back to Java source

Awesome indeed!

@Minas: how hard is to integrate this in WicketForge (IDEA users) ? 

On Wed, Feb 1, 2012 at 3:21 AM, Jenny Brown <jennybrown8 <at> gmail.com> wrote:
> Working on someone else's complex wicket pages can result in a lot of time
> spent hunting for components in the source. What if you could click on an
> item in the web page and jump straight to the line of Java source that
> created it?
>
> The net.ftlines.wicket-source module, plus a couple of plugins, lets you do
> just that. There are three parts - a module for your WicketApplication, a
> Firefox plugin, and an Eclipse plugin.
>
> 1. Wicket module records where in the source code each component is
> constructed and saves it in an HTML attribute.
> 2. Firebug extension displays the html attribute in Firebug's sidebar and
> lets you click to open it in Eclipse. (Chrome extension pending.)
> 3. Eclipse plugin listens for clicks from Firefox and opens the file to
> that line of the Java source.
>
> These three pieces together close the circle from wicket components and
> html rendering, to the browser, and back to the wicket component source,
> speeding work on existing but unfamiliar pages, and making minor wording
> tweaks quick and easy.
>
> For more information and installation, check out
> https://www.42lines.net/2012/01/31/announcing-wicket-source/
>
> Release 1.5.0_06 is available in maven central.  1.5.0.7-SNAPSHOT contains

Re: Google bot see my site with errors!!

On Wed, Feb 1, 2012 at 1:01 AM, Paolo <irresistiblecam <at> gmail.com> wrote:
> Alle martedì 31 gennaio 2012, Martin Grigorov ha scritto:
>> What exactly is the code at: org.wicket.example.QuoteResult. <init>
>> (QuoteResult.java: 55) ?
>
> package org.wicket.example;
>
> import java.util.Locale;
>
> import javax.servlet.http.HttpServletRequest;
>
> import org.apache.wicket.markup.html.WebMarkupContainer;
> import org.apache.wicket.Component;
> import org.apache.wicket.behavior.AbstractBehavior;
> import org.apache.wicket.markup.html.IHeaderResponse;
> import org.apache.wicket.markup.html.internal.HeaderResponse;
> import org.apache.wicket.markup.ComponentTag;
> import org.apache.wicket.behavior.SimpleAttributeModifier;
> import org.apache.wicket.markup.html.WebPage;
> import org.apache.wicket.markup.html.form.DropDownChoice;
> import org.apache.wicket.markup.html.form.Form;
> import org.apache.wicket.markup.html.form.TextField;
> import org.apache.wicket.markup.html.panel.FeedbackPanel;
> import org.apache.wicket.markup.html.link.*;
> import org.apache.wicket.model.Model;
> import org.apache.wicket.PageParameters;
> import org.apache.wicket.markup.html.basic.Label;
> import org.apache.wicket.protocol.http.WebRequest;
> import org.apache.wicket.protocol.http.WebResponse;
> import org.apache.wicket.request.target.coding.QueryStringUrlCodingStrategy;

Re: Cannot detect ModalWindow cancel

Hi Jered,

this is a known issue, you can find more informations here: 
https://issues.apache.org/jira/browse/WICKET-3809
> I have a ModalWindow where I need to know if the user saved in the 
> WindowClosedCallback or if they chose to click the X to close the 
> window.  To do this in Wicket 1.4, I just set a variable on the page 
> that the ModalWindow gets in the PageCreator and then check the 
> variable in the WindowClosedCallback.  When I try this in Wicket 1.5 
> it doesn't work.  My variable retains the value I initialized it to 
> and not the value I updated it to when I submitted the form on the 
> ModalWindow page.  I am attaching a quickstart with the 1.5.4 version 
> of Wicket.  This is where the bug appears.  I updated the POM and a 
> few files to test the same code with 1.4.19 and it works.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe <at> wicket.apache.org
> For additional commands, e-mail: users-help <at> wicket.apache.org

Re: Wicket-Source: Click-through from browser back to Java source

Sounds great! Would be nice to have it for IDEA too... will look into it. 

--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-Source-Click-through-from-browser-back-to-Java-source-tp4346532p4347366.html
Sent from the Users forum mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe <at> wicket.apache.org
For additional commands, e-mail: users-help <at> wicket.apache.org

RE: Wiquery and JQWicket crash each other!!!!

Better late than never:

To respond to your question again: why would you want to use both? They seem to do the same thing...

Hielke

-----Original Message-----
From: atomix [mailto:say_i_love_you_4ever <at> yahoo.com] 
Sent: donderdag 26 januari 2012 21:14
To: users <at> wicket.apache.org
Subject: Re: Wiquery and JQWicket crash each other!!!!

I got answer from Wiquey developer :

"Hi!

JQWicket and WiQuery do not work well together. Both aim to do the same but using a different approach.
Choose either one, not both. 

When you add WiQuery to the classpath it installs itself using a Wicket Initializer and sets a
HeaderResponseDecorator. The HeaderResponseDecorator manages all resource references when they are
of a certain type and manages the jQuery initializing statements."

Now , my question is : Did anyone have a solution for Wiquery and JQWicket work together, it's really a pity
that we can't use them both!

--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wiquery-and-JQWicket-crash-each-other-tp4330840p4331638.html
Sent from the Users forum mailing list archive at Nabble.com.

Re: Stateless and Ajax

Thank you all involved in this thread. With your help, I managed to build a
login/registration form, totally stateless and submitted with ajax. (Thanks,
Robert, for the referenced component, it works really good).

This was a proof of concept for me that such a page could be built in
Wicket. I want to continue further with my project in a completely stateless
manner. However, I see my project using many more complicated ajax
components (ajax-autocomplete, etc.), also incorporating jqwicket library
for integration with Jquery UI.

Is it possible to continue with this arsenal of stateless ajax components
(extended jolira) in order to achieve my plan? If I go this route (like the
login/registration form), can I be optimistic that I can overcome all or
most of other stateless ajax quirks waiting for me in the future?

I work with Wicket 6.0-SNAPSHOT and Roberts' components nicely fit in my
environment.

Thank you,
Zlatko

--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/Stateless-and-Ajax-tp4344007p4348144.html
Sent from the Users forum mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe <at> wicket.apache.org
For additional commands, e-mail: users-help <at> wicket.apache.org

Re: Stateless and Ajax

On Wed, Feb 1, 2012 at 5:04 PM, zlatko99 <zlatko.suslevski <at> gmail.com> wrote:
> Thank you all involved in this thread. With your help, I managed to build a
> login/registration form, totally stateless and submitted with ajax. (Thanks,
> Robert, for the referenced component, it works really good).
>
> This was a proof of concept for me that such a page could be built in
> Wicket. I want to continue further with my project in a completely stateless
> manner. However, I see my project using many more complicated ajax
> components (ajax-autocomplete, etc.), also incorporating jqwicket library
> for integration with Jquery UI.
>
> Is it possible to continue with this arsenal of stateless ajax components
> (extended jolira) in order to achieve my plan? If I go this route (like the
> login/registration form), can I be optimistic that I can overcome all or
> most of other stateless ajax quirks waiting for me in the future?
>

I'm thinking of a problem which I'm not sure can be handled by stateless ajax.
A page has a panel and an ajax link that replaces this panel with a
another panel. So far so good.
The new panel also has an ajax link. Clicking on this link will lead
to ComponentNotFoundException I think, because it wont be in the
initial state of the re-created page.

Stateless Ajax users can you try this scenario ?

> I work with Wicket 6.0-SNAPSHOT and Roberts' components nicely fit in my
> environment.

Cool! More users testing the new Ajax impl in Wicket 6.0 !