Re: Apache Wicket releases Wicket 1.5
Congratulations and thanks a lot!
On Thu, Sep 8, 2011 at 9:08 AM, Hans Lesmeister
hans.lesmeis...@lessy-software.de wrote:
Congratulations! Thank you for this great Framework.
Martijn Dashorst dasho...@apache.org schrieb:
The Apache Wicket team is proud to announce the immediate availability of
the
newest release of their component oriented open source Java web framework.
Apache Wicket 1.5 has been in development for the last two years and brings
many improvements over previous versions.
Downloading Apache Wicket 1.5
-
You can download the release here:
http://www.apache.org/dyn/closer.cgi/wicket/1.5.0
Or use this in your Maven POM to upgrade to the new version:
dependency
groupIdorg.apache.wicket/groupId
artifactIdwicket-core/artifactId
version1.5.0/version
/dependency
Please note that Wicket’s main artifact ID has been renamed to wicket-core.
You will need to upgrade all modules (i.e. wicket, wicket-extensions,
wicket-ioc, wicket-spring, etc) to 1.5.0. It is not possible to mix
previous
versions of Wicket with modules of this release.
Most notable changes
With this release the Wicket team has revised many of its internals. A
short list:
- HTML5 components added: EmailTextField, NumberTextField, UrlTextField and
RangeTextField
- New inter-component events (explained below)
- Minimum required servlet API is servlet-api 2.5
- All standard validators now extend Behavior to allow for client side
validations
- IBehavior has been removed and AbstractBehavior has been deprecated, you
should now extend Behavior instead
- Simplified the request cycle processing and made it more extensible
- URL handling is now in one place
- Wicket’s rendering code has been greatly simplified
- Improved browser caching support
- ClientSideImageMap replaces old ImageMap
- Better support for running behind proxies with x-forwarded-for header
- Request cycle listeners make it easier to integrate frameworks in your
Wicket application
- Consistent naming: methods with Javascript in the name have been renamed
to
use proper capitalization: JavaScript
- Switching to HTTPS is as simple as configuring a new root mapper to make
Wicket HTTPS aware and annotating a page with @RequireHttps
A longer list of changes and improvements can be found in our migration
guide.
Inter-component events
--
Wicket 1.5 offers a simple, yet flexible, way for component to communicate
with each other in a decoupled manner. The two major interfaces that
facilitate this are:
/**
* Objects that can send events
*/
public interface IEventSource {
T void send(IEventSink sink, Broadcast broadcast, T payload);
}
and
/**
* Objects that can receive events
*/
public interface IEventSink
{
/**
* Called when an event is sent to this sink
*/
void onEvent(IEvent? event);
}
The classes that implement these interfaces, and can thus participate in
the
event mechanism are: Component, RequestCycle, Session, and Application.
The mechanism allows for different event broadcast methods defined here:
/**
* Defines the event broadcast type.
*/
public enum Broadcast {
BREADTH,
DEPTH,
BUBBLE,
EXACT;
}
There is an example in wicket-examples which demonstrates the usage of
this.
Applications can register custom event dispatchers in FrameworkSettings;
the
dispatchers can be used to build custom event delivery mechanisms. For
example
a custom IEventDispatcher mechanism can route events to annotated methods,
for
example:
public class MyComponent extends Component {
@OnEvent
private void onUserAdded(UserAddedEvent event) {...}
}
where UserAddedEvent is the event payload object.
The default Component#onEvent method will be called even if custom
dispatchers
are registered.
A default event is raised whenever Wicket begins to create an AJAX
response.
The payload of the event is the AjaxRequestTarget used for event. Sample
implementation:
// component that always adds itself to the ajax response
public class MyCompo
Include wicket into jsp page
Hello! We're slowly migrating a big legacy jsp application into wicket and I'm evaluating the ways incorporate wicket components into existing jsp pages. Right now I'm trying to figure out how to include a wicket component through jsp:include tag. As I've spent some time debugging I think that's what's going on: 1. When I use the jsp:include tag the RequestDispatcher.include(request, response, ...) is being called. 2. The RequestDispatcher tries to preserve original Request, so it puts the actual include's request URI into some attribute inside the request, while leaving the original requestURI and contextPath unmodified from the original request - I see that Catalina's servlets (e.g. DefaultServlet) specifically accounts for the case that the request might be from include and, later, grabs the URI from these attributes. 3. Once WicketFilter tries to determine whether the request is to be processed by Wicket it takes the requestURI and contextPath from the original Request and ignores the path I've used in jsp:include tag. As far as I understand I can try to modify the Request and replace the requestURI and the contextPath with the ones I need (from the tag), but before I go through this path I wanted to do a sanity check :) Is there, perhaps, a more convenient way to achieve the same result? Would there be some gotchas to look out for? Regards, Ilya
final in MarkupContainer#add(Component...) method
Hello! We're struggling with working around the final modifier for the MarkupContainer#add(Component ...) method. We have the following scenario: 1. We'd like to use a repeater to add some components to the form. 2. We'd like these components to work with CompoundPropertyModel, thus we need these to have meaningful wicket ids 3. We'd like not to find ourselves backstabbed by the non-numeric ids in the RepeatingView's children. This brings us to a suggested wrapping of the children in WebMarkupContainers, but we'd like to hide it to get rid of the webmarkupcontainer item=new webmarkupcontainer(rv.newchildid()); part. To do this, it seems logical to extend the RepeatingView overriding the add() method to be wrapping every component, however the add() method is final :( Could anyone suggest some other way to resolve this situation? Or, perhaps, it could be acceptable to officially remove the final modifier from the add() method? Thanks in advance! Ilya German.
Re: css not managed by wicket
Thanks for the replies! I'll try to experiment some more! - Original Message - From: Nicolas Melendez nmelen...@getsense.com.ar To: users@wicket.apache.org Sent: Monday, November 23, 2009 7:28 PM Subject: Re: css not managed by wicket hi, consider use this annotations: http://wicketstuff.org/confluence/display/STUFFWIKI/wicketstuff-merged-resources here a blog which explains the features it has: http://techblog.molindo.at/2009/10/wicket-annotation-based-mounting-of-resources.html#more-128 it will help i hope. bye On Mon, Nov 23, 2009 at 2:14 PM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: Just put /style.css Otherwise wicket is trying to guess the relative url. In most cases it guesses wrong so I have adopted the practice of using resource urls relative to the root of the domain. ** Martin 2009/11/23 Ilya German ilja.germ...@parex.lv: Hello! I'm trying to make my web application to use a .css stylesheet. As far as I understood reading http://cwiki.apache.org/WICKET/including-css-resources.html and Wicket in Action book I should be able to make any html page to work in the following configuration: say, Base.html includes: head link rel=stylesheet type=text/css href=style.css/ /head and to put the css file into web app directory (root of your war file). So the deployed project structure (say, in tomcat) would be like this: tomcat webapps/myapp --/META-INF --/WEB-INF /classes /pages -/Base.html -/Base.java -/Page1.html -/Page1.java - extends Base --/style.css However, when I access my Page1 page in browser (which extends Base page both in java and html and seems to be working), I see, that the URL to css is rewritten to ../style.css, which tries to reach style.css directly in tomcat webapps and doesn't find it there. Could anyone explain me what am I doing wrong? Thanks in advance, Ilya - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
css not managed by wicket
Hello! I'm trying to make my web application to use a .css stylesheet. As far as I understood reading http://cwiki.apache.org/WICKET/including-css-resources.html and Wicket in Action book I should be able to make any html page to work in the following configuration: say, Base.html includes: head link rel=stylesheet type=text/css href=style.css/ /head and to put the css file into web app directory (root of your war file). So the deployed project structure (say, in tomcat) would be like this: tomcat webapps/myapp --/META-INF --/WEB-INF /classes /pages -/Base.html -/Base.java -/Page1.html -/Page1.java - extends Base --/style.css However, when I access my Page1 page in browser (which extends Base page both in java and html and seems to be working), I see, that the URL to css is rewritten to ../style.css, which tries to reach style.css directly in tomcat webapps and doesn't find it there. Could anyone explain me what am I doing wrong? Thanks in advance, Ilya
