How to get at the 404 request URL?
Hi, I'm using a servlet error-page mapping to display my custom NotFound page for 404s (eg. as described here: http://herebebeasties.com/2006-12-20/using-a-servlet-filter-for-404-error-page/) filter-mapping filter-namewicket-filter/filter-name url-pattern/*/url-pattern dispatcherREQUEST/dispatcher dispatcherERROR/dispatcher /filter-mapping error-page error-code404/error-code location/404/location /error-page I have some anlayzing code on my NotFound page to check where the 404 occured, eg. by looking at the referrer and logging the request URI. This works when I use setResponsePage(NotFound.class) in other pages, but not for the error-page mapping, as HttpServletRequest#getRequestURI() returns just /404, which isn't helping at all. Any ideas on how to get at the original URI that triggered the 404? Jörn - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: How to get at the 404 request URL?
Thanks Jonas, exactly what I was looking for! Jörn On Fri, Feb 6, 2009 at 4:20 PM, Jonas barney...@gmail.com wrote: Hi, this isn't actually related to wicket, but anyway, I think what you're looking for is the servlet request attribute javax.servlet.error.request_uri See: http://www.servlets.com/soapbox/servlet23.html specially the section 'New error attributes' regards, Jonas On Fri, Feb 6, 2009 at 3:28 PM, Jörn Zaefferer joern.zaeffe...@googlemail.com wrote: Hi, I'm using a servlet error-page mapping to display my custom NotFound page for 404s (eg. as described here: http://herebebeasties.com/2006-12-20/using-a-servlet-filter-for-404-error-page/) filter-mapping filter-namewicket-filter/filter-name url-pattern/*/url-pattern dispatcherREQUEST/dispatcher dispatcherERROR/dispatcher /filter-mapping error-page error-code404/error-code location/404/location /error-page I have some anlayzing code on my NotFound page to check where the 404 occured, eg. by looking at the referrer and logging the request URI. This works when I use setResponsePage(NotFound.class) in other pages, but not for the error-page mapping, as HttpServletRequest#getRequestURI() returns just /404, which isn't helping at all. Any ideas on how to get at the original URI that triggered the 404? Jörn - 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Mounting parameters on homepage
Hi, I have a simple search form on my homepage and would like to mount the search parameter, eg. to have host/?term=foo instead of host/?x=faniwfani35gfsge353 (when using CryptedUrlWebRequestCodingStrategy). I can't figure out a way to configure the strategy used to mount the homepage. This throws an IllegalArgumentException(The mount path '/' is reserved for the application home page): mount(new QueryStringUrlCodingStrategy(/, Homepage.class)); Overriding WebRequestCodingStrategy#mount(IRequestTargetUrlCodingStrategy) isn't an option, as that method is final. Is there any way to achieve this? Thanks Jörn
Re: Mounting parameters on homepage
Thanks for your answers, though thats not what I asked for. I know that the homepage is already mounted, thats why I'm asking how I can change the strategy for its parameters. Creating a seperate page for the search result is a workaround, not a solution. Any other ideas? Thanks Jörn On Tue, Aug 26, 2008 at 7:57 PM, Ritesh Trivedi [EMAIL PROTECTED] wrote: I dont think you need to explicitly mount a home page to /. Your application has the home page reference and application mounts that page to /. What you probably need is create a SearchPage.java, have it mounted as mixed param coding strategy and let SearchPage provide PageParameter constructor taking the search term as parameter. You can mount SearchPage with whatever string you want, form submission on the home page should setResponsePage(SearchPage.class, new PageParameter(searchterm_etc)) will do it. Jörn Zaefferer-2 wrote: Hi, I have a simple search form on my homepage and would like to mount the search parameter, eg. to have host/?term=foo instead of host/?x=faniwfani35gfsge353 (when using CryptedUrlWebRequestCodingStrategy). I can't figure out a way to configure the strategy used to mount the homepage. This throws an IllegalArgumentException(The mount path '/' is reserved for the application home page): mount(new QueryStringUrlCodingStrategy(/, Homepage.class)); Overriding WebRequestCodingStrategy#mount(IRequestTargetUrlCodingStrategy) isn't an option, as that method is final. Is there any way to achieve this? Thanks Jörn -- View this message in context: http://www.nabble.com/Mounting-parameters-on-homepage-tp19163461p19167106.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket resources (css, js and images)?
Hi Matej, let me know if you reconsider jQuery and have any specific question. The jQuery team is there to help! Jörn On Tue, Aug 26, 2008 at 7:57 PM, Matej Knopp [EMAIL PROTECTED] wrote: Hi, I haven't announced yet publicly but for some time I was working on Ajax implementation for 1.5. The work is available in /repos/asf/wicket/sandbox/knopp/experimental/wicket I will put together a wiki page when I have some free time. I have of course considered jquery. I gave it a proper look but I decided to go with YUI instead because I like it's approach more. Also some functionality that YUI provides in core (dom manipulations) is only available as plugin to Jquery. New Wicket Ajax the is based on YUI3 which provides new node module that allows method chaining and kinda feels like jquery. Also personally I consider YUI source code much more readable than jquery -Matej On Tue, Aug 26, 2008 at 6:10 PM, Scott Swank [EMAIL PROTECTED] wrote: Has jquery been considered for WANG, or am I coming into this conversation late? Scott On Tue, Aug 26, 2008 at 5:51 AM, Martijn Dashorst [EMAIL PROTECTED] wrote: Probably something for 1.5 (with WANG–Wicket Ajax Next Generation–being based on YUI) Martijn On Tue, Aug 26, 2008 at 2:25 PM, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED] wrote: I've been hearing some rants on how merging resources can up the performance, should wicket be able todo this? I mean merging several css's into one etc.. I know it wont work for dynamic css/js/images. But on static it could, even yslow recommends you merge your resources into one... Images might be stretching it too far? WDYT? http://workingwithrails.com/railsplugin/5317-asset-packager http://www.kaboomerang.com/blog/2007/11/29/getting-to-10-actiontastic-actionatr-gwt-and-automagic-rest/ -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.3.4 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. - 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: WANG–Wicket Ajax Next Generation–being based on YUI (MD)
On Tue, Aug 26, 2008 at 10:19 PM, Matej Knopp [EMAIL PROTECTED] wrote: Hi, On Tue, Aug 26, 2008 at 9:24 PM, jWeekend [EMAIL PROTECTED] wrote: Matej, What are the implications of the decision to base Wicket Ajax Next Generation on YUI in terms of choosing a Javascript library for future Wicket based web front ends? actually, there really are none. The use of YUI will be more or less internal to Wicket, so you can continue using jQuery, YUI2 or whatever else you are using. Everything in Wicket (and YUI) is namespaced so there are no conflicts. Of course there is the overhead of including two or more libraries in an application, which don't find desirable. + there's huge number and variety of jQuery plugins for those special occasions. Unfortunately the quality of plugins varies. For actual wicket ajax implementation i prefer to stick with the core thing, and that's where YUI definitely beats jquery. I don't say that there are no plugins for jQuery that covers YUI functionality. Question is how well are those plugins supported and maintained. You are well on the point that the variety of plugins varies. I see it this way: jQuery core is small, very stable and the base for everything else JS-related. jQuery UI is the official project providing the same stability and quality for various high-level UI components (like dialogs) and also low-level components (like dragdrop, sortables). We'll see at least two major releases this year that add more components to the mix. Anything else that isn't covered by core or UI is almost always covered by some third-party plugin. While these plugin can be of bady quality (eg. no documentation/demos), they can still provide a good starting point, so that you don't have to start from scratch. Even if you do a full rewrite, the existing plugin can expose useful information like potential browser-bug-traps. Anyway, as I say, this doesn't make any implication to Wicket users or 3rd party components. The reason why wicket ajax is based on another framework is to get rid of most of the low level browser specific code we have currently so that I wouldn't have to maintain it :) Whatever the framework, I think its a good idea to start with something well supported and tested. Thats why I use Wicket, though I'd like it even more with jQuery as the base framework :-) Jörn PS: Comet support is a nice to have, but I think there a way more important things for core than that, eg. annotation-based validation
Re: [announce] Openlayers contrib upgraded to 1.4-SNAPSHOT
Ah, thanks Nino! Jörn On Wed, Aug 27, 2008 at 12:45 AM, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED] wrote: I am refering to http://wicketstuff.org/confluence/display/STUFFWIKI/wicket-contrib-openlayers Openlayer components for wicket:) Previously only supported wicket 1.3, although a pretty trivial upgrade I thought it nice to announce it. If you combine the openlayer contrib, wicket and geoserver you have a kick ass opportunity to make geo apps very very easy. And btw the problem I had with my smoketest were just loong response times from labs.meta data so no problems at all. Jörn Zaefferer wrote: I guess I missed previous discussions or announcements - but based on your mail and the URL you provide I have no idea what you are talking about, eg. how openlayers is related to Wicket and the 1.4-SNAPSHOT. Could you give some more details for those uninvolved in the development? Thanks Jörn On Tue, Aug 26, 2008 at 8:46 PM, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED] wrote: So there it are for your pleasure.. I've smoke tested it manually, and it seems to be working. However it seems there are a problem with the map provider, it's there on http://openlayers.org/ too. But i've previously experienced it to be unstable. Feel free to come with propositions on howto apply generics where I haven't (remember it were a 1.5 project from the begining). Or any other ideas are welcome. -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Discussion on Wicket Interface Speed-Up
Again, great work Stefan!
The basics already work fine, allowing me to keep a maintenance
friendly style of development while heavily optimizing frontend
performance.
The biggest isse now is the public API: I have to duplicate a lot of
information in the application and the page/component classes.
Eventually something like this could remove the duplication while
making it very easy to add new components and resources:
@HeaderContribution(
scripts={jquery.js, Example.js},
stylesheets={theme.js, Example.css}
)
public class Example {
public Example() {
HeaderContribution.addResources(this);
}
}
With something similar to wicketstuff-annotation in the Application#init method:
new AnnotatedResourcesMountScanner().scanPackage(my.package).mount(this);
A small issue, but still important: Please consider setting JDK 5 as
the goal for the project. JDK 6 is still unavailable on most OSX
installations and the one or two new methods aren't worth the trouble.
If you don't have plans to support JDK 1.4, it would be nice to
replace the various array-arguments with (generic)
varargs/collections.
Jörn
On Thu, Aug 28, 2008 at 11:59 AM, Stefan Fußenegger
[EMAIL PROTECTED] wrote:
I just finished the 4th and last entry of my series Wicket Interface
Speed-Up on my blog. To give a short summary: I investigated one of my apps
with YSlow and started optimizing it's interface rendering speed [1].
Especially Wicket's way of handling resources, i.e. JS and CSS files, causes
interfaces to load rather slowly. In my articles, I explain how to modify
the cache interval [2], how to mount resources with a version (e.g.
/css/all-1234.css) in order to use aggressive client-side caching (e.g.
resources expire after a year) [3]. Finally, I show how to merge resources
at application startup (using a class classed MergedResourceStream) to
reduce the number of resources a client has to download [4], including
code). I was able to increase interface loading times considerably, so it's
surely worth a look.
I feel that it would also be worth to discuss, whether this work could be
part of upcoming Wicket versions. For the time being I'd like to make the
code attached to [4] a wicketstuff project - sfussenegger needs commit
access ;) - and wait for your feedback.
The links:
[1] http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html
Wicket Interface Speed-Up
[2]
http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html
Wicket Interface Speed-Up: Modifying Expires and Cache-Control Headers
[3]
http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html
Wicket Interface Speed-Up: Caching Resources Forever
[4]
http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html
Wicket Interface Speed-Up: Merging Resources for Fewer HTTP Requests
-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
--
View this message in context:
http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19197540.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Discussion on Wicket Interface Speed-Up
Here is a first patch for the RevisionVersionProvider:
Index:
src/main/java/org/wicketstuff/mergedresources/versioning/RevisionVersionProvider.java
===
---
src/main/java/org/wicketstuff/mergedresources/versioning/RevisionVersionProvider.java
(revision
4147)
+++
src/main/java/org/wicketstuff/mergedresources/versioning/RevisionVersionProvider.java
(working
copy)
@@ -15,7 +15,7 @@
public int getVersion(final Class? scope, final String fileName)
throws VersionException {
final String file = getResourcePath(scope, fileName);
- final InputStream in =
ClassLoader.getSystemResourceAsStream(file);
+ final InputStream in =
RevisionVersionProvider.class.getClassLoader().getResourceAsStream(file);
if (in == null) {
throw new VersionException(scope, fileName, can't find
+ file);
}
ClassLoader.getSystemResourceAsStream in my deployment enviroment, it
always returned null for classpath resources. Using the
RevisionVersionProvider classloader works fine.
Let me know where I should post further patches etc.
Jörn
On Fri, Aug 29, 2008 at 11:29 AM, Stefan Fußenegger
[EMAIL PROTECTED] wrote:
Code is now available through wicketsuff:
https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-merged-resources/
wicketstuff-merged-resources and
https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-merged-resources-examples/
wicketstuff-merged-resources-examples
Now I want to make it available through
http://wicketstuff.org/maven/repository/. I therefore registered at
wicketstuff.org/teamcity (sfussenegger). What's next?
Stefan Fußenegger wrote:
I just finished the 4th and last entry of my series Wicket Interface
Speed-Up on my blog. To give a short summary: I investigated one of my
apps with YSlow and started optimizing it's interface rendering speed [1].
Especially Wicket's way of handling resources, i.e. JS and CSS files,
causes interfaces to load rather slowly. In my articles, I explain how to
modify the cache interval [2], how to mount resources with a version (e.g.
/css/all-1234.css) in order to use aggressive client-side caching (e.g.
resources expire after a year) [3]. Finally, I show how to merge resources
at application startup (using a class classed MergedResourceStream) to
reduce the number of resources a client has to download [4], including
code). I was able to increase interface loading times considerably, so
it's surely worth a look.
I feel that it would also be worth to discuss, whether this work could be
part of upcoming Wicket versions. For the time being I'd like to make the
code attached to [4] a wicketstuff project - sfussenegger needs commit
access ;) - and wait for your feedback.
The links:
[1]
http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html
Wicket Interface Speed-Up
[2]
http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html
Wicket Interface Speed-Up: Modifying Expires and Cache-Control Headers
[3]
http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html
Wicket Interface Speed-Up: Caching Resources Forever
[4]
http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html
Wicket Interface Speed-Up: Merging Resources for Fewer HTTP Requests
-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
--
View this message in context:
http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19216657.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Discussion on Wicket Interface Speed-Up
Good point, I forgot that wicketstuff has its own JIRA installation.
Though the entry for the project is missing. Let me know once its
there, and I'll create the report.
Jörn
On Fri, Aug 29, 2008 at 12:26 PM, Peter Ertl [EMAIL PROTECTED] wrote:
why don't you open up an issue in JIRA?
Am 29.08.2008 um 12:22 schrieb Jörn Zaefferer:
Here is a first patch for the RevisionVersionProvider:
Index:
src/main/java/org/wicketstuff/mergedresources/versioning/RevisionVersionProvider.java
===
---
src/main/java/org/wicketstuff/mergedresources/versioning/RevisionVersionProvider.java
(revision
4147)
+++
src/main/java/org/wicketstuff/mergedresources/versioning/RevisionVersionProvider.java
(working
copy)
@@ -15,7 +15,7 @@
public int getVersion(final Class? scope, final String fileName)
throws VersionException {
final String file = getResourcePath(scope, fileName);
- final InputStream in =
ClassLoader.getSystemResourceAsStream(file);
+ final InputStream in =
RevisionVersionProvider.class.getClassLoader().getResourceAsStream(file);
if (in == null) {
throw new VersionException(scope, fileName, can't
find + file);
}
ClassLoader.getSystemResourceAsStream in my deployment enviroment, it
always returned null for classpath resources. Using the
RevisionVersionProvider classloader works fine.
Let me know where I should post further patches etc.
Jörn
On Fri, Aug 29, 2008 at 11:29 AM, Stefan Fußenegger
[EMAIL PROTECTED] wrote:
Code is now available through wicketsuff:
https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-merged-resources/
wicketstuff-merged-resources and
https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-merged-resources-examples/
wicketstuff-merged-resources-examples
Now I want to make it available through
http://wicketstuff.org/maven/repository/. I therefore registered at
wicketstuff.org/teamcity (sfussenegger). What's next?
Stefan Fußenegger wrote:
I just finished the 4th and last entry of my series Wicket Interface
Speed-Up on my blog. To give a short summary: I investigated one of my
apps with YSlow and started optimizing it's interface rendering speed
[1].
Especially Wicket's way of handling resources, i.e. JS and CSS files,
causes interfaces to load rather slowly. In my articles, I explain how
to
modify the cache interval [2], how to mount resources with a version
(e.g.
/css/all-1234.css) in order to use aggressive client-side caching (e.g.
resources expire after a year) [3]. Finally, I show how to merge
resources
at application startup (using a class classed MergedResourceStream) to
reduce the number of resources a client has to download [4], including
code). I was able to increase interface loading times considerably, so
it's surely worth a look.
I feel that it would also be worth to discuss, whether this work could
be
part of upcoming Wicket versions. For the time being I'd like to make
the
code attached to [4] a wicketstuff project - sfussenegger needs commit
access ;) - and wait for your feedback.
The links:
[1]
http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html
Wicket Interface Speed-Up
[2]
http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html
Wicket Interface Speed-Up: Modifying Expires and Cache-Control Headers
[3]
http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html
Wicket Interface Speed-Up: Caching Resources Forever
[4]
http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html
Wicket Interface Speed-Up: Merging Resources for Fewer HTTP Requests
-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
--
View this message in context:
http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19216657.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
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: Discussion on Wicket Interface Speed-Up
Thanks Stefan! Just removed my local checkout and it works fine.
Jörn
On Tue, Sep 2, 2008 at 8:46 AM, Stefan Fußenegger
[EMAIL PROTECTED] wrote:
wicketstuff-merged-resources is now available in JIRA:
http://wicketstuff.org/jira/browse/WMR
and from wicketstuff maven repo:
repositories
repository
idwicket-snaps/id
urlhttp://wicketstuff.org/maven/repository/url
snapshots
enabledtrue/enabled
/snapshots
releases
enabledtrue/enabled
/releases
/repository
/repositories
dependency
groupIdorg.wicketstuff/groupId
artifactIdwicketstuff-merged-resources/artifactId
version1.3.4-SNAPSHOT/version
/dependency
i am also going to add a short wiki page at wicketstuff.org
regards, Stefan
Jörn Zaefferer-2 wrote:
Good point, I forgot that wicketstuff has its own JIRA installation.
Though the entry for the project is missing. Let me know once its
there, and I'll create the report.
Jörn
On Fri, Aug 29, 2008 at 12:26 PM, Peter Ertl [EMAIL PROTECTED] wrote:
why don't you open up an issue in JIRA?
Am 29.08.2008 um 12:22 schrieb Jörn Zaefferer:
Here is a first patch for the RevisionVersionProvider:
Index:
src/main/java/org/wicketstuff/mergedresources/versioning/RevisionVersionProvider.java
===
---
src/main/java/org/wicketstuff/mergedresources/versioning/RevisionVersionProvider.java
(revision
4147)
+++
src/main/java/org/wicketstuff/mergedresources/versioning/RevisionVersionProvider.java
(working
copy)
@@ -15,7 +15,7 @@
public int getVersion(final Class? scope, final String
fileName)
throws VersionException {
final String file = getResourcePath(scope, fileName);
- final InputStream in =
ClassLoader.getSystemResourceAsStream(file);
+ final InputStream in =
RevisionVersionProvider.class.getClassLoader().getResourceAsStream(file);
if (in == null) {
throw new VersionException(scope, fileName,
can't
find + file);
}
ClassLoader.getSystemResourceAsStream in my deployment enviroment, it
always returned null for classpath resources. Using the
RevisionVersionProvider classloader works fine.
Let me know where I should post further patches etc.
Jörn
On Fri, Aug 29, 2008 at 11:29 AM, Stefan Fußenegger
[EMAIL PROTECTED] wrote:
Code is now available through wicketsuff:
https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-merged-resources/
wicketstuff-merged-resources and
https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-merged-resources-examples/
wicketstuff-merged-resources-examples
Now I want to make it available through
http://wicketstuff.org/maven/repository/. I therefore registered at
wicketstuff.org/teamcity (sfussenegger). What's next?
Stefan Fußenegger wrote:
I just finished the 4th and last entry of my series Wicket Interface
Speed-Up on my blog. To give a short summary: I investigated one of
my
apps with YSlow and started optimizing it's interface rendering speed
[1].
Especially Wicket's way of handling resources, i.e. JS and CSS files,
causes interfaces to load rather slowly. In my articles, I explain how
to
modify the cache interval [2], how to mount resources with a version
(e.g.
/css/all-1234.css) in order to use aggressive client-side caching
(e.g.
resources expire after a year) [3]. Finally, I show how to merge
resources
at application startup (using a class classed MergedResourceStream) to
reduce the number of resources a client has to download [4], including
code). I was able to increase interface loading times considerably, so
it's surely worth a look.
I feel that it would also be worth to discuss, whether this work could
be
part of upcoming Wicket versions. For the time being I'd like to make
the
code attached to [4] a wicketstuff project - sfussenegger needs commit
access ;) - and wait for your feedback.
The links:
[1]
http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html
Wicket Interface Speed-Up
[2]
http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html
Wicket Interface Speed-Up: Modifying Expires and Cache-Control Headers
[3]
http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html
Wicket Interface Speed-Up: Caching Resources Forever
[4]
http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html
Wicket Interface Speed-Up: Merging Resources for Fewer HTTP Requests
-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
--
View this message in context:
http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19216657.html
Sent from the Wicket
Re: Discussion on Wicket Interface Speed-Up
Ignoring the iPhone - not everyone has that as a target platform - the
bruteforce method of packaging everything into one file isn't that
bad. The initial bandwidth hit is outweighed be reducing requests to
one (or two, one js, one css file). That means the first page loads a
bit longer, which is normal in most cases anyway, while all other
pages loaded afterwards need no additional css/js at all, therefore
being potentially lightning fast.
Putting all page specific scripts into one file isn't trivial. I've
found that its very easy to handle by starting each script to check if
a certain dom element, selected via ID, exists. In my case, using
jQuery, something like this:
Subpage.js
jQuery(function($) {
if ($(#somePageSpecificId).length) {
// Subpage is active, do something
}
});
ID selectors should have no performance impact at all, as long as
there aren't thousands of them, which is very unlikely in this
scenario.
The same applies to CSS, where page specific styles are namespaces
with parent ids - same concept, easier to write.
If you *are* targeting the iPhone, you proably shouldn't load a full
library and tinymce and what not anyway...
Jörn
On Wed, Sep 3, 2008 at 4:21 PM, Matej Knopp [EMAIL PROTECTED] wrote:
There is yet another thing to consider. Iphone doesn't cache resources
bigger than 25kb (after unzipping). So instead of grouping files
together sometimes it even might be appropriate to split them...
-Matej
On Wed, Sep 3, 2008 at 4:11 PM, [EMAIL PROTECTED] wrote:
It's not the pages that have these files. Let's say I have a page that
uses jquery and a textfield with a button that toggles tinymce.
If we do what you say then there are two possible files: jquery and
jquery+tinymce.
Than let's say I add Ajax to the page, now there are 6 possibilities
depending on which components are currently on the page.
IMHO much cheaper to just cache jquery, tinymce, wicket-Ajax individually.
-Igor
On 9/3/08, richardwilko [EMAIL PROTECTED] wrote:
im not sure we could help in the cases where you have dynamic header
contributors, like you say you would either have to specify them up front
(ie add them into the page not the panel, breaking encapsulation) or just
serve via the normal header contributor.
But i dont see how this would result in many many large files. you would
have a single file for the static stuff, and then each dynamic one would
have its own file (assuming not specified up front). This would still bring
down the total number.
eg a page has 6 static js and 2 dynamic js which would get turned into 1
static js and the same 2 dynamic js.
cases where a component and resulting header contributers are added via ajax
wouldnt be important for the initial page load speed anyway, as they are
added after the page has loaded.
Richard
igor.vaynberg wrote:
problem with this is that pages can have dynamic components which
dynamic header contributions.
so either you have to somehow collect all possible header
contributions from all possible component combinations - breaking
encapsulation in the process, or you have to do what you do - ending
up with many many possible and big javascript files to serve to the
user.
-igor
On Tue, Sep 2, 2008 at 2:57 PM, richardwilko
[EMAIL PROTECTED] wrote:
The problem of breaking encapsulation:
I did some work on this problem on my own a few months ago, my solution
was
to use a header contrib manager, and instead of adding files with a
header
contributer i add them to the manager, then get a single contributer per
page from the manger.
for example in a panel you would do
@Override
protected void onBeforeRender() {
super.onBeforeRender();
ResourceReference rr = new ResourceReference(getClass(),
test.js);
WicketApplication.get().getHcm().add(rr,
getPage().getClass());
}
See how it uses getPage().getClass(), so the manager knows which class
the
panel is being added into
then in the main page class
@Override
protected void onBeforeRender() {
super.onBeforeRender();
add(WicketApplication.get().getHcm().getHeaderContributor(getClass()));
}
since the manager knows all of the resources added for the page at this
point, it is easy to compress them all together and serve a single file,
and
you dont have to list the files up front.
What do you think of this idea?
My code is here:
http://www.nabble.com/file/p19279269/HeaderContribManagerTest.zip
HeaderContribManagerTest.zip
It still has bugs etc in it, and doesnt really work cos ive messed up the
registerResource method, but you should be able to get the idea from it
Richard
-
http://www.richard-wilkinson.co.uk My blog:
http://www.richard-wilkinson.co.uk
--
View this message in context:
http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19279269.html
Sent from the Wicket - User mailing list archive at
Re: Bypass validation conditionally
Using JavaScript to store tabs means that all tabs are rendered at once, so there is no need to store anything between switching tabs. Jörn On Mon, Sep 8, 2008 at 10:00 AM, thebeard [EMAIL PROTECTED] wrote: Thanks for your response Igor. It makes sense that the validation for field type is done ie: if a String is entered but an int is expected. Is there a simple way to conditionally bypass custom validation only eg: String length less than 64 characters? Also if we use javascript to switch tabs, how we can store the values that have been inputted. Thanks -The Beard igor.vaynberg wrote: you cannot bind non-validated input to your model objects. what happens if your model object is of type integer but the user entered a, how do you store that? the easiest way to accomplish what you want is to simply use javascript tabs so switching tabs does not result in another request. -igor On Mon, Sep 8, 2008 at 12:02 AM, thebeard [EMAIL PROTECTED] wrote: We have a number of tabs that is contained within a single form. Each of the tabs has some fields on them, but when we navigate from tab to tab, we would like to bypass validation BUT still have it bind to our property model object. Additionally we have 1 button on the form, which when submitted, should do validation across all the tabs. We have tried changing the links to submit links in order to get it to bind to our property model and then setDefaultFormProcessing(false) in order to bypass the validation per tab, but this hasn't worked for us. Any ideas would be appreciated, Beardie -- View this message in context: http://www.nabble.com/Bypass-validation-conditionally-tp19366878p19366878.html Sent from the Wicket - User mailing list archive at Nabble.com. - 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] -- View this message in context: http://www.nabble.com/Bypass-validation-conditionally-tp19366878p19367605.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Release date for 1.3.5?
Hi, is there a release date planned for 1.3.5? There are important updates in trunk, like protection against CSRF (https://issues.apache.org/jira/browse/WICKET-1782). If there isn't a date yet, what needs to be done to get one? Regards Jörn
Wicket in Action
My copy of Wicket in Action just arrived - kudos to Martjin and Eelco! Great work! Jörn
Re: Best first approach to Wicket for my case
Persistence with Hibernate annotations and Spring declarative transactions (@Transactional) provide a great programming model. Wicket on top of that, with Spring components injected via @SpringBean works well, too, though so far Wicket doesn't really leverage Java 5. One notable exceptions is the wicketstuff-annotations project, which allows you to configure mounts with annotations. You should look for existing components for image uploading and map display, that will help getting started. Building your own forum software doesn't sound like a good idea, all in all there is just way too much stuff you'd have to reinvent. Not sure if there is anything available for wicket for building a forum. Jörn On Tue, Sep 9, 2008 at 10:01 PM, Vernon [EMAIL PROTECTED] wrote: I plan to use Wicket first time for my next project. I will use Wicket + Spring + Hibernate to build a web application. I am familiar with Spring (mostly the pre-2.5 version) and Hibernate. And I also worked with Swing before moved into the Java server side development. I would like to hear any suggestions of most effective approaches. I don't have a lot of time for this project, but would like to get it up ASAP. The first phase of the project will allow users post entries which involves image uploading and map display. Online forum is another feature in my plan. While I am starting research/study on related materials, I would like to hear suggestions/advices from others with related successful or unsuccessful experience. Thanks very much in advance. .v
Re: https flips to http
Setting the following security-constraint in your web.xml should fix that: security-constraint web-resource-collection web-resource-namesecure/web-resource-name url-pattern//url-pattern /web-resource-collection user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint It basically enforces ALL requests to SSL connections. Jörn On Wed, Sep 10, 2008 at 6:14 PM, insom [EMAIL PROTECTED] wrote: Here's what I see from using Tamper Data. It appears that there's a 302 redirect causing the switch. Is that something Wicket does? http://www.nabble.com/file/p19414977/tamperData.gif Jeremy Thomerson-5 wrote: Wicket uses relative URLs, so at first guess, I'd think it was something else. Start with something like -- View this message in context: http://www.nabble.com/https-flips-to-http-tp19403303p19414977.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket not secure?
Though afaik the URL encryption will be even better with 1.3.5, where the encryption key is session-based, that is, per user, instead of one default key for everything (current 1.3.4 behaviour). Once that is released, you get unique-per-user URLs which provide perfect protection against CSRF without ever getting into the way of the application developer. Haven't seen that anywhere else! Jörn On Thu, Sep 18, 2008 at 7:15 PM, Jonathan Locke [EMAIL PROTECTED] wrote: to be totally explicit, the third sentence should probably say explicit steps must be taken *by the programmer* ;-) the last sentence is outdated as wicket provides URL encryption if you want it Johan Compagner wrote: Why is that sentence ambiguous? On 9/18/08, cj91 [EMAIL PROTECTED] wrote: My company is planning an extremely large web project and Wicket is a candidate for use. My manager pointed out some unsettling words on the Wicket FAQ, which are ambiguous unfortunately. http://wicket.apache.org/features.html Wicket is secure by default. URLs do not expose sensitive information and all component paths are session-relative. Explicit steps must be taken to share information between sessions. There are plans for the next version of Wicket to add URL encryption to support highly secure web sites. Can someone please elaborate on what is meant by Explicit steps must be taken to share information between sessions. Thank you, -Jonathan -- View this message in context: http://www.nabble.com/Wicket-not-secure--tp19556259p19556259.html Sent from the Wicket - User mailing list archive at Nabble.com. - 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] -- View this message in context: http://www.nabble.com/Wicket-not-secure--tp19556259p19557667.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicketstuff wishlist?
Don't we have already at least one wishlist on the wicket wiki? http://cwiki.apache.org/WICKET/#Index-WishListforNextVersion Jörn On Fri, Sep 19, 2008 at 12:30 PM, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED] wrote: Hi I'd really like a wish list for wicketstuff. So reply with your wishes and I might have time at a point to implement it:) I'll start by adding this to the list: Integration with : http://code.google.com/p/iui/ I'll add a wishlist to the wiki or maybe my blog.. -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicketstuff wishlist?
Oops, I missed that bit! Well, then I add: Annotations for form validation. Maybe integrated with the bean validation JSR, Hibernate Validation or standalone. Enabled by adding AnnotationValidator instance to a form or indivdual fields... Jörn On Fri, Sep 19, 2008 at 2:05 PM, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED] wrote: wicketstuff!=wicket :) And it should not go on the wicket wiki... Jörn Zaefferer wrote: Don't we have already at least one wishlist on the wicket wiki? http://cwiki.apache.org/WICKET/#Index-WishListforNextVersion Jörn On Fri, Sep 19, 2008 at 12:30 PM, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED] wrote: Hi I'd really like a wish list for wicketstuff. So reply with your wishes and I might have time at a point to implement it:) I'll start by adding this to the list: Integration with : http://code.google.com/p/iui/ I'll add a wishlist to the wiki or maybe my blog.. -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket not secure?
Sure, but why bother when its already implemented? Security-related stuff isn't exactly the right place to roll your own. Jörn On Fri, Sep 19, 2008 at 4:34 PM, Igor Vaynberg [EMAIL PROTECTED] wrote: that is trivial to implement with 1.3.4 also -igor On Fri, Sep 19, 2008 at 12:51 AM, Jörn Zaefferer [EMAIL PROTECTED] wrote: Though afaik the URL encryption will be even better with 1.3.5, where the encryption key is session-based, that is, per user, instead of one default key for everything (current 1.3.4 behaviour). Once that is released, you get unique-per-user URLs which provide perfect protection against CSRF without ever getting into the way of the application developer. Haven't seen that anywhere else! Jörn On Thu, Sep 18, 2008 at 7:15 PM, Jonathan Locke [EMAIL PROTECTED] wrote: to be totally explicit, the third sentence should probably say explicit steps must be taken *by the programmer* ;-) the last sentence is outdated as wicket provides URL encryption if you want it Johan Compagner wrote: Why is that sentence ambiguous? On 9/18/08, cj91 [EMAIL PROTECTED] wrote: My company is planning an extremely large web project and Wicket is a candidate for use. My manager pointed out some unsettling words on the Wicket FAQ, which are ambiguous unfortunately. http://wicket.apache.org/features.html Wicket is secure by default. URLs do not expose sensitive information and all component paths are session-relative. Explicit steps must be taken to share information between sessions. There are plans for the next version of Wicket to add URL encryption to support highly secure web sites. Can someone please elaborate on what is meant by Explicit steps must be taken to share information between sessions. Thank you, -Jonathan -- View this message in context: http://www.nabble.com/Wicket-not-secure--tp19556259p19556259.html Sent from the Wicket - User mailing list archive at Nabble.com. - 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] -- View this message in context: http://www.nabble.com/Wicket-not-secure--tp19556259p19557667.html Sent from the Wicket - User mailing list archive at Nabble.com. - 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: Wicketstuff wishlist?
A pony? Django now got one... Thanks for the wicket-hibernate link! Jörn On Sat, Sep 20, 2008 at 2:29 AM, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED] wrote: Baah.. Theres already something on it: https://wicket-stuff.svn.sf.net/svnroot/wicket-stuff/trunk/wicketstuff-hibernate-behavior/ something on it here: http://jroller.com/wireframe/entry/hibernate_annotations_and_wicket Anything else for the wish list not already existing? :) Nino Saturnino Martinez Vazquez Wael wrote: Great:) First shot will probably be Hibernate Validation (is general and works without hibernate with any JPA provider), since I have a demo project for that, validation JSR 303 arent done yet AFAIK.. And I think im gonna try to use IVisitor to do it.. So it's actually a fairly simple one:) Jörn Zaefferer wrote: Oops, I missed that bit! Well, then I add: Annotations for form validation. Maybe integrated with the bean validation JSR, Hibernate Validation or standalone. Enabled by adding AnnotationValidator instance to a form or indivdual fields... Jörn On Fri, Sep 19, 2008 at 2:05 PM, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED] wrote: wicketstuff!=wicket :) And it should not go on the wicket wiki... Jörn Zaefferer wrote: Don't we have already at least one wishlist on the wicket wiki? http://cwiki.apache.org/WICKET/#Index-WishListforNextVersion Jörn On Fri, Sep 19, 2008 at 12:30 PM, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED] wrote: Hi I'd really like a wish list for wicketstuff. So reply with your wishes and I might have time at a point to implement it:) I'll start by adding this to the list: Integration with : http://code.google.com/p/iui/ I'll add a wishlist to the wiki or maybe my blog.. -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: Wicket and Mootools?
jQuery UI (ui.jquery.com) adds quite a few effects: http://ui.jquery.com/repository/real-world/effects/ Jörn On Fri, Sep 19, 2008 at 5:27 PM, mahone9 [EMAIL PROTECTED] wrote: I think I´m gonna use scriptaculous. It´s much more easier to use it and I guess you can also compress the js files as mootools does. Scriptaculous provides almost that much effects as mootools. JQuery is very poor on effects... Nino.Martinez wrote: Agent Mahone wrote: O, thank u very much for ur comments. I have some questions to you: 1. What is the package mini under contribution package for? What is the difference to package contribution/wicket-mootools??? Im not sure how well managed wicket-mootools are... 2. I also noticed that wicket offers you scriptaculous and jquery. Is there any comparsion between that frameworks? Go google:) I´ve seen that scriptaculous is much more easier to understand and difinitely to use. Thanks again for any comments - Ursprüngliche Mail Von: Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED] An: users@wicket.apache.org Gesendet: Donnerstag, den 18. September 2008, 09:50:32 Uhr Betreff: Re: Wicket and Mootools? You can also check out the new addition to wicket stuff minis, the mootips integration.. Agent Mahone wrote: Hi all What is the best way to integrate mootools in wicket ? Does Mootools slow down the application? Does somebody had good expierence with it? Thanks in advane for any comments __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/AW%3A-Wicket-and-Mootools--tp19550432p19574467.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicketstuff wishlist?
How about a IFormValidator? That has access to the form's components and is more flexible to use (composition instead of inheritance). Jörn On Sat, Sep 20, 2008 at 4:56 PM, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: I'm the one who developed HibernateFormComponentValidator and HibernateFormValidator, which does the validation in a different way compared with the annotations package. We really should improve this project. :-) Hows it lacking.. A less intrusive way..? Maybe instead just provide an HibernateValidatedForm, just use the form and it will and the correct validators using vistor etc? cheers Bruno On Sep 20, 2008 6:47am, Jörn Zaefferer [EMAIL PROTECTED] wrote: A pony? Django now got one... Thanks for the wicket-hibernate link! Jörn On Sat, Sep 20, 2008 at 2:29 AM, Nino Saturnino Martinez Vazquez Wael wrote: Baah.. Theres already something on it: https://wicket-stuff.svn.sf.net/svnroot/wicket-stuff/trunk/wicketstuff-hibernate-behavior/ something on it here: http://jroller.com/wireframe/entry/hibernate_annotations_and_wicket Anything else for the wish list not already existing? :) Nino Saturnino Martinez Vazquez Wael wrote: Great:) First shot will probably be Hibernate Validation (is general and works without hibernate with any JPA provider), since I have a demo project for that, validation JSR 303 arent done yet AFAIK.. And I think im gonna try to use IVisitor to do it.. So it's actually a fairly simple one:) Jörn Zaefferer wrote: Oops, I missed that bit! Well, then I add: Annotations for form validation. Maybe integrated with the bean validation JSR, Hibernate Validation or standalone. Enabled by adding AnnotationValidator instance to a form or indivdual fields... Jörn On Fri, Sep 19, 2008 at 2:05 PM, Nino Saturnino Martinez Vazquez Wael wrote: wicketstuff!=wicket :) And it should not go on the wicket wiki... Jörn Zaefferer wrote: Don't we have already at least one wishlist on the wicket wiki? http://cwiki.apache.org/WICKET/#Index-WishListforNextVersion Jörn On Fri, Sep 19, 2008 at 12:30 PM, Nino Saturnino Martinez Vazquez Wael wrote: Hi I'd really like a wish list for wicketstuff. So reply with your wishes and I might have time at a point to implement it:) I'll start by adding this to the list: Integration with : http://code.google.com/p/iui/ I'll add a wishlist to the wiki or maybe my blog.. -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release date for 1.3.5?
Check the open issues for 1.3.5 on JIRA: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=priorityresolution=-1pid=12310561fixfor=12313175 They are down to 27 from ~35 a few days ago. Jörn On Mon, Sep 22, 2008 at 6:14 AM, ywtsang [EMAIL PROTECTED] wrote: as i also want to know the release schedule of 1.3.5, after searching the mail list, it seems this thread is the latest about the topic, so i bring this thread up again do we have a planned schedule for 1.3.5? thanks Jörn Zaefferer-2 wrote: Hi, is there a release date planned for 1.3.5? There are important updates in trunk, like protection against CSRF (https://issues.apache.org/jira/browse/WICKET-1782). If there isn't a date yet, what needs to be done to get one? Regards Jörn -- View this message in context: http://www.nabble.com/Release-date-for-1.3.5--tp19368299p19601665.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Markup parse doesn't handle Conditional Comments
We are using conditional comments in our base page without any issues.
Dunno if that page isn't parsed my the MarkupParser for some reason...
Jörn
On Mon, Sep 22, 2008 at 5:49 PM, Matej Knopp [EMAIL PROTECTED] wrote:
Well, if it is a valid xml then it is bug in our parser.
-Matej
On Mon, Sep 22, 2008 at 5:44 PM, Igor Vaynberg [EMAIL PROTECTED]wrote:
you are going to have to output the whole thing using a label or
header contributor. our parser cant handle the non-standard comment
tags yet.
-igor
On Mon, Sep 22, 2008 at 1:40 AM, Wayne Pope
[EMAIL PROTECTED] wrote:
Hi,
I just tried to put some conditional comments in my page:
!--[if lt IE 7]
style type=text/css
.dock img { behavior: url(css/iepngfix.htc) }
/style
![endif]--
and the Markupparser just can't seem to handle it:
Caused by: java.text.ParseException: Unclosed comment beginning at line:9
column:3
at
org.apache.wicket.markup.parser.XmlPullParser.specialTagHandling(XmlPullParser.java:332)
at
org.apache.wicket.markup.parser.XmlPullParser.next(XmlPullParser.java:243)
at
org.apache.wicket.markup.parser.XmlPullParser.nextTag(XmlPullParser.java:423)
at
org.apache.wicket.markup.parser.filter.WicketTagIdentifier.nextTag(WicketTagIdentifier.java:77)
at
org.apache.wicket.markup.parser.filter.TagTypeHandler.nextTag(TagTypeHandler.java:76)
at
org.apache.wicket.markup.parser.filter.HtmlHandler.nextTag(HtmlHandler.java:78)
at
org.apache.wicket.markup.parser.filter.WicketRemoveTagHandler.nextTag(WicketRemoveTagHandler.java:60)
at
org.apache.wicket.markup.parser.filter.WicketLinkTagHandler.nextTag(WicketLinkTagHandler.java:94)
at
org.apache.wicket.markup.parser.AbstractMarkupFilter.nextComponentTag(AbstractMarkupFilter.java:82)
at
org.apache.wicket.markup.parser.filter.WicketNamespaceHandler.nextTag(WicketNamespaceHandler.java:72)
at
org.apache.wicket.markup.parser.AbstractMarkupFilter.nextComponentTag(AbstractMarkupFilter.java:82)
at
org.apache.wicket.markup.parser.filter.WicketMessageTagHandler.nextTag(WicketMessageTagHandler.java:81)
at
org.apache.wicket.markup.parser.AbstractMarkupFilter.nextComponentTag(AbstractMarkupFilter.java:82)
at
org.apache.wicket.markup.parser.filter.HtmlHeaderSectionHandler.nextTag(HtmlHeaderSectionHandler.java:77)
at
org.apache.wicket.markup.parser.filter.HeadForceTagIdHandler.nextTag(HeadForceTagIdHandler.java:77)
at
org.apache.wicket.markup.parser.AbstractMarkupFilter.nextComponentTag(AbstractMarkupFilter.java:82)
at
org.apache.wicket.markup.parser.filter.OpenCloseTagExpander.nextTag(OpenCloseTagExpander.java:51)
at
org.apache.wicket.markup.parser.AbstractMarkupFilter.nextComponentTag(AbstractMarkupFilter.java:82)
at
org.apache.wicket.markup.parser.filter.EnclosureHandler.nextTag(EnclosureHandler.java:76)
at
org.apache.wicket.markup.parser.filter.RelativePathPrefixHandler.nextTag(RelativePathPrefixHandler.java:116)
at
org.apache.wicket.markup.MarkupParser.getNextTag(MarkupParser.java:302)
at
org.apache.wicket.markup.MarkupParser.parseMarkup(MarkupParser.java:322)
... 35 more
Any way of handling this?
thanks
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Announce] The Wicket Reflex Game:)
Fun! The loading indicator is annoying, makes the game feel jumpy/slow. Also I didn't ever see a blue or yellow box - whats the deal with those? Jörn On Thu, Sep 25, 2008 at 9:23 AM, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED] wrote: Hi I've done a small game using Wicket and Ajax, consider it an ajax show case for wicket.. It's in a prototype state, I used a few hours yesterday on it.. The game it self lasts about 20 seconds depending on latency etc. And you can get 20 points by clicking small boxes. I want to see your name on the highscore:) http://wicketgames.ninosbox.thruhere.net/ Im hosting it on my own box as you see ( http://wicketgames.ninosbox.thruhere.net/ ) , so responses could be slow it's a p3 500 mhz running other stuff aswell.. -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WANG–Wicket Ajax Next Generation–being based on YUI (MD)
There is something new to consider when choosing a JavaScript library as Wicket's base: http://www.jondavis.net/blog/post/2008/09/jQuery-Has-Won-The-3-Year-Javascript-Framework-Battle-As-Far-As-Im-Concerned.aspx http://www.hanselman.com/blog/jQuerytoshipwithASPNETMVCandVisualStudio.aspx Jörn On Wed, Aug 27, 2008 at 1:05 AM, Matej Knopp [EMAIL PROTECTED] wrote: On Wed, Aug 27, 2008 at 12:50 AM, Jörn Zaefferer [EMAIL PROTECTED] wrote: On Tue, Aug 26, 2008 at 10:19 PM, Matej Knopp [EMAIL PROTECTED] wrote: Hi, On Tue, Aug 26, 2008 at 9:24 PM, jWeekend [EMAIL PROTECTED] wrote: Matej, What are the implications of the decision to base Wicket Ajax Next Generation on YUI in terms of choosing a Javascript library for future Wicket based web front ends? actually, there really are none. The use of YUI will be more or less internal to Wicket, so you can continue using jQuery, YUI2 or whatever else you are using. Everything in Wicket (and YUI) is namespaced so there are no conflicts. Of course there is the overhead of including two or more libraries in an application, which don't find desirable. Wicket uses only part of YUI, the compressed minified required YUI javascript is about 20kb big. I would understand the concern if I used dojo or some other behemoth with 200+ kb of compressed javascript. + there's huge number and variety of jQuery plugins for those special occasions. Unfortunately the quality of plugins varies. For actual wicket ajax implementation i prefer to stick with the core thing, and that's where YUI definitely beats jquery. I don't say that there are no plugins for jQuery that covers YUI functionality. Question is how well are those plugins supported and maintained. You are well on the point that the variety of plugins varies. I see it this way: jQuery core is small, very stable and the base for everything else JS-related. jQuery UI is the official project providing the same stability and quality for various high-level UI components (like dialogs) and also low-level components (like dragdrop, sortables). We'll see at least two major releases this year that add more components to the mix. Anything else that isn't covered by core or UI is almost always covered by some third-party plugin. While these plugin can be of bady quality (eg. no documentation/demos), they can still provide a good starting point, so that you don't have to start from scratch. Even if you do a full rewrite, the existing plugin can expose useful information like potential browser-bug-traps. Problem is that the jQuery core doesn't cut it. And rewriting plugins from scratch? Are you serious? This is exactly the reason why I decided to use YUI. The stuff that I need is there, it is supported and maintained. Anyway, as I say, this doesn't make any implication to Wicket users or 3rd party components. The reason why wicket ajax is based on another framework is to get rid of most of the low level browser specific code we have currently so that I wouldn't have to maintain it :) Whatever the framework, I think its a good idea to start with something well supported and tested. Thats why I use Wicket, though I'd like it even more with jQuery as the base framework :-) At this point, I really don't see any advantage that YUI would give me over jQuery. Also it is possible that InMethod grid will be part of Wicket 1.5 extensions which is another point for using YUI. Rewriting the grid with jquery would be a huge pain. -Matej Jörn PS: Comet support is a nice to have, but I think there a way more important things for core than that, eg. annotation-based validation - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WANG–Wicket Ajax Next Generation–being based on YUI (MD)
It would be a big plus for me if Wicket would adopt jQuery. Drupal does that, and anyone writing a Drupal module can rely on the fact that jQuery is available. Same for Wordpress, where plugin authors can rely on the availability of jQuery. And not having to load more than one library, internal or not, is a good thing performance-wise. In response to your examples: Unbinding only particular event handlers without having a reference to the handler function can be achieved with namespaces: $(element).bind(click.somethingUnique, handleClick); $(element).unbind(click.somethingUnique); That way you don't have to keep a reference at all, while its possible to group multiple events into one namespace. This is now heavily used by most jQuery UI components when destroyed, to clean up their own event handlers without affecting any other. Multiple file upload we'll eventually have as part of jQuery UI. That would then be the same level of official and supported component that YUI provides. The descision to add new components is partly community-driven. So if you think multipart ajax uploads should be added, just ask for it. About selectors: John Resig is currently working on a new selector engine that likely outperformances any other selector engine available so far. Its developed as a standalone library, so its likely that MochKit and Prototype will use it, too. jQuery 1.3. will also provide heavy performance improvements for DOM manipulations, which I'm very exited about as that is usually where most time is spent. Its easy to avoid running certain selectors too often, but its hard to optimize DOM manipulation in clientcode. Anyway, thanks for taking the time to discuss this again. Jörn On Mon, Sep 29, 2008 at 12:54 PM, Matej Knopp [EMAIL PROTECTED] wrote: Are you really that surprised that Microsoft is not shipping YUI after the failed attempts to take over Yahoo? :) Seriously, there are technical reasons why I considered to use YUI, not political. Just because some companies use jQuery it doesn't mean Wicket should use it. Say most of the companies use JSF, does it mean we should? As I said, I really like the way YUI api is designed. Also there are things in YUI core that are only available as jQuery plugins. The plugins have different lifecycle than the core and are mantained differently. Also keep in mind that the javascript Wicket-Ajax uses is internal to Wicket. Let me give you an example where I find YUI (3) api more elegant. That's just one of many things and it is of course my personal opinion. If i want to unbind event in jQuery, i need to remember event name and the exact handler instance. For YUI, i get event handler on bind that i can just call detach on and the event is unbound. var h = Y.on(click, handleClick, element); h.detach(); Of course it is possible to mock the behavior with jQuery, but that's not really the point, is it? Another this is functionality provided in core. YUI can handle multipart Ajax uploads (well, it can't do that in 3.0 yet, but it's very likely it will be as it was supported in 2.x). For jQuery, i need to use a plugin for it. The reason why I feel so uneasy about plugins is that I've tried some. And the quality really varies. I think selectors might be the part where jQuery really shines. But that's the part not needed by Wicket at all. Plus YUI has selectors too (although maybe not that fast - I don't know, haven't profiled them). Also the new YUI3 node API resembles jQuery chaining API for those who like it. -Matej On Mon, Sep 29, 2008 at 4:01 AM, Jörn Zaefferer [EMAIL PROTECTED] wrote: There is something new to consider when choosing a JavaScript library as Wicket's base: http://www.jondavis.net/blog/post/2008/09/jQuery-Has-Won-The-3-Year-Javascript-Framework-Battle-As-Far-As-Im-Concerned.aspx http://www.hanselman.com/blog/jQuerytoshipwithASPNETMVCandVisualStudio.aspx Jörn On Wed, Aug 27, 2008 at 1:05 AM, Matej Knopp [EMAIL PROTECTED] wrote: On Wed, Aug 27, 2008 at 12:50 AM, Jörn Zaefferer [EMAIL PROTECTED] wrote: On Tue, Aug 26, 2008 at 10:19 PM, Matej Knopp [EMAIL PROTECTED] wrote: Hi, On Tue, Aug 26, 2008 at 9:24 PM, jWeekend [EMAIL PROTECTED] wrote: Matej, What are the implications of the decision to base Wicket Ajax Next Generation on YUI in terms of choosing a Javascript library for future Wicket based web front ends? actually, there really are none. The use of YUI will be more or less internal to Wicket, so you can continue using jQuery, YUI2 or whatever else you are using. Everything in Wicket (and YUI) is namespaced so there are no conflicts. Of course there is the overhead of including two or more libraries in an application, which don't find desirable. Wicket uses only part of YUI, the compressed minified required YUI javascript is about 20kb big. I would understand the concern if I used dojo or some other behemoth with 200+ kb of compressed javascript. + there's huge
Re: WANG–Wicket Ajax Next Generation–being based on YUI (MD)
I guess I didn't quite get the file upload example in the first place. Uploading via iframe is supported by jQuery's form plugin, which is one of the best plugins we have. We plan to add it, together with other related plugins, to jQuery UI forms (or something like that). About selectors: jQuery promotes progressive enhancement a lot, and selectors are essential for that. One example for that is that we avoid inline onclick=.. and similar stuff. I'm not sure how that would be handled by Wicket, and if using jQuery would open ways to handle things differently. I can't give you too many details on replaceOuterHtml, though that sounds like I can easily get more info on. Currently jQuery does a lot of work cleaning html input that is appended into the DOM, which seems to be basically the same usecase here. Also executing script-tags is something we cover. Could you give me an example how exactly replaceOuterHTML is currently used? About the Microsoft argument: True, from a technical perspective that doesn't matter. But its an important political aspect: I already read a few comments from people that couldn't use jQuery due to a general no open-source policy - but now that Microsoft, that had exactly that policy, is changed theirs, it could enable others to adopt it, too. Jörn PS: I'm currently sitting on a panel with PPK and guys from Prototype, Dojo, YUI and jQuery. One question was: What library would you recommend but your own?. Two of the three non-jQuery guys recommened jQuery On Mon, Sep 29, 2008 at 1:41 PM, Matej Knopp [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 1:18 PM, Jörn Zaefferer [EMAIL PROTECTED] wrote: It would be a big plus for me if Wicket would adopt jQuery. Drupal does that, and anyone writing a Drupal module can rely on the fact that jQuery is available. Same for Wordpress, where plugin authors can rely on the availability of jQuery. And not having to load more than one library, internal or not, is a good thing performance-wise. In response to your examples: Unbinding only particular event handlers without having a reference to the handler function can be achieved with namespaces: $(element).bind(click.somethingUnique, handleClick); $(element).unbind(click.somethingUnique); But that's not quite the same. This requires me to use generate and keep a unique string. Anyway, this is a cosmetic issue only. That way you don't have to keep a reference at all, while its possible to group multiple events into one namespace. This is now heavily used by most jQuery UI components when destroyed, to clean up their own event handlers without affecting any other. Multiple file upload we'll eventually have as part of jQuery UI. That would then be the same level of official and supported component that YUI provides. The descision to add new components is partly community-driven. So if you think multipart ajax uploads should be added, just ask for it. This is not about multiple file upload. We already have such component in Wicket. This is about support for input type=file on ajax uploads - just use hidden frame instead of xml http request. About selectors: John Resig is currently working on a new selector engine that likely outperformances any other selector engine available so far. Its developed as a standalone library, so its likely that MochKit and Prototype will use it, too. That sure is nice, but the selectors are not used in Wicket core at all. jQuery 1.3. will also provide heavy performance improvements for DOM manipulations, which I'm very exited about as that is usually where most time is spent. Its easy to avoid running certain selectors too often, but its hard to optimize DOM manipulation in clientcode. While we at this, I'd like to ask. Significant part of Wicket ajax is Wicket.replaceOuterHtml method. This was really a major pain to implement and stabilize. What it does is basically a replaceOuterHTML call for all browser but it works in totally cross browser consistent way. I.e. it allows table rows, cells etc replaced in internet explorer and it also executes embedded script tags on browsers that would normally not do that (basically all except for Firefox). So my question is, just out of curiosity, is there/will there be similar functionality provided by jQuery? Anyway, thanks for taking the time to discuss this again. Sure. Keep in mind that the decision is not carved to stone. I'm open to argument, but I'm really interested in technical aspect. Having Microsoft will use jQuery is not really a valid argument to me :) -Matej Jörn On Mon, Sep 29, 2008 at 12:54 PM, Matej Knopp [EMAIL PROTECTED] wrote: Are you really that surprised that Microsoft is not shipping YUI after the failed attempts to take over Yahoo? :) Seriously, there are technical reasons why I considered to use YUI, not political. Just because some companies use jQuery it doesn't mean Wicket should use it. Say most of the companies use JSF, does
Re: WANG–Wicket Ajax Next Generation–being based on YUI (MD)
Wicket.replaceOuterHTML(element, newmarkup); would be this in jQuery: $(element).after(newmarkup).remove(); That inserts the new stuff after the element, then removes the element, leaving only the new content in the DOM. after() takes care of cleanup stuff for table colgroups, rows and cells, legends, options and so on. Jörn On Mon, Sep 29, 2008 at 11:31 PM, Matej Knopp [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 11:13 PM, Jörn Zaefferer [EMAIL PROTECTED] wrote: I guess I didn't quite get the file upload example in the first place. Uploading via iframe is supported by jQuery's form plugin, which is one of the best plugins we have. We plan to add it, together with other related plugins, to jQuery UI forms (or something like that). Well, that's what I'm talking about. It's a separate plugin. I don't know how good the plugin is. How actively it is mantained. Can I rely on it? Those are the questions I do not need to ask when dealing with YUI. About selectors: jQuery promotes progressive enhancement a lot, and selectors are essential for that. One example for that is that we avoid inline onclick=.. and similar stuff. I'm not sure how that would be handled by Wicket, and if using jQuery would open ways to handle things differently. In wicket 1.5 there won't be any inline handlers in the markup. All events will be attached separately. I can't give you too many details on replaceOuterHtml, though that sounds like I can easily get more info on. Currently jQuery does a lot of work cleaning html input that is appended into the DOM, which seems to be basically the same usecase here. Also executing script-tags is something we cover. Could you give me an example how exactly replaceOuterHTML is currently used? It is used every time Ajax request replaces component on page. Wicket.replaceOuterHTML(element, newmarkup); It replaces the element (the tag itself) with the new markup. But it takes care of some things such as when the element is a table row or cell, or if there are script tag embedded in the markup. About the Microsoft argument: True, from a technical perspective that doesn't matter. But its an important political aspect: I already read a few comments from people that couldn't use jQuery due to a general no open-source policy - but now that Microsoft, that had exactly that policy, is changed theirs, it could enable others to adopt it, too. Well, I consider YAHOO to be a player that is major enough when the political questions arise. As for Microsoft and it's no open-source policy, well, until vista they have been using BSD network stack and had no problems with that as far as i can tell :) -Matej Jörn PS: I'm currently sitting on a panel with PPK and guys from Prototype, Dojo, YUI and jQuery. One question was: What library would you recommend but your own?. Two of the three non-jQuery guys recommened jQuery On Mon, Sep 29, 2008 at 1:41 PM, Matej Knopp [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 1:18 PM, Jörn Zaefferer [EMAIL PROTECTED] wrote: It would be a big plus for me if Wicket would adopt jQuery. Drupal does that, and anyone writing a Drupal module can rely on the fact that jQuery is available. Same for Wordpress, where plugin authors can rely on the availability of jQuery. And not having to load more than one library, internal or not, is a good thing performance-wise. In response to your examples: Unbinding only particular event handlers without having a reference to the handler function can be achieved with namespaces: $(element).bind(click.somethingUnique, handleClick); $(element).unbind(click.somethingUnique); But that's not quite the same. This requires me to use generate and keep a unique string. Anyway, this is a cosmetic issue only. That way you don't have to keep a reference at all, while its possible to group multiple events into one namespace. This is now heavily used by most jQuery UI components when destroyed, to clean up their own event handlers without affecting any other. Multiple file upload we'll eventually have as part of jQuery UI. That would then be the same level of official and supported component that YUI provides. The descision to add new components is partly community-driven. So if you think multipart ajax uploads should be added, just ask for it. This is not about multiple file upload. We already have such component in Wicket. This is about support for input type=file on ajax uploads - just use hidden frame instead of xml http request. About selectors: John Resig is currently working on a new selector engine that likely outperformances any other selector engine available so far. Its developed as a standalone library, so its likely that MochKit and Prototype will use it, too. That sure is nice, but the selectors are not used in Wicket core at all. jQuery 1.3. will also provide heavy performance improvements for DOM manipulations, which I'm very exited about
Re: WANG–Wicket Ajax Next Generation–being based on YUI (MD)
I'll go through a few things in the wicket-ajax-ng.js file, to give an
idea how that could look like when putting it on top of jQuery. I skip
all stuff where I can't guess while scanning the code whats its
supposed to do.
W.$ looks like it selects one or more elements by id. Selecting is
completely encapsulated in the jQuery-function, so you would change
the usage a bit:
W.$(myID) == $(#myID).get(0)
W.$(id1, id2) == $(#id1, #id2).get()
Usually you won't need to reference the DOM elements, so you could
remove the get(0) and get() calls.
W.$$ would just use:
if ($(#id).size() ) {
// element exists
}
copyArray can be replaced with jQuery.makeArray
(http://dev.jquery.com/browser/trunk/jquery/src/core.js#L1130), which
is heavily optimized and takes stuff like passing window as an
argument into account.
iterateArray could be replaced with jQuery.each, though the symantics
are slightly different. jQuery.each iterates over both objects and
arrays.
The GarbageCollector wouldn't be necessary: jQuery cleans up all event
listeneres when removing elements from the DOM. You don't have to
bother with that at all.
Like I mentioned earlier, replaceOuterHtmlXXX shouldn't be necessary
at all, jQuery handles that automatically for all DOM manipulation
methods.
mapToUrlParameters would be handled by jQuery.param. Though usually
when using jQuery's ajax methods, you don't have to worry about that.
For example, to post some parameters to the server, you'd just use
jQuery.ajax with the data option:
$.ajax({
url: ...,
method: post
data: {
key1: value1,
key2: value2
}
});
And so far I've covered only jQuery core functionality. What do you think?
Jörn
On Mon, Sep 29, 2008 at 11:50 PM, Matej Knopp [EMAIL PROTECTED] wrote:
Okay, let's keep this focused.
Here is my experimental branch.
http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/
There is new Ajax implementation here:
http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/js/wicket-ajax-ng.js
and the main AjaxBehavior here:
http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/AjaxBehavior.java
What I'd like to hear is what exactly is wrong with it and how using
jQuery (or any other framework for that matter) could improve things.
-Matej
On Mon, Sep 29, 2008 at 11:45 PM, Martijn Dashorst
[EMAIL PROTECTED] wrote:
On Mon, Sep 29, 2008 at 11:13 PM, Jörn Zaefferer
[EMAIL PROTECTED] wrote:
PS: I'm currently sitting on a panel with PPK and guys from Prototype,
Dojo, YUI and jQuery. One question was: What library would you
recommend but your own?. Two of the three non-jQuery guys recommened
jQuery
So you're saying that 75% of the leading JS framework community think
jquery is second best.
Please keep the jquery marketing BS and fanboyism to the jquery
forums. It serves nobody any good. In fact it makes me cringe and want
to -1 any and all votes for adopting anything near jquery.
Martijn
-
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: WANG–Wicket Ajax Next Generation–being based on YUI (MD)
ExtJS actually tried implementing bridges to other libraries when they tried to get independent of YUI. The ended with rolling their own and removing all bridges. Unfortunately its still a bloated intertangled web of dependencies, with over 200k for just some basics... Jörn On Tue, Sep 30, 2008 at 10:03 AM, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED] wrote: Hi Matej I was just thinking if WANG Wicket Ajax comes loosely coupled to the js lib? If it does, then people could then implement their own js bridge to what ever js framework they like... Im just thinking aloud here... Btw, I don't care which js lib you are gonna use as long as it's the best for wicket and you. Matej Knopp wrote: Okay, let's keep this focused. Here is my experimental branch. http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/ There is new Ajax implementation here: http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/js/wicket-ajax-ng.js and the main AjaxBehavior here: http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/AjaxBehavior.java What I'd like to hear is what exactly is wrong with it and how using jQuery (or any other framework for that matter) could improve things. -Matej On Mon, Sep 29, 2008 at 11:45 PM, Martijn Dashorst [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 11:13 PM, Jörn Zaefferer [EMAIL PROTECTED] wrote: PS: I'm currently sitting on a panel with PPK and guys from Prototype, Dojo, YUI and jQuery. One question was: What library would you recommend but your own?. Two of the three non-jQuery guys recommened jQuery So you're saying that 75% of the leading JS framework community think jquery is second best. Please keep the jquery marketing BS and fanboyism to the jquery forums. It serves nobody any good. In fact it makes me cringe and want to -1 any and all votes for adopting anything near jquery. Martijn - 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] -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WANG–Wicket Ajax Next Generation–being based on YUI (MD)
About removing events when removing elements: jQuery always removes
events when removing an element from the DOM. If you want to actually
move an element to insert it somewhere else, you can do that just as
well, you just may not use it with remove. Eg.
$(element).insertAfter(otherElement); will move element somewhere
else, keeping all events intact.
The replaceOuterHTML-replacement should be already heavily optimized,
though thats actually something that should work much better in jQuery
1.3, which is planned for fall 2008.
About get/post: True, if you use method: post, all data-parameters
are posted. Though you can still just use $.param to seriliaze the
get-parameters and append it manually to the URL.
$.ajax({
url: ...? + $.param(getParams),
data: postParams
});
Offset and position computations were part of the dimensions plugin,
which is now merged into jQuery core, so that is readily available and
official.
Jörn
On Tue, Sep 30, 2008 at 3:27 PM, Matej Knopp [EMAIL PROTECTED] wrote:
Thanks for the response.
On Tue, Sep 30, 2008 at 5:11 AM, Jörn Zaefferer
[EMAIL PROTECTED] wrote:
I'll go through a few things in the wicket-ajax-ng.js file, to give an
idea how that could look like when putting it on top of jQuery. I skip
all stuff where I can't guess while scanning the code whats its
supposed to do.
W.$ looks like it selects one or more elements by id. Selecting is
completely encapsulated in the jQuery-function, so you would change
the usage a bit:
W.$(myID) == $(#myID).get(0)
W.$(id1, id2) == $(#id1, #id2).get()
well, since we are not using any selector but # here, this is more
like a cosmetic thing.
Usually you won't need to reference the DOM elements, so you could
remove the get(0) and get() calls.
W.$$ would just use:
if ($(#id).size() ) {
// element exists
}
That's not entirely corrent i believe. If you pass element instance to
W.$$ it checks if the element is part of active document. That's very
important for wicket to determine if the queued ajax request is still
valid.
copyArray can be replaced with jQuery.makeArray
(http://dev.jquery.com/browser/trunk/jquery/src/core.js#L1130), which
is heavily optimized and takes stuff like passing window as an
argument into account.
We only copy small arrays, the performance of array copy has never
bothered me much :)
iterateArray could be replaced with jQuery.each, though the symantics
are slightly different. jQuery.each iterates over both objects and
arrays.
The GarbageCollector wouldn't be necessary: jQuery cleans up all event
listeneres when removing elements from the DOM. You don't have to
bother with that at all.
Well, this is a rather unfortunate thing with YUI. If you bind event
to element and then remove the element, yui only seem to release the
element when window is being unloaded, which causes certain problems
in IE. The memory consumption grows over time if you stay on single
page, though it's not really a leak because the memory gets reclaimed
on page reload. That's why i built the garbage collector that goes
over elements and checks if they are still in the document.
So I'm a bit curious here, how does jQuery know that element has been
removed from document? And how does it know that I don't want to use
it anymore? Or are all the events released when I use jQuery API to
remove element from document? But what if i keep reference to that
element myself (after removing it from the document) and I don't want
the events to be removed (this part isn't really solved with current
version of the Garbage Collectior either).
Like I mentioned earlier, replaceOuterHtmlXXX shouldn't be necessary
at all, jQuery handles that automatically for all DOM manipulation
methods.
That's a good news if the method really works as advertised (plus has
decent performance for replacing large chunks of markup, which I'd
have to test first though).
mapToUrlParameters would be handled by jQuery.param. Though usually
when using jQuery's ajax methods, you don't have to worry about that.
For example, to post some parameters to the server, you'd just use
jQuery.ajax with the data option:
Sure, as long as jQuery allows me to make distinction between GET and
POST parameters. If it doesn't, I'd still have to encode the
parameters for query string myself.
$.ajax({
url: ...,
method: post
data: {
key1: value1,
key2: value2
}
});
And so far I've covered only jQuery core functionality. What do you think?
Well, so far the element replacement method would be a benefit if it
really works like Wicket.replaceOuterHTML does. As well as no
leaking when removing elements with attached events from document,
if it, indeed, works :)
One thing that has crossed my mind too. YUI contains API for getting
absolute coordinates of element as well as settings absolute
coordinates to element (it takes care of setting proper position
attributes, etc.). Last time I checked this was only
Re: Client side validation behaviors - already started?
What approach for client-side validation are you looking for? I may be able to help with that. Jörn On Fri, Oct 3, 2008 at 5:50 AM, Jeremy Thomerson [EMAIL PROTECTED] wrote: I've been thinking of trying to create some behaviors that combine the standard server-side validation with client-side validation. I just wanted to check to see if anyone knew of something like this already started. I don't want to duplicate work already done. Thanks, -- Jeremy Thomerson http://www.wickettraining.com
Re: Client side validation behaviors - already started?
Okay, this sounds like the validation plugin (I've written) could be
useful: http://bassistance.de/jquery-plugins/jquery-plugin-validation/
You'd add a very small script to the head: $(function() {
$(#formid).validate() });
And then create inline rules based on the validation behaviour. There
are two options for those: Either classes and (custom attributes) or
metadata (which requires an additional plugin). I think
classes/attributes work really well and result in readable HTML,
though depending on the rules in use, it won't validate. For example,
to make an input required and an email address:
input class=required email name=... /
For an optional input with min and max length:
input minlength=5 maxlength=15 /
For an input with min/max value:
input min=5 max=10 /
Those are actually attributes defined by HTLM5
(http://www.whatwg.org/specs/web-apps/current-work/#the-min-and-max-attributes).
I've tried to keep it close to specs where possible and already
existing.
The thing is: generating those classes/attributes with Wicket is
really easy and already works fine in a lot of projects. Let me know
if invalid HTLM isn't acceptable, and I'll detail the alternatives.
Jörn
On Sat, Oct 4, 2008 at 4:39 PM, Jeremy Thomerson
[EMAIL PROTECTED] wrote:
Basically, where you would normally call:
Formcomponent.add(IValidator),
You could now add a behavior. In my behavior, on bind I add the server-side
equivalent validator. Then in renderHead, I add some onLoad JS that adds the
component to a JS array of components to be validated on form submit.
Let me get a little more of the basic started, and then I would REALLY
welcome the help! Maybe tomorrow night or Monday I can get a wicketstuff
project started for it...
The help will be great - my JS fu is rusty!
Jeremy Thomerson
http://www.wickettraining.com
-- sent from a wireless device
-Original Message-
From: Jörn Zaefferer =F6rn_Zaefferer _ [EMAIL PROTECTED]
Sent: Saturday, October 04, 2008 5:50 AM
To: users@wicket.apache.org
Subject: Re: Client side validation behaviors - already started?
What approach for client-side validation are you looking for? I may be
able to help with that.
Jörn
On Fri, Oct 3, 2008 at 5:50 AM, Jeremy Thomerson
[EMAIL PROTECTED] wrote:
I've been thinking of trying to create some behaviors that combine the
standard server-side validation with client-side validation. I just wanted
to check to see if anyone knew of something like this already started. I
don't want to duplicate work already done.
Thanks,
--
Jeremy Thomerson
http://www.wickettraining.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Client side validation behaviors - already started?
First thing that I have to notice: ClientAndServerExactLengthValidatingBehavior is an awful class name. LengthValidation would be enough. The other thing: I wouldn't use clientside validation when it validates on submit only. It should validate non-empty fields on blur, and fields already marked as invalid on keyup. Without that there really isn't much of a point in using clientside validation at all. I'll try to look at your actual code, though some examples would help a lot! Jörn On Sun, Oct 5, 2008 at 7:33 AM, Jeremy Thomerson [EMAIL PROTECTED] wrote: Okay, I was able to commit what I had already started on. This is only a few hours work, so it is nowhere near complete. However, I have the basis for the framework, and a replica of all the StringValidator validation done. https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-client-and-server-validation/ Here are the basic features: - By simply replacing formcomponent.add(StringValidator.exactLength(4)) with add(new ClientAndServerExactLengthValidatingBehavior(form, 4)), it will do the client side validation and add the server side IValidator for you. - It is internationalized because it uses all of the same resource keys / messages that the standard Wicket validators use. - It can insert feedback messages onto the page in a feedback panel or other WebMarkupContainer by calling feedbackpanel.add(new ClientAndServerValidatingFeedbackBehavior(form)) - this will make it use the same appearance that the normal feedback panel would generate. I'm sure there is quite a bit of stuff that can be cleaned up, especially in the JS code. For instance, I'm using document.getElementById quite a bit, but I'm not sure if there are some browsers that may not support that. I need to look because I can't remember. Anyway, feedback is welcome! NOTE: I had started it within another project and was testing it there. I have not had time to test it again after I moved it to its own project. Since all I did was move it, add the license info and rename the packages, it should still work, but you know how that goes. -- Jeremy Thomerson http://www.wickettraining.com On Sat, Oct 4, 2008 at 9:39 AM, Jeremy Thomerson [EMAIL PROTECTED]wrote: Basically, where you would normally call: Formcomponent.add(IValidator), You could now add a behavior. In my behavior, on bind I add the server-side equivalent validator. Then in renderHead, I add some onLoad JS that adds the component to a JS array of components to be validated on form submit. Let me get a little more of the basic started, and then I would REALLY welcome the help! Maybe tomorrow night or Monday I can get a wicketstuff project started for it... The help will be great - my JS fu is rusty! Jeremy Thomerson http://www.wickettraining.com -- sent from a wireless device -Original Message- From: Jörn Zaefferer =F6rn_Zaefferer _ [EMAIL PROTECTED] Sent: Saturday, October 04, 2008 5:50 AM To: users@wicket.apache.org Subject: Re: Client side validation behaviors - already started? What approach for client-side validation are you looking for? I may be able to help with that. Jörn On Fri, Oct 3, 2008 at 5:50 AM, Jeremy Thomerson [EMAIL PROTECTED] wrote: I've been thinking of trying to create some behaviors that combine the standard server-side validation with client-side validation. I just wanted to check to see if anyone knew of something like this already started. I don't want to duplicate work already done. Thanks, -- Jeremy Thomerson http://www.wickettraining.com
Re: Pages or components... how do u decide?
A URL is quite a strong argument for using pages. With the wicket-annotations project its dead-easy to make pages bookmarkable, just add @MountPath(path=/path/to/page). Jörn On Sun, Oct 19, 2008 at 11:55 PM, Ned Collyer [EMAIL PROTECTED] wrote: I use markup inheritance for some pages, but I try to avoid making new pages (after all, what do they give you that a panel does not (other than an URL)?) I do use markup inheritance for components A LOT!! jwcarman wrote: Are you using one page and just passing in your content component? Are you not using markup inheritance? On Thu, Oct 16, 2008 at 5:16 PM, Ned Collyer [EMAIL PROTECTED] wrote: The system I'm building at the moment has almost everything pushed down into components. Most of the functionality is achieved by a single base page which takes a component in its constructor. For Bookmarkable pages, I extend this base page, and pass a component to the super. How do _you_ separate concerns? Is there a best practice? A benefit of using a page is that it can be accessed with getPage() regardless of how deep in the hierarchy you are... so I guess it could be useful for storing the primary model for that section of the site. Anyway, I'm interested in hearing how others deal with Page vs Components, and how they structure their applications. So many ways of skinning a cat :) Rgds Ned -- View this message in context: http://www.nabble.com/Pages-or-components...-how-do-u-decide--tp20016807p20016807.html Sent from the Wicket - User mailing list archive at Nabble.com. - 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] -- View this message in context: http://www.nabble.com/Pages-or-components...-how-do-u-decide--tp20016807p20060673.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
CSRF Protection: double submitted cookie
Hi, my application currently uses CryptedUrlWebRequestCodingStrategy to protect against CRSF attacks. Afaik 1.3.5 will include an update that generates the key based on user sessions: http://issues.apache.org/jira/browse/WICKET-1782 According to Johan Compagner, there are still issues with that approach, though I don't know if that has been fixed: http://www.nabble.com/Wicket-not-secure--to19556259.html#a19557593 Anyway, the point of this mail is to bring up a different strategy for CSRF protection, the double-submitted-cookie. Discussion of that are here http://www.codinghorror.com/blog/archives/001175.html which links to this article, including a whitepaper: http://freedom-to-tinker.com/blog/wzeller/popular-websites-vulnerable-cross-site-request-forgery-attacks The basic idea is: When a user visits a site, the site should generate a (cryptographically strong) pseudorandom value and set it as a cookie on the user's machine. The site should require every form submission to include this pseudorandom value as a form value and also as a cookie value. When a POST request is sent to the site, the request should only be considered valid if the form value and the cookie value are the same. When an attacker submits a form on behalf of a user, he can only modify the values of the form. An attacker cannot read any data sent from the server or modify cookie values, per the same-origin policy. This means that while an attacker can send any value he wants with the form, he will be unable to modify or read the value stored in the cookie. Since the cookie value and the form value must be the same, the attacker will be unable to successfully submit a form unless he is able to guess the pseudorandom value. For Wicket, this would mean: Generate a pseudorandom value and set is as a session cookie, when the cookie doesn't yet exist. Insert a hidden input into each form with the generated value. Validate that the value equals the cookie when submitting a form. The input and validation can be abstracted into a Form subclass (or even add it to Wicket's Form class...). That really easy to implement, is much more efficient (generate only one value per user/browser session, store it on the client, not the server) and is now the most common strategy to protect against CSRF attacks. I've read a lot about CSRF, and this strategy seems the only one both easy enough to implement and without holes. What do you think? Should Wicket support that out-of-the-box? Jörn
Re: CSRF Protection: double submitted cookie
No, the cookie is subject to the same-origin-policy, both in reading and writing. The request is authenticated because the session cookie is set, but its invalid when the form itself is missing the value. Combining the attack with XSS would give access to the cookie, but then he could just as well hijack the session directly. In other words: With CSRF alone there is no way for the attacker to read the cookie, therefore its enough to use just one. Their whitepaper may do a better job of explaining the techniquie: http://www.freedom-to-tinker.com/sites/default/files/csrf.pdf Solutions are described on page 8ff. Jörn On Mon, Oct 20, 2008 at 12:33 PM, Johan Compagner [EMAIL PROTECTED] wrote: what i dont get if an attacker wants to submit the form. and it can get to the form it can do the post but you say it cant access the cookie. But if the cookie value is just compared to the form post value we have to make sure that the name of the cookie cant be guessed right? So what should the name be? Because if the name would be wicket-form-uuid then couldnt the attacker also just generate that cookie? I guess there is a cookie per form (there can be many forms on the same page or different active pages) and that cookie must be regenerated/set on every form render? johan On Mon, Oct 20, 2008 at 11:27 AM, Jörn Zaefferer [EMAIL PROTECTED] wrote: Hi, my application currently uses CryptedUrlWebRequestCodingStrategy to protect against CRSF attacks. Afaik 1.3.5 will include an update that generates the key based on user sessions: http://issues.apache.org/jira/browse/WICKET-1782 According to Johan Compagner, there are still issues with that approach, though I don't know if that has been fixed: http://www.nabble.com/Wicket-not-secure--to19556259.html#a19557593 Anyway, the point of this mail is to bring up a different strategy for CSRF protection, the double-submitted-cookie. Discussion of that are here http://www.codinghorror.com/blog/archives/001175.html which links to this article, including a whitepaper: http://freedom-to-tinker.com/blog/wzeller/popular-websites-vulnerable-cross-site-request-forgery-attacks The basic idea is: When a user visits a site, the site should generate a (cryptographically strong) pseudorandom value and set it as a cookie on the user's machine. The site should require every form submission to include this pseudorandom value as a form value and also as a cookie value. When a POST request is sent to the site, the request should only be considered valid if the form value and the cookie value are the same. When an attacker submits a form on behalf of a user, he can only modify the values of the form. An attacker cannot read any data sent from the server or modify cookie values, per the same-origin policy. This means that while an attacker can send any value he wants with the form, he will be unable to modify or read the value stored in the cookie. Since the cookie value and the form value must be the same, the attacker will be unable to successfully submit a form unless he is able to guess the pseudorandom value. For Wicket, this would mean: Generate a pseudorandom value and set is as a session cookie, when the cookie doesn't yet exist. Insert a hidden input into each form with the generated value. Validate that the value equals the cookie when submitting a form. The input and validation can be abstracted into a Form subclass (or even add it to Wicket's Form class...). That really easy to implement, is much more efficient (generate only one value per user/browser session, store it on the client, not the server) and is now the most common strategy to protect against CSRF attacks. I've read a lot about CSRF, and this strategy seems the only one both easy enough to implement and without holes. What do you think? Should Wicket support that out-of-the-box? Jörn
Re: CSRF Protection: double submitted cookie
I've looked at CSRFGuard, the approach has several of the drawbacks described in the paper. Its much less effective then the double-submitted-cookie, eg. it involves buffering and rewriting the response to modify forms. It generates values for each rendered form and stores it in the user session (http://www.owasp.org/index.php/How_CSRFGuard_Works). The double-submitted-cookie doesn't require any serverstate at all. I'm not sure what happens when you open multiple tabs/windows, but considering that the value is stored in the session, it probably breaks. Again something the cookie pattern isn't affected by. Jörn On Mon, Oct 20, 2008 at 12:42 PM, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED] wrote: I found this interesting: Don't forget OWASP CSRFTester and CSRFGuard http://freedom-to-tinker.com/blog/wzeller/popular-websites-vulnerable-cross-site-request-forgery-attacks#comment-100619 Comment by Jeff Williams http://www.owasp.org on September 29th, 2008 at 9:53 am. OWASP has made two tools available to help with CSRF problems. The first is CSRFTester which will allow you to test your website for CSRF problems. The tool allows you to create multi-step test cases and has been used to transfer funds, create accounts, issue checks, etc... The second tool is called CSRFGuard, and it's a Java EE filter that can be placed in front of an entire application to provide CSRF protection. CSRFGuard uses javascript to insert tokens into forms and links, and then validates the token in every request. You can find both free tools at http://www.owasp.org.; Especially the part about the filter. If it's compatible with wicket and a okay approach, I'd say forget about these things... Johan Compagner wrote: what i dont get if an attacker wants to submit the form. and it can get to the form it can do the post but you say it cant access the cookie. But if the cookie value is just compared to the form post value we have to make sure that the name of the cookie cant be guessed right? So what should the name be? Because if the name would be wicket-form-uuid then couldnt the attacker also just generate that cookie? I guess there is a cookie per form (there can be many forms on the same page or different active pages) and that cookie must be regenerated/set on every form render? johan On Mon, Oct 20, 2008 at 11:27 AM, Jörn Zaefferer [EMAIL PROTECTED] wrote: Hi, my application currently uses CryptedUrlWebRequestCodingStrategy to protect against CRSF attacks. Afaik 1.3.5 will include an update that generates the key based on user sessions: http://issues.apache.org/jira/browse/WICKET-1782 According to Johan Compagner, there are still issues with that approach, though I don't know if that has been fixed: http://www.nabble.com/Wicket-not-secure--to19556259.html#a19557593 Anyway, the point of this mail is to bring up a different strategy for CSRF protection, the double-submitted-cookie. Discussion of that are here http://www.codinghorror.com/blog/archives/001175.html which links to this article, including a whitepaper: http://freedom-to-tinker.com/blog/wzeller/popular-websites-vulnerable-cross-site-request-forgery-attacks The basic idea is: When a user visits a site, the site should generate a (cryptographically strong) pseudorandom value and set it as a cookie on the user's machine. The site should require every form submission to include this pseudorandom value as a form value and also as a cookie value. When a POST request is sent to the site, the request should only be considered valid if the form value and the cookie value are the same. When an attacker submits a form on behalf of a user, he can only modify the values of the form. An attacker cannot read any data sent from the server or modify cookie values, per the same-origin policy. This means that while an attacker can send any value he wants with the form, he will be unable to modify or read the value stored in the cookie. Since the cookie value and the form value must be the same, the attacker will be unable to successfully submit a form unless he is able to guess the pseudorandom value. For Wicket, this would mean: Generate a pseudorandom value and set is as a session cookie, when the cookie doesn't yet exist. Insert a hidden input into each form with the generated value. Validate that the value equals the cookie when submitting a form. The input and validation can be abstracted into a Form subclass (or even add it to Wicket's Form class...). That really easy to implement, is much more efficient (generate only one value per user/browser session, store it on the client, not the server) and is now the most common strategy to protect against CSRF attacks. I've read a lot about CSRF, and this strategy seems the only one both easy enough to implement and without holes. What do you think? Should Wicket support that out-of-the-box? Jörn -- -Wicket for love Nino
Re: Pages or components... how do u decide?
The only markup difference between pages and panels for me is that panels use wicket:panel and pages use wicket:extend. Making that the same, I'd prefer wicket:extend, would make it even easier to switch from a page to a panel and back. Jörn On Mon, Oct 20, 2008 at 10:22 AM, Ned Collyer [EMAIL PROTECTED] wrote: I use those annotations - they are awesome :) If you could annotate a panel to be bookmarkable.. that'd be interesting. So the panel COULD be embeded into other components, or used standalone as a page. Currently I achieve this by creating a new page class which instantiates and passes the panel to the super. Anyway, i thought it was an interesting thing to discuss. Jörn Zaefferer-2 wrote: A URL is quite a strong argument for using pages. With the wicket-annotations project its dead-easy to make pages bookmarkable, just add @MountPath(path=/path/to/page). Jörn -- View this message in context: http://www.nabble.com/Pages-or-components...-how-do-u-decide--tp20016807p20065174.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: @MountPath with same path
How about mounting that to just products and displaying different
content based on the presence of the parameter? You abstract the
content of both pages into panels and show one or the other based on
the paramter.
Jörn
On Mon, Oct 20, 2008 at 6:15 PM, Cédric Thiébault
[EMAIL PROTECTED] wrote:
Hi,
I want to use REST url for my application using wicketstuff-annotation
but it seems that I can't use the same path for 2 pages.
For example :
- /products for the list of products
@MountPath(path = products)
public class ProductListPage extends Webpage
- /products/5 for the detail of product with id=5.
@MountPath(path = products)
@MountMixedParam(parameterNames = { id })
public class ProductDetailPage extends Webpage
It throws an WicketRuntimeException: its is already mounted for
BookmarkablePageEncoder on start up.
I tried to use the patch described in
https://issues.apache.org/jira/browse/WICKET-1534 but it goes to first
page with this path (ie /products displays the product detail page for
id=null).
I also tried:
- /products for the list of products
@MountPath(path = products)
public class ProductListPage extends Webpage
- /products/detail/5 for the detail of product with id=5.
@MountPath(path = products/detail)
@MountMixedParam(parameterNames = { id })
public class ProductDetailPage extends Webpage
but /products/detail/5 displays the list page because the list page
path is a subset of the detail page path.
Dis someone used this kind of urls with Wicket ?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: how to get bookmarkable-page-url in FeedResource
I'm using with in my Application subclass to mount the feed as implemented by MyFeedResource: getSharedResources().add(my-feed, new MyFeedResource()); mountSharedResource(/games/atom, new ResourceReference(my-feed).getSharedResourceKey()); And on my base page: add(FeedResource.autodiscoveryLink(new ResourceReference(games-feed))); Jörn On Tue, Oct 21, 2008 at 12:04 PM, Oliver Mahnke [EMAIL PROTECTED] wrote: Hi, i am trying to show links to bookmarkable pages in a news feed using FeedResource from wicketstuff-rome. I can't get it to work because i don't know the urls. I tried to use BookmarkablePageLink, but this fails in the FeedResource because the link is not attached to any page. Thanks for any advice! Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: inmethod / grid website?
I second that, please get the site fixed! Jörn On Tue, Oct 21, 2008 at 12:27 PM, Martin Voigt [EMAIL PROTECTED] wrote: Yea, was just that it's Matej who did the grid stuff (at least to my knowledge), so I thought it would make sense to ask it here, as I'm sure I'm not the only one using grid ;) Regards, Martin 2008/10/21 Robby O'Connor [EMAIL PROTECTED]: They may have screwed up their context descriptor or perhaps just didn't deploy it? Best bet would be email their tech contect (see domain name whois for info.) --rob Martin Voigt wrote: Hi, this may be the wrong place to ask, but anyways. What happened to the inmethod/ grid web site? http://www.inmethod.com/ is showing the tomcat welcome page for some time now. Did it move? Regards, Martin - 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: @MountPath with same path
Thats the type of problem where you fight against a basic design
descision. Happens a lot with Hibernate, too, and you always lose one
way or the other...
Jörn
On Tue, Oct 21, 2008 at 5:04 PM, Cédric Thiébault
[EMAIL PROTECTED] wrote:
Jörn
Yes I could do something like that but I don't really like the idea of
a unique page that dispatch to panels depending on parameters...
David
It throws the same exception with @MountIndexedHybrid:
org.apache.wicket.WicketRuntimeException: products is already mounted
for HybridUrlCodingStrategy
I tried to do it without annotations and I have exactly the same
problems (hopefully):
mountBookmarkablePage(products, ProductListPage.class);
mount(new IndexedHybridUrlCodingStrategy(products,
ProductDetailPage.class));
Cedric
On Mon, Oct 20, 2008 at 5:46 PM, David Leangen [EMAIL PROTECTED] wrote:
You can use IndexedHybridUrlCodingStrategy (or something like that...
currently writing from [my poor] memory).
Cheers,
=dml
-Original Message-
From: Jorn Zaefferer [mailto:[EMAIL PROTECTED]
Sent: 21 October 2008 06:33
To: users@wicket.apache.org
Subject: Re: @MountPath with same path
How about mounting that to just products and displaying different
content based on the presence of the parameter? You abstract the
content of both pages into panels and show one or the other based on
the paramter.
Jörn
On Mon, Oct 20, 2008 at 6:15 PM, Cédric Thiébault
[EMAIL PROTECTED] wrote:
Hi,
I want to use REST url for my application using wicketstuff-annotation
but it seems that I can't use the same path for 2 pages.
For example :
- /products for the list of products
@MountPath(path = products)
public class ProductListPage extends Webpage
- /products/5 for the detail of product with id=5.
@MountPath(path = products)
@MountMixedParam(parameterNames = { id })
public class ProductDetailPage extends Webpage
It throws an WicketRuntimeException: its is already mounted for
BookmarkablePageEncoder on start up.
I tried to use the patch described in
https://issues.apache.org/jira/browse/WICKET-1534 but it goes to first
page with this path (ie /products displays the product detail page for
id=null).
I also tried:
- /products for the list of products
@MountPath(path = products)
public class ProductListPage extends Webpage
- /products/detail/5 for the detail of product with id=5.
@MountPath(path = products/detail)
@MountMixedParam(parameterNames = { id })
public class ProductDetailPage extends Webpage
but /products/detail/5 displays the list page because the list page
path is a subset of the detail page path.
Dis someone used this kind of urls with Wicket ?
-
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: CSRF Protection: double submitted cookie
I've created a ticket and attached a reference implementation: https://issues.apache.org/jira/browse/WICKET-1885 Jörn On Mon, Oct 20, 2008 at 11:31 PM, Jörn Zaefferer [EMAIL PROTECTED] wrote: The double-submitted-cookie isn't related to double submit protection, no. Thats a completely different turf. With that out of the way, its enough to create just one cookie and use that both while rendering and validating forms. I hope that makes it clearer. I'll try to provide a reference implementation tomorrow. Jörn On Mon, Oct 20, 2008 at 12:58 PM, Johan Compagner [EMAIL PROTECTED] wrote: hmm i will read the paper then I stil dont get it how it is possible with 1 cookie, that then can never change when it is first generated and all the forms also just have that value right? But it is also for double submit protection right? So the cookie has to change right? But how can you then have 1 cookie? for all the forms? If i submit one and that is rerendered or redirected to another page. (so it has a new cookie so the double submit cant happen) But if a new cookie is set then all other forms are also suddenly invalid.. and that looks pretty wrong to me johan On Mon, Oct 20, 2008 at 12:44 PM, Jörn Zaefferer [EMAIL PROTECTED] wrote: No, the cookie is subject to the same-origin-policy, both in reading and writing. The request is authenticated because the session cookie is set, but its invalid when the form itself is missing the value. Combining the attack with XSS would give access to the cookie, but then he could just as well hijack the session directly. In other words: With CSRF alone there is no way for the attacker to read the cookie, therefore its enough to use just one. Their whitepaper may do a better job of explaining the techniquie: http://www.freedom-to-tinker.com/sites/default/files/csrf.pdf Solutions are described on page 8ff. Jörn On Mon, Oct 20, 2008 at 12:33 PM, Johan Compagner [EMAIL PROTECTED] wrote: what i dont get if an attacker wants to submit the form. and it can get to the form it can do the post but you say it cant access the cookie. But if the cookie value is just compared to the form post value we have to make sure that the name of the cookie cant be guessed right? So what should the name be? Because if the name would be wicket-form-uuid then couldnt the attacker also just generate that cookie? I guess there is a cookie per form (there can be many forms on the same page or different active pages) and that cookie must be regenerated/set on every form render? johan On Mon, Oct 20, 2008 at 11:27 AM, Jörn Zaefferer [EMAIL PROTECTED] wrote: Hi, my application currently uses CryptedUrlWebRequestCodingStrategy to protect against CRSF attacks. Afaik 1.3.5 will include an update that generates the key based on user sessions: http://issues.apache.org/jira/browse/WICKET-1782 According to Johan Compagner, there are still issues with that approach, though I don't know if that has been fixed: http://www.nabble.com/Wicket-not-secure--to19556259.html#a19557593 Anyway, the point of this mail is to bring up a different strategy for CSRF protection, the double-submitted-cookie. Discussion of that are here http://www.codinghorror.com/blog/archives/001175.html which links to this article, including a whitepaper: http://freedom-to-tinker.com/blog/wzeller/popular-websites-vulnerable-cross-site-request-forgery-attacks The basic idea is: When a user visits a site, the site should generate a (cryptographically strong) pseudorandom value and set it as a cookie on the user's machine. The site should require every form submission to include this pseudorandom value as a form value and also as a cookie value. When a POST request is sent to the site, the request should only be considered valid if the form value and the cookie value are the same. When an attacker submits a form on behalf of a user, he can only modify the values of the form. An attacker cannot read any data sent from the server or modify cookie values, per the same-origin policy. This means that while an attacker can send any value he wants with the form, he will be unable to modify or read the value stored in the cookie. Since the cookie value and the form value must be the same, the attacker will be unable to successfully submit a form unless he is able to guess the pseudorandom value. For Wicket, this would mean: Generate a pseudorandom value and set is as a session cookie, when the cookie doesn't yet exist. Insert a hidden input into each form with the generated value. Validate that the value equals the cookie when submitting a form. The input and validation can be abstracted into a Form subclass (or even add it to Wicket's Form class...). That really easy to implement, is much more efficient (generate only one value per user/browser session, store it on the client
Render a Wicket page to a string for HTML email
Hi, I've found this article on how to render a page to a String: http://www.danwalmsley.com/2008/10/21/render-a-wicket-page-to-a-string-for-html-email/ It seemed to be exactly what I was looking for. Copying the code into my app, I got a compiler error on the line where the WebRequest is created. Using the constructor to ServletWebRequest helped. Nonetheless, I get only an empty string back, no clue whats going wrong. I'm using Wicket 1.3.5. Any ideas? Jörn
Re: Render a Wicket page to a string for HTML email
No voodoo neccessary, got it working:
protected String renderPage(Class? extends Page pageClass,
PageParameters pageParameters) {
//get the servlet context
WebApplication application = (WebApplication)
WebApplication.get();
ServletContext context = application.getServletContext();
//fake a request/response cycle
MockHttpSession servletSession = new MockHttpSession(context);
servletSession.setTemporary(true);
MockHttpServletRequest servletRequest = new
MockHttpServletRequest(
application, servletSession, context);
MockHttpServletResponse servletResponse = new
MockHttpServletResponse(
servletRequest);
//initialize request and response
servletRequest.initialize();
servletResponse.initialize();
WebRequest webRequest = new ServletWebRequest(servletRequest);
BufferedWebResponse webResponse = new
BufferedWebResponse(servletResponse);
webResponse.setAjax(true);
WebRequestCycle requestCycle = new WebRequestCycle(
application, webRequest, webResponse);
requestCycle.setRequestTarget(new
BookmarkablePageRequestTarget(pageClass, pageParameters));
try {
requestCycle.getProcessor().respond(requestCycle);
log.warn(Response after request:
+webResponse.toString());
if (requestCycle.wasHandled() == false) {
requestCycle.setRequestTarget(new
WebErrorCodeResponseTarget(
HttpServletResponse.SC_NOT_FOUND));
}
requestCycle.detach();
} finally {
requestCycle.getResponse().close();
}
return webResponse.toString();
}
Does it make sense to put this in a ticket to request it for Wicket 1.5?
Jörn
On Tue, Nov 4, 2008 at 5:55 PM, Martijn Dashorst
[EMAIL PROTECTED] wrote:
Are you in New Orleans in some voodoo bar? Why not join us at ApacheCon? :)
Martijn
On Tue, Nov 4, 2008 at 10:43 AM, Igor Vaynberg [EMAIL PROTECTED] wrote:
without seeing your code we have to resort to waving a dead chicken in
front of our screens or making swags.
-igor
On Tue, Nov 4, 2008 at 9:19 AM, Jörn Zaefferer
[EMAIL PROTECTED] wrote:
Hi,
I've found this article on how to render a page to a String:
http://www.danwalmsley.com/2008/10/21/render-a-wicket-page-to-a-string-for-html-email/
It seemed to be exactly what I was looking for. Copying the code into
my app, I got a compiler error on the line where the WebRequest is
created. Using the constructor to ServletWebRequest helped.
Nonetheless, I get only an empty string back, no clue whats going wrong.
I'm using Wicket 1.3.5.
Any ideas?
Jörn
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.4 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCE] Apache Wicket 1.4 release candidate 1
The following subprojects are incompatible with Wicket 1.4 RC1 and therefore block us from migrating: wicket-ioc (only 1.3.5 available) and wicket-spring-annot (only 1.3.5 available). wicket-spring-annot needs to change its usage of MetaDataKey in SpringComponentInjector (constructor doesn't accept any arguments anymore) and wicket-ioc needs to be recompiled using the JDK's ConcurrentHashMap instead of wicket.util.concurrent. Jörn On Thu, Nov 13, 2008 at 3:06 PM, Frank Bille [EMAIL PROTECTED] wrote: The Apache Wicket team is proud to present the first release candidate of Apache Wicket 1.4. This is the first Wicket version with java 1.5 as minimum requirement. Eager people click here to download the distribution, others can read further: * http://www.apache.org/dyn/closer.cgi/wicket/1.4-rc1 We thank you for your patience and support. The Wicket Team - Apache Wicket Apache Wicket is a component oriented Java web application framework. With proper mark-up/logic separation, a POJO data model, and a refreshing lack of XML, Apache Wicket makes developing web-apps simple and enjoyable again. Swap the boilerplate, complex debugging and brittle code for powerful, reusable components written with plain Java and HTML. You can find out more about Apache Wicket on our website: * http://wicket.apache.org - This release The Apache Wicket team is proud to announce the availability of the third milestone release of our first java 1.5 Wicket version: Apache Wicket 1.4-m3. This is the first release with java 1.5 as a minimum. Almost everything has been converted to java 1.5. If you find something missing, please help us and send a message to the dev@ or user@ list. - Migrating from 1.3 If you are coming from Wicket 1.3, you really want to read our migration guide, found on the wiki: * http://cwiki.apache.org/WICKET/migrate-14.html h3. Downloading the release You can download the release from the official Apache mirror system, and you can find it through the following link: * http://www.apache.org/dyn/closer.cgi/wicket/1.4-rc1/ For the Maven and Ivy fans out there: update your pom's to the following, and everything will be downloaded automatically: dependency groupIdorg.apache.wicket/groupId artifactIdwicket/artifactId version1.4-rc1/version /dependency Substitute the artifact ID with the projects of your liking to get the other projects. Please note that we don't prescribe a Logging implementation for SLF4J. You need to specify yourself which one you prefer. Read more about SLF4J here: http://slf4j.org - Validating the release The release has been signed by Frank Bille, your release manager for today. The public key can be found in the KEYS file in the download area. Download the KEYS file only from the Apache website. * http://www.apache.org/dist/wicket/1.4-rc1/KEYS Instructions on how to validate the release can be found here: * http://www.apache.org/dev/release-signing.html#check-integrity - Reporting bugs In case you do encounter a bug, we would appreciate a report in our JIRA: * http://issues.apache.org/jira/browse/WICKET - The distribution In the distribution you will find a README. The README contains instructions on how to build from source yourself. You also find a CHANEGELOG-1.4 which contains a list of all things that have been fixed, added and/or removed since the first release in the 1.4 branch. - Release Notes - Wicket - Version 1.4-RC1 ** Sub-task * [WICKET-1624] - ServletWebRequest.getRelativePathPrefixToContextRoot() double decodes servlet path * [WICKET-1805] - Allow to change charset in StringRequestTarget: change CharSet used by the OutStream as well ** Bug * [WICKET-550] - Use WebRequestEncoder everywhere a query string is constructed * [WICKET-861] - NumberFormatException with UrlCompressingWebRequestProcessor in WicketTester * [WICKET-1120] - Problem closing a ModalWindow when used through an IFrame * [WICKET-1180] - Converters : final vs non final * [WICKET-1220] - Component.visitParents visits the calling component as well * [WICKET-1311] - Improper HTML escaping for most wicket components and extensions * [WICKET-1376] - Using AbstractAjaxTimerBehavior and mounting that page gives exception * [WICKET-1425] - appendToInit() method is not called in class DatePicker * [WICKET-1436] - Unable to use properties file when generating XML files * [WICKET-1496] - DataTable.html does not validate (HTML 4.01/XHTML-Strict) * [WICKET-1535] - ExternalLink JavaScript not working in FF 3 * [WICKET-1565] - AbstractTransformerBehavior can't be added to a page * [WICKET-1582] - WicketTester executeAjaxEvent onclick generating non-AJAX response * [WICKET-1583] - NPE in EnclosureResolver * [WICKET-1627] - AbstractRequestTargetUrlCodingStrategy improper user of URLEncoder.encode * [WICKET-1634] - ClassName needs conversion from Path
Re: [ANNOUNCE] Apache Wicket 1.4 release candidate 1
Sorry, I didn't. Looks like its all there, thanks! Jörn On Thu, Nov 13, 2008 at 6:20 PM, Martijn Dashorst [EMAIL PROTECTED] wrote: Did you read the migration guide? Martijn On Thu, Nov 13, 2008 at 5:49 PM, Jörn Zaefferer [EMAIL PROTECTED] wrote: The following subprojects are incompatible with Wicket 1.4 RC1 and therefore block us from migrating: wicket-ioc (only 1.3.5 available) and wicket-spring-annot (only 1.3.5 available). wicket-spring-annot needs to change its usage of MetaDataKey in SpringComponentInjector (constructor doesn't accept any arguments anymore) and wicket-ioc needs to be recompiled using the JDK's ConcurrentHashMap instead of wicket.util.concurrent. Jörn On Thu, Nov 13, 2008 at 3:06 PM, Frank Bille [EMAIL PROTECTED] wrote: The Apache Wicket team is proud to present the first release candidate of Apache Wicket 1.4. This is the first Wicket version with java 1.5 as minimum requirement. Eager people click here to download the distribution, others can read further: * http://www.apache.org/dyn/closer.cgi/wicket/1.4-rc1 We thank you for your patience and support. The Wicket Team - Apache Wicket Apache Wicket is a component oriented Java web application framework. With proper mark-up/logic separation, a POJO data model, and a refreshing lack of XML, Apache Wicket makes developing web-apps simple and enjoyable again. Swap the boilerplate, complex debugging and brittle code for powerful, reusable components written with plain Java and HTML. You can find out more about Apache Wicket on our website: * http://wicket.apache.org - This release The Apache Wicket team is proud to announce the availability of the third milestone release of our first java 1.5 Wicket version: Apache Wicket 1.4-m3. This is the first release with java 1.5 as a minimum. Almost everything has been converted to java 1.5. If you find something missing, please help us and send a message to the dev@ or user@ list. - Migrating from 1.3 If you are coming from Wicket 1.3, you really want to read our migration guide, found on the wiki: * http://cwiki.apache.org/WICKET/migrate-14.html h3. Downloading the release You can download the release from the official Apache mirror system, and you can find it through the following link: * http://www.apache.org/dyn/closer.cgi/wicket/1.4-rc1/ For the Maven and Ivy fans out there: update your pom's to the following, and everything will be downloaded automatically: dependency groupIdorg.apache.wicket/groupId artifactIdwicket/artifactId version1.4-rc1/version /dependency Substitute the artifact ID with the projects of your liking to get the other projects. Please note that we don't prescribe a Logging implementation for SLF4J. You need to specify yourself which one you prefer. Read more about SLF4J here: http://slf4j.org - Validating the release The release has been signed by Frank Bille, your release manager for today. The public key can be found in the KEYS file in the download area. Download the KEYS file only from the Apache website. * http://www.apache.org/dist/wicket/1.4-rc1/KEYS Instructions on how to validate the release can be found here: * http://www.apache.org/dev/release-signing.html#check-integrity - Reporting bugs In case you do encounter a bug, we would appreciate a report in our JIRA: * http://issues.apache.org/jira/browse/WICKET - The distribution In the distribution you will find a README. The README contains instructions on how to build from source yourself. You also find a CHANEGELOG-1.4 which contains a list of all things that have been fixed, added and/or removed since the first release in the 1.4 branch. - Release Notes - Wicket - Version 1.4-RC1 ** Sub-task * [WICKET-1624] - ServletWebRequest.getRelativePathPrefixToContextRoot() double decodes servlet path * [WICKET-1805] - Allow to change charset in StringRequestTarget: change CharSet used by the OutStream as well ** Bug * [WICKET-550] - Use WebRequestEncoder everywhere a query string is constructed * [WICKET-861] - NumberFormatException with UrlCompressingWebRequestProcessor in WicketTester * [WICKET-1120] - Problem closing a ModalWindow when used through an IFrame * [WICKET-1180] - Converters : final vs non final * [WICKET-1220] - Component.visitParents visits the calling component as well * [WICKET-1311] - Improper HTML escaping for most wicket components and extensions * [WICKET-1376] - Using AbstractAjaxTimerBehavior and mounting that page gives exception * [WICKET-1425] - appendToInit() method is not called in class DatePicker * [WICKET-1436] - Unable to use properties file when generating XML files * [WICKET-1496] - DataTable.html does not validate (HTML 4.01/XHTML-Strict) * [WICKET-1535] - ExternalLink JavaScript not working in FF 3 * [WICKET-1565] - AbstractTransformerBehavior can't be added to a page * [WICKET-1582
Re: Loosing page parameters after submit
That's how it is isn't really that much helpful, there's always a
workaround, isn't there?
In thise case, saving the pageparameters in the form constructor and
using them to set the response page onSubmit helps. Something like
this:
class MyForm extends Form {
private PageParameters pageParameters;
public MyForm() {
pageParameters = RequestCycle.get().getPageParameters();
// other stuff
}
public void onSubmit() {
// other stuff
setResponsePage(getPage().getClass(), pageParameters);
}
}
I guess there is a better solution, but at least it works in this case.
Jörn
On Mon, Nov 17, 2008 at 5:53 PM, Igor Vaynberg [EMAIL PROTECTED] wrote:
your complaint is not that you are losing page parameters, but that
you are losing the url. thats just how wicket works...
-igor
On Mon, Nov 17, 2008 at 12:40 AM, Enes Fazli [EMAIL PROTECTED] wrote:
Hello everybody,
following situation:
I have a comment panel with a form and a paging navigator to show the
comments. I implemented a own version of the PagingNavigator which uses
BookmarkablePageLinks for navigation links. Now, if i use this panel in a
page that has this url *http://localhost/sample//test/* the link to the
second page of the PagingNavigator has a url according to that *
http://localhost/sample//test/?commentspage=2*
If I now submit a comment the url to the second page of the PagingNavigator
changes to: *https://localhost:8443/sample/?commentspage=2
*My workaround at the moment is to set the response page in the form's
submit to the sample page with it's parameters. But I would have to do it
for every submitting panel in that page. I hope someone can give me a hint
on to why I lose the page parameters on submit.*
*
*For the sake of completeness:*
The page in which the Panel is embedded is mounted with a custom
UrlCodingStrategy which is a non versioned HybridUrlCodingStrategy extended
with the possibility to add mixed parameters.
I already tried other UrlCodingStrategies but that changed nothing.
Thanks,
Enes
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Announcing: Scala-Wicket Extensions Project
Hi Antony, is there a website for the project with some documentation? You mention the specification files, but those aren't included in the SNAPSHOT release. So all I have are some not-so-useful SDocs, your hints here and a link to http://technically.us/code/x/the-escape-hatch, which doesn't help either. Also, when looking at the source files I see a lot of ⇒ icons, which my Eclipse just displays as a little rectangle. That makes it somewhat difficult to use those - could you stick with an ASCII charset? Jörn On Fri, Aug 14, 2009 at 6:53 PM, Antony Stubbsantony.stu...@gmail.com wrote: Hello People, Today, I am proud to announce that I have now uploaded the first version of the new Scala-Wicket Extensions. The project aims to be a central point for Scala related extensions to the Wicket framework. At the moment, the project consists of an Archetype, Sample application and Core libraries. The core libraries at this point consist of some useful implicit conversation functions (Scala - Java list conversion, Closure - Fodel conversion, etc... ScalaWicket.scala) a collection of simple extensions to existing components and the Fodel class. The Fodel class allows us to use closures and pass by name parameters in Scala to avoid some explicit construction of Models. For example: new SLabel(name, person.name ) This actually constructs a Model which just like a Property Model looks up and re-evaluates the name property of the Person during each render time (i.e. this is a dynamic model, not a static model as it may appear to be, or would be if it were Java). Also: new SPropertyListView[String](presentations, list, _.add(new SLabel(name, asdp name))) There are a whole lot of examples in the Specification files, as the whole library as it stands is covered by Specs unit tests. It also includes SBT (simple build tool) code AND Maven build code (take your pick). I invite all those who are currently using Scala with Wicket to submit there odds and ends that make life easy for them - I'm sure there's a whole bunch of stuff out there! Special thanks to Stuq.nl P.s. it seems wicketstuff team city is stuck, so the SNAPSHOT won't be on the Wicket Stuff repo atm, but I'll try and get that sorted out asap. Maven signature: dependency groupIdorg.wicketstuff.scala/groupId artifactIdwicket-scala/artifactId version1.4-SNAPSHOT/version /dependency Cheers, Antony Stubbs, sharca.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [announce] wicket 1.4.x branched
Is this the right place to look for planned features for 1.5? http://cwiki.apache.org/WICKET/wicket-15-wish-list.html Jörn On Thu, Aug 20, 2009 at 5:10 PM, Igor Vaynbergigor.vaynb...@gmail.com wrote: Wicket 1.4.x has been branched and now lives in https://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.x Trunk is now what will become 1.5.0. Trunk may be broken in the early days of development and contain a lot of API breaks, so if you are following bleeding edge you may want to do so on the 1.4.x branch for a while. -igor - 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
Re: [announce] wicket 1.4.x branched
So, where do you plan what you'll actually build? Jörn On Fri, Aug 28, 2009 at 1:17 AM, Igor Vaynbergigor.vaynb...@gmail.com wrote: thats the right place to look for users want, not for what we are going to build. -igor On Thu, Aug 27, 2009 at 3:53 PM, Jörn Zaeffererjoern.zaeffe...@googlemail.com wrote: Is this the right place to look for planned features for 1.5? http://cwiki.apache.org/WICKET/wicket-15-wish-list.html Jörn On Thu, Aug 20, 2009 at 5:10 PM, Igor Vaynbergigor.vaynb...@gmail.com wrote: Wicket 1.4.x has been branched and now lives in https://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.x Trunk is now what will become 1.5.0. Trunk may be broken in the early days of development and contain a lot of API breaks, so if you are following bleeding edge you may want to do so on the 1.4.x branch for a while. -igor - 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 - 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
Re: Wicket Stuff Core 1.4.1 Release[ing]
So jquery-parent was build, which just references jquery and jquery-examples - neither of which were build. Whats the point of that? Also, how can we get wicketstuff-merged-resources included in the next release? Jörn On Mon, Aug 31, 2009 at 10:20 PM, Jeremy Thomersonjer...@wickettraining.com wrote: I have the credentials and think that I will definitely be trying this on the next release :) -- Jeremy Thomerson http://www.wickettraining.com On Mon, Aug 31, 2009 at 3:16 PM, Martijn Dashorst martijn.dasho...@gmail.com wrote: Perhaps it's more beneficial to do the actual release local on the machine? I'm sure Johan can provide you with the credentials to do so. Martijn On Mon, Aug 31, 2009 at 9:27 PM, Jeremy Thomersonjer...@wickettraining.com wrote: It's mostly uploading and then merging the POMs on the remote server. The build isn't actually that bad (maybe 15 or 20 minutes for the release procedure, including tagging, etc). -- Jeremy Thomerson http://www.wickettraining.com On Mon, Aug 31, 2009 at 2:14 PM, Nicolas Melendez nmelen...@getsense.com.ar wrote: very slow build :) On Mon, Aug 31, 2009 at 9:07 PM, Jeremy Thomersonjer...@wickettraining.com wrote: Wicket Stuff Core 1.4.1 is now released: [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 204 minutes 20 seconds [INFO] Finished at: Mon Aug 31 14:04:09 CDT 2009 [INFO] Final Memory: 218M/929M [INFO] -- Jeremy Thomerson http://www.wickettraining.com On Mon, Aug 31, 2009 at 10:38 AM, Jeremy Thomerson jer...@wickettraining.com wrote: That was only in the event that we really needed an interim release. The plan still is that we will release to match Wicket releases. PS - I have to try to start the deploy over again: [INFO] Retrieving previous metadata from wicketstuff-org-maven [INFO] Uploading repository metadata for: 'artifact org.wicketstuff:sitemap-xml' [INFO] Uploading project information for sitemap-xml 1.4.1 Uploading: scpexe:// wicketstuff.org/home/wicket/tomcat/webapps/maven/repository/org/wicketstuff/sitemap-xml/1.4.1/sitemap-xml-1.4.1-sources.jar [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error deploying artifact: Error executing command for transfer Exit code 255 - Write failed: Connection timed out [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 601 minutes 35 seconds [INFO] Finished at: Mon Aug 31 10:33:31 CDT 2009 [INFO] Final Memory: 221M/902M [INFO] [INFO] [ERROR] BUILD ERROR -- Jeremy Thomerson http://www.wickettraining.com On Mon, Aug 31, 2009 at 3:36 AM, Maarten Bosteels mbosteels@gmail.com wrote: Hi Jeremy, Great to see another release of Wicket Stuff Core !! Some weeks ago you suggested : I think that the best solution is that we have 1.4.1.X where X is our release number. Did you change your mind about this ? http://www.mail-archive.com/users@wicket.apache.org/msg40780.html Regards, Maarten On Mon, Aug 31, 2009 at 8:03 AM, Jeremy Thomerson jer...@wickettraining.com wrote: I successfully built Wicket Stuff Core 1.4.1 today. It is in the (very very slow) process of doing a release:perform (currently uploading all of the necessary files to wicketstuff repo). Hopefully by the time you read this, your project will be available as 1.4.1. Here are a couple that seem to have already made it up: http://wicketstuff.org/maven/repository/org/wicketstuff/wicketstuff-core/1.4.1/ http://wicketstuff.org/maven/repository/org/wicketstuff/gmap2/1.4.1/ http://wicketstuff.org/maven/repository/org/wicketstuff/calendarviews-parent/1.4.1/ -- Jeremy Thomerson http://www.wickettraining.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe,
Generate markup for hidden framework form field?
Hi,
my application uses a form subclass everywhere for CSRF protection.
Each form needs a hidden field like this: input type=hidden
wicket:id=csrf-protection /
The wicket component for that is added by the form subclass
(SecureForm) which all other forms in the application extend.
Currently each form has to include that markup somewhere, producing a
lot of duplication.
I'm looking for a way to get rid of that duplication. An approach I'm
currently investigating is to generate the markup, similar to how Form
genrates a hidden input it its onComponentTagBody:
@Override
protected void onComponentTagBody(MarkupStream markupStream,
ComponentTag openTag) {
String nameAndId = get(csrf-protection).getId();
AppendingStringBuffer buffer = new AppendingStringBuffer(
input type=\hidden\ name=\).append(nameAndId).append(\ /);
getResponse().write(buffer);
super.onComponentTagBody(markupStream, openTag);
}
That doesn't work, Wicket throws an exception of a missing reference
in markup anyway. Likely because this just writes to the response, not
extending the markup.
I also don't see any way to achieve this via MarkupStream or ComponentTag.
Any ideas?
Regards
Jörn Zaefferer
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
How to test for a redirect after form submit, eg. setting RedirectRequestTarget?
Hi, in one of my Wicket unit tests I'd like to assert that after a successful submit, a RedirectRequestTarget was set. Its not even necessary to check the exact URL of that redirect, just that it happens. I can't find any support for that via WicketTester, and RequestCycle.get().getRequestTarget() (or accessed via tester.getLastRenderedPage().getRequestCycle().getRequestTarget()) returns null. Any ideas? Regards Jörn Zaefferer - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Generate markup for hidden framework form field?
That was the idea. But Wicket still can't find the component markup
when looking for it. The form adds this elsewhere:
add(new HiddenFieldString(csrf-protection, new
ModelString(csrfProtection())).setRequired(true).add(new
IValidatorString() {
public void validate(IValidatableString validatable) {
log.warn(potential csrf attack, submitted value: +
validatable.getValue() + , expected: + csrfProtection());
validatable.error(new ValidationError().setMessage(wrong csrf
protection cookie));
}
}));
Jörn
On Mon, May 25, 2009 at 5:44 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote:
if you write it out in oncomponenttagbody then you dont need it in the
markupo anymore.
-igor
On Mon, May 25, 2009 at 6:32 AM, Jörn Zaefferer
joern.zaeffe...@googlemail.com wrote:
Hi,
my application uses a form subclass everywhere for CSRF protection.
Each form needs a hidden field like this: input type=hidden
wicket:id=csrf-protection /
The wicket component for that is added by the form subclass
(SecureForm) which all other forms in the application extend.
Currently each form has to include that markup somewhere, producing a
lot of duplication.
I'm looking for a way to get rid of that duplication. An approach I'm
currently investigating is to generate the markup, similar to how Form
genrates a hidden input it its onComponentTagBody:
@Override
protected void onComponentTagBody(MarkupStream markupStream,
ComponentTag openTag) {
String nameAndId = get(csrf-protection).getId();
AppendingStringBuffer buffer = new AppendingStringBuffer(
input type=\hidden\ name=\).append(nameAndId).append(\ /);
getResponse().write(buffer);
super.onComponentTagBody(markupStream, openTag);
}
That doesn't work, Wicket throws an exception of a missing reference
in markup anyway. Likely because this just writes to the response, not
extending the markup.
I also don't see any way to achieve this via MarkupStream or ComponentTag.
Any ideas?
Regards
Jörn Zaefferer
-
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
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Generate markup for hidden framework form field?
How is that going the fix the problem? I'd end up with markup, but no
behaviour on top of it.
Jörn
On Mon, May 25, 2009 at 5:52 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote:
right, so remove that code since you have replaced that component with
pure markup.
-igor
On Mon, May 25, 2009 at 8:48 AM, Jörn Zaefferer
joern.zaeffe...@googlemail.com wrote:
That was the idea. But Wicket still can't find the component markup
when looking for it. The form adds this elsewhere:
add(new HiddenFieldString(csrf-protection, new
ModelString(csrfProtection())).setRequired(true).add(new
IValidatorString() {
public void validate(IValidatableString validatable) {
log.warn(potential csrf attack, submitted value: +
validatable.getValue() + , expected: + csrfProtection());
validatable.error(new ValidationError().setMessage(wrong csrf
protection cookie));
}
}));
Jörn
On Mon, May 25, 2009 at 5:44 PM, Igor Vaynberg igor.vaynb...@gmail.com
wrote:
if you write it out in oncomponenttagbody then you dont need it in the
markupo anymore.
-igor
On Mon, May 25, 2009 at 6:32 AM, Jörn Zaefferer
joern.zaeffe...@googlemail.com wrote:
Hi,
my application uses a form subclass everywhere for CSRF protection.
Each form needs a hidden field like this: input type=hidden
wicket:id=csrf-protection /
The wicket component for that is added by the form subclass
(SecureForm) which all other forms in the application extend.
Currently each form has to include that markup somewhere, producing a
lot of duplication.
I'm looking for a way to get rid of that duplication. An approach I'm
currently investigating is to generate the markup, similar to how Form
genrates a hidden input it its onComponentTagBody:
@Override
protected void onComponentTagBody(MarkupStream markupStream,
ComponentTag openTag) {
String nameAndId = get(csrf-protection).getId();
AppendingStringBuffer buffer = new AppendingStringBuffer(
input type=\hidden\ name=\).append(nameAndId).append(\ /);
getResponse().write(buffer);
super.onComponentTagBody(markupStream, openTag);
}
That doesn't work, Wicket throws an exception of a missing reference
in markup anyway. Likely because this just writes to the response, not
extending the markup.
I also don't see any way to achieve this via MarkupStream or ComponentTag.
Any ideas?
Regards
Jörn Zaefferer
-
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
-
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
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Generate markup for hidden framework form field?
The current component (the HiddenField) checks that the same value
that it started with, is submitted. I'll try to replace that using a
form validator that reads the parameter directly.
Thanks
Jörn
On Tue, May 26, 2009 at 1:32 PM, Maarten Bosteels
mbosteels@gmail.com wrote:
When you write it out with oncomponenttagbody it's not part of the
component hierarchy, it's just rendered markup.
Once the form is submitted, you can retrieve the value using the servlet
API.
What behavior would you want to add on top ?
Maarten
On Tue, May 26, 2009 at 12:17 PM, Jörn Zaefferer
joern.zaeffe...@googlemail.com wrote:
How is that going the fix the problem? I'd end up with markup, but no
behaviour on top of it.
Jörn
On Mon, May 25, 2009 at 5:52 PM, Igor Vaynberg igor.vaynb...@gmail.com
wrote:
right, so remove that code since you have replaced that component with
pure markup.
-igor
On Mon, May 25, 2009 at 8:48 AM, Jörn Zaefferer
joern.zaeffe...@googlemail.com wrote:
That was the idea. But Wicket still can't find the component markup
when looking for it. The form adds this elsewhere:
add(new HiddenFieldString(csrf-protection, new
ModelString(csrfProtection())).setRequired(true).add(new
IValidatorString() {
public void validate(IValidatableString validatable) {
log.warn(potential csrf attack, submitted value: +
validatable.getValue() + , expected: + csrfProtection());
validatable.error(new ValidationError().setMessage(wrong
csrf
protection cookie));
}
}));
Jörn
On Mon, May 25, 2009 at 5:44 PM, Igor Vaynberg igor.vaynb...@gmail.com
wrote:
if you write it out in oncomponenttagbody then you dont need it in the
markupo anymore.
-igor
On Mon, May 25, 2009 at 6:32 AM, Jörn Zaefferer
joern.zaeffe...@googlemail.com wrote:
Hi,
my application uses a form subclass everywhere for CSRF protection.
Each form needs a hidden field like this: input type=hidden
wicket:id=csrf-protection /
The wicket component for that is added by the form subclass
(SecureForm) which all other forms in the application extend.
Currently each form has to include that markup somewhere, producing a
lot of duplication.
I'm looking for a way to get rid of that duplication. An approach I'm
currently investigating is to generate the markup, similar to how Form
genrates a hidden input it its onComponentTagBody:
@Override
protected void onComponentTagBody(MarkupStream markupStream,
ComponentTag openTag) {
String nameAndId = get(csrf-protection).getId();
AppendingStringBuffer buffer = new AppendingStringBuffer(
input type=\hidden\ name=\).append(nameAndId).append(\
/);
getResponse().write(buffer);
super.onComponentTagBody(markupStream, openTag);
}
That doesn't work, Wicket throws an exception of a missing reference
in markup anyway. Likely because this just writes to the response, not
extending the markup.
I also don't see any way to achieve this via MarkupStream or
ComponentTag.
Any ideas?
Regards
Jörn Zaefferer
-
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
-
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
-
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
Re: Generate markup for hidden framework form field?
Thanks guys! The end result looks like this, works fine, and removed a
lot of html boilderplate from our templates:
public SecureForm(String id, IModelT model) {
super(id, model);
setMarkupId(id);
add(new IFormValidator() {
@Override
public void validate(Form? form) {
String submitted =
getRequest().getParameter(csrf-protection);
if
(Application.get().getConfigurationType().equals(Application.DEPLOYMENT)
!csrfProtection().equals(submitted)) {
log.warn(potential csrf attack, submitted
value: + submitted +
, expected: + csrfProtection());
form.error(wrong csrf protection cookie);
}
}
@Override
public FormComponent?[] getDependentFormComponents() {
return null;
}
});
}
@Override
protected void onComponentTagBody(MarkupStream markupStream,
ComponentTag openTag) {
getResponse().write(new AppendingStringBuffer(input
type=\hidden\ name=\csrf-protection\
value=\).append(csrfProtection()).append(\ /));
super.onComponentTagBody(markupStream, openTag);
}
Jörn
On Tue, May 26, 2009 at 2:23 PM, Jörn Zaefferer
joern.zaeffe...@googlemail.com wrote:
The current component (the HiddenField) checks that the same value
that it started with, is submitted. I'll try to replace that using a
form validator that reads the parameter directly.
Thanks
Jörn
On Tue, May 26, 2009 at 1:32 PM, Maarten Bosteels
mbosteels@gmail.com wrote:
When you write it out with oncomponenttagbody it's not part of the
component hierarchy, it's just rendered markup.
Once the form is submitted, you can retrieve the value using the servlet
API.
What behavior would you want to add on top ?
Maarten
On Tue, May 26, 2009 at 12:17 PM, Jörn Zaefferer
joern.zaeffe...@googlemail.com wrote:
How is that going the fix the problem? I'd end up with markup, but no
behaviour on top of it.
Jörn
On Mon, May 25, 2009 at 5:52 PM, Igor Vaynberg igor.vaynb...@gmail.com
wrote:
right, so remove that code since you have replaced that component with
pure markup.
-igor
On Mon, May 25, 2009 at 8:48 AM, Jörn Zaefferer
joern.zaeffe...@googlemail.com wrote:
That was the idea. But Wicket still can't find the component markup
when looking for it. The form adds this elsewhere:
add(new HiddenFieldString(csrf-protection, new
ModelString(csrfProtection())).setRequired(true).add(new
IValidatorString() {
public void validate(IValidatableString validatable) {
log.warn(potential csrf attack, submitted value: +
validatable.getValue() + , expected: + csrfProtection());
validatable.error(new ValidationError().setMessage(wrong
csrf
protection cookie));
}
}));
Jörn
On Mon, May 25, 2009 at 5:44 PM, Igor Vaynberg igor.vaynb...@gmail.com
wrote:
if you write it out in oncomponenttagbody then you dont need it in the
markupo anymore.
-igor
On Mon, May 25, 2009 at 6:32 AM, Jörn Zaefferer
joern.zaeffe...@googlemail.com wrote:
Hi,
my application uses a form subclass everywhere for CSRF protection.
Each form needs a hidden field like this: input type=hidden
wicket:id=csrf-protection /
The wicket component for that is added by the form subclass
(SecureForm) which all other forms in the application extend.
Currently each form has to include that markup somewhere, producing a
lot of duplication.
I'm looking for a way to get rid of that duplication. An approach I'm
currently investigating is to generate the markup, similar to how Form
genrates a hidden input it its onComponentTagBody:
@Override
protected void onComponentTagBody(MarkupStream markupStream,
ComponentTag openTag) {
String nameAndId = get(csrf-protection).getId();
AppendingStringBuffer buffer = new AppendingStringBuffer(
input type=\hidden\ name=\).append(nameAndId).append(\
/);
getResponse().write(buffer);
super.onComponentTagBody(markupStream, openTag);
}
That doesn't work, Wicket throws an exception of a missing reference
in markup anyway. Likely because this just writes to the response, not
extending the markup.
I also don't see any way to achieve this via MarkupStream or
ComponentTag.
Any ideas?
Regards
Jörn Zaefferer
-
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
Re: How to test for a redirect after form submit, eg. setting RedirectRequestTarget?
Thanks Igor! After figuring out that onRequestTargetSet is called afterwards again with null as an argument (probably on closing the RequestCycle), it worked. Jörn On Tue, May 26, 2009 at 6:03 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: subclass requestcycle, override onrequesttargetset (may only be in 1.4) and set some flag when you see the redirect, or add it to some list you have visibility into. -igor On Mon, May 25, 2009 at 8:32 AM, Jörn Zaefferer joern.zaeffe...@googlemail.com wrote: Hi, in one of my Wicket unit tests I'd like to assert that after a successful submit, a RedirectRequestTarget was set. Its not even necessary to check the exact URL of that redirect, just that it happens. I can't find any support for that via WicketTester, and RequestCycle.get().getRequestTarget() (or accessed via tester.getLastRenderedPage().getRequestCycle().getRequestTarget()) returns null. Any ideas? Regards Jörn Zaefferer - 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Help us release 1.4 sooner by helping out with the migration guide
2350 cost us a lot of time, getting that fixed would be very very helpful. We have a lot of cases where similar fields are used in different forms... Jörn On Tue, Jul 14, 2009 at 3:47 AM, Igor Vaynbergigor.vaynb...@gmail.com wrote: thanks major, i added a couple of notes to the wiki. i totally forgot about 2350, i will get it into 1.4.0 for sure. -igor 2009/7/11 Major Péter majorpe...@sch.bme.hu: Hi, I have recently upgraded my project and I did find these changes: - the first parameter of org.apache.wicket.markup.html.tree.LinkTree#onNodeLinkClicked has been changed from TreeNode to Object, so if you had override this method, you need to change the parametertype. - localization messages for validations works only in form.component.validatorType=message format, the component.validatorType=message format isn't working anymore (but this could be change for final release - for further infos see: https://issues.apache.org/jira/browse/WICKET-2350 ) Besides this, I found in WebApplication#getConfigurationType a FIXME comment, so in theory the init-param's name for filter/servlet (or context-param) should be changed from configuration to wicket.configuration in final 1.4 release. (See: https://issues.apache.org/jira/browse/WICKET-1317 ) //Also many old component has been genericized, a list of these components would be helpful, (for example TextField, RequiredTF, and so on, if you follow these changes in your code, it would be easier to read next time) p.s: I would wrote this on wiki, but I know how bad my english is. :) Best Regards, Peter Major 2009-07-10 21:22 keltezéssel, Igor Vaynberg írta: We would like to release Wicket 1.4 very soon, but in order to do so we would like to provide our users with a good migration guide. We have started one here: http://cwiki.apache.org/confluence/display/WICKET/Migrate-1.4 but it probably lacks the smaller tweaks necessary to migrate. If you have recently migrated a project, or remember any changes you had to perform, or have any helpful tips or hints please add them to the migration guide. Do not worry about formatting, for now we are looking for content. If you do not want to bother putting them on the wiki simply add them to this thread. Thanks! -igor - 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Announcing: Scala-Wicket Extensions Project
Its not quite as good as the Java Tools, but it has come a long way: http://www.scala-lang.org/node/94 Jörn On Sat, Aug 15, 2009 at 1:14 PM, Martin Sachssachs.mar...@gmail.com wrote: Thanks for that variant of programming wicket-application! I like scala and its concepts, very much. Using scala with wicket would properbly make wicketapplications a little faster, more refactor-safe and better maintainable. Do you have good IDE for scala ? If the IDE (e.g. Plugin for eclipse) is as well as java-IDE, scala would be the better java. But without IDE, many enterprises wont use scala. Martin Antony Stubbs schrieb: Hello People, Today, I am proud to announce that I have now uploaded the first version of the new Scala-Wicket Extensions. The project aims to be a central point for Scala related extensions to the Wicket framework. At the moment, the project consists of an Archetype, Sample application and Core libraries. The core libraries at this point consist of some useful implicit conversation functions (Scala - Java list conversion, Closure - Fodel conversion, etc... ScalaWicket.scala) a collection of simple extensions to existing components and the Fodel class. The Fodel class allows us to use closures and pass by name parameters in Scala to avoid some explicit construction of Models. For example: new SLabel(name, person.name ) This actually constructs a Model which just like a Property Model looks up and re-evaluates the name property of the Person during each render time (i.e. this is a dynamic model, not a static model as it may appear to be, or would be if it were Java). Also: new SPropertyListView[String](presentations, list, _.add(new SLabel(name, asdp name))) There are a whole lot of examples in the Specification files, as the whole library as it stands is covered by Specs unit tests. It also includes SBT (simple build tool) code AND Maven build code (take your pick). I invite all those who are currently using Scala with Wicket to submit there odds and ends that make life easy for them - I'm sure there's a whole bunch of stuff out there! Special thanks to Stuq.nl P.s. it seems wicketstuff team city is stuck, so the SNAPSHOT won't be on the Wicket Stuff repo atm, but I'll try and get that sorted out asap. Maven signature: dependency groupIdorg.wicketstuff.scala/groupId artifactIdwicket-scala/artifactId version1.4-SNAPSHOT/version /dependency Cheers, Antony Stubbs, sharca.com - 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
Re: (Server-independent) Comet support in Wicket?
On Feb 20, 2008 3:50 AM, Erik van Oosten [EMAIL PROTECTED] wrote: Jörn Zaefferer wrote: ... The architecture must support several both dependent and independent components on a single page which get updated based on server-events, be it on schedules or events triggered by other users. Wicket currently support updates through timers on the client side. Can you point me at a resource that provides some details on that? While the exact number of simultaneous users isn't clear yet, up to 10k must be possible with the appropriate hardware. That is quite huge, for any framework. Because of the way Wicket uses the HTTP session, you are probably best of with a Terracotta cluster. To that regard: Is there a document that describes Wicket architecture? It looks like I need a good understand of the session usage when dealing larger number of users. Thanks Jörn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Markup Rendering issues
Hi, I've got a few rendering issues with wicket: I'd like to use IDs to select elements via jQuery on the clientside, eg. a form with wicket:id=commentForm should also have id=commentForm. Wicket generates id=commentForm4 or id=commentForm5 - I've got no idea where that number comes from. Specifying an id-attribute doesn't help, it gets overwritten. So far I was unable to select elements via jQuery using the wicket:id attribute, most likely the namespace and colon kills the attribute selector. In other words: How can I instruct Wicket to render and static id-attribute? Another, similar issue: Wicket renders stuff like wicket:child and wicket:panel into the HTML markup. While the browser ignores it, I don't know why Wicket doesn't filter out those instructional markups instead. Is that configurable? All in all, I'd like to use Wicket without making it obvious to someone reading the markup that Wicket is used to generate it. So not tags and attributes with the wicket namespace should appear in the markup - I'm not using Wickets Ajax stuff anyway. For completeness, the action attribute of my form must be modified, too. Currently the contain something like ../?wicket:interface=:1:loginForm::IFormSubmitListener::. How can I replace that, eg. mount a static URL for that form? I guess most of this is easy to resolve and I just don't know enough about Wicket, yet. Pointers or solutions are both highly appreciated. Thanks Jörn Zaefferer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Markup Rendering issues
On Wed, Mar 5, 2008 at 5:01 PM, Erik van Oosten [EMAIL PROTECTED] wrote: Hi Jörn, -- Ids This one of the exceptions in just taking existing HTML. Our designers also use jquery and solved the problem by using classes. Something like: class=idCommentForm. For jquery it doesn't matter much, and by including id in the class name the intend is still clear. While you are right that it is just as easy to jQuery to select classes, its not a real replacement. When performance matters, the difference between #id and .id can be quite huge. Richard's suggestion to use setMarkupId works for me, thanks Richard. -- Wicket tags This is all time high FAQ :) Do getMarkupSettings().setStripWicketTags(true) in the init() of your application class. (I still wonder why it is not the default.) That works perfect, thanks. I prefer a rendering that is the same in both development and deployment - if my clientside script relies on development-only markup, my deployed application would behave quite differently. -- Url handling There is a lot to say on this topic (and a lot has been said). Its best to search the lists and ask again with more specific questions. Mounting bookmarkable pages could indeed alleviate your problem. Mounting is typically done in the init() method of your application. Ok, I'll give mounting a try and see how far I can get. Thanks Jörn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to mount a form?
Hi, I'm trying to mount a form, eg. a login form to /login/, resulting in something like form action=/login//. There are a lot of classes related to mounting, though everything I found so far refers to pages. Just mounting a Form subclass doesn't yield anything at all. Thanks for any hints Jörn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Display text depending on user being logged in and intercept pages
Hi,
I'd need some help on getting the following to work properly:
If the user is logged in, display some text Hello {name}. If he
isn't logged in, display a text Please register or login instead,
where register is a link to the register page. If he clicks that
link and submits the register form, go back to the former page - use
the register page as an intercept page.
To start with, I don't know how to embed a link inside the label only
if the user is logged in - how should I structure the markup for that?
A Label component discards its body, so just nesting the link doesn't
work.
The other problem is that redirectToInterceptPage does the redirect,
but if I submit the register form I get a MarkupException about a
missing component. It looks like the intercept mechanism redirects
back to the original page, but loads the wrong template, here the
register-page-template. I've got no idea how to get that to work, so
far I replaced the intercept with a normal setResponsePage, which is
far from optimal.
Thanks
Jörn Zaefferer
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
How to flush(?) page without using setResponsePage
Hi, our application has a login form on every page, defined in a Base WebPage. So far we have to use setResponsePage(getApplication().getHomePage()); to update the page, otherwise it looks like the login didn't work, even if it did. But we don't want to go to the homepage, the user wants to stay on the current page instead. How can I flush the current page? Thanks Jörn Zaefferer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Display text depending on user being logged in and intercept pages
Hi Martijn,
thanks for the response.
Though your suggestion doesn't solve the problem of embedding a Link
within a Label. I need to be able to translate the text surrounding
the link and the text of the link itself. Depending on the language,
the position of the link varies. I can't embed a Link within a Label
and I can't wrap the Link with Labels, because then the position would
be fixed.
In other words: How would you implement the HaveToSigninFragment?
Thanks
Jörn
On Mon, Mar 10, 2008 at 12:25 PM, Martijn Dashorst
[EMAIL PROTECTED] wrote:
Use fragments for that instead to switch between the two. So you have
a UserRegistrationPanel that provides this functionality. On the panel
you create 2 fragments: one for just the label, another for the label
and link. Now you can do in onbeforerender:
if(loggedIn)
addOrReplace(new WelcomeFragment());
else addOrReplace(new HaveToSigninFragment());
Martijn
On 3/10/08, Jörn Zaefferer [EMAIL PROTECTED] wrote:
Hi,
I'd need some help on getting the following to work properly:
If the user is logged in, display some text Hello {name}. If he
isn't logged in, display a text Please register or login instead,
where register is a link to the register page. If he clicks that
link and submits the register form, go back to the former page - use
the register page as an intercept page.
To start with, I don't know how to embed a link inside the label only
if the user is logged in - how should I structure the markup for that?
A Label component discards its body, so just nesting the link doesn't
work.
The other problem is that redirectToInterceptPage does the redirect,
but if I submit the register form I get a MarkupException about a
missing component. It looks like the intercept mechanism redirects
back to the original page, but loads the wrong template, here the
register-page-template. I've got no idea how to get that to work, so
far I replaced the intercept with a normal setResponsePage, which is
far from optimal.
Thanks
Jörn Zaefferer
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.1 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.1
-
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: How to flush(?) page without using setResponsePage
Ok. An example for the basic problem: There is a label that displays Loggein as ... when the user is logged in, and Not logged in when he's not. If the user logins in using the login form, the label doesn't change, unless I use setResponsePage. I figured out that I can use setResponsePage(getPage().getClass()); to keep the user on the same page, but that still looks like a workaround to me, not a solution. Jörn On Mon, Mar 10, 2008 at 11:46 AM, Maurice Marrink [EMAIL PROTECTED] wrote: If you don't set a responsepage the current page will be served again. For determining what might be the problem of the login not working we need to see some code and a better description of what is not working. Maurice On Mon, Mar 10, 2008 at 11:39 AM, Jörn Zaefferer [EMAIL PROTECTED] wrote: Hi, our application has a login form on every page, defined in a Base WebPage. So far we have to use setResponsePage(getApplication().getHomePage()); to update the page, otherwise it looks like the login didn't work, even if it did. But we don't want to go to the homepage, the user wants to stay on the current page instead. How can I flush the current page? Thanks Jörn Zaefferer - 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: How to flush(?) page without using setResponsePage
Kudos Maurice! That was the one little thing that fixed most of the
issue I was having with Wicket. I've rewrote now most of the code,
using models and overwriting isVisible methods, works much better now.
Thanks
Jörn
On Mon, Mar 10, 2008 at 1:58 PM, Maurice Marrink [EMAIL PROTECTED] wrote:
The way you describe it, it sounds to me like you are not properly
using a model to update the label.
I am guessing you are doing something like new Label(id,Logged in)
or new Label(id,new Model(Logged in)).
What you have to remember is that you are in the constructor here,
rendering the same page does not trigger a new page object and thus no
constructor call.
In order to solve this you need a model to dynamically return whether
a user is logged in or not.
Something like this should do the job:
class MyModel extends loadableDetachableModel
{
public Object load()
{
//pseudo code:
if(Session.get().getUser()!=null)
return Logged in;
return Not logged in;
}
}
See
http://www.theserverside.com/tt/articles/article.tss?l=IntroducingApacheWicket
for an introduction to Wicket including models
Maurice
On Mon, Mar 10, 2008 at 1:10 PM, Jörn Zaefferer
[EMAIL PROTECTED] wrote:
Ok. An example for the basic problem:
There is a label that displays Loggein as ... when the user is
logged in, and Not logged in when he's not. If the user logins in
using the login form, the label doesn't change, unless I use
setResponsePage.
I figured out that I can use setResponsePage(getPage().getClass()); to
keep the user on the same page, but that still looks like a workaround
to me, not a solution.
Jörn
On Mon, Mar 10, 2008 at 11:46 AM, Maurice Marrink [EMAIL PROTECTED]
wrote:
If you don't set a responsepage the current page will be served again.
For determining what might be the problem of the login not working we
need to see some code and a better description of what is not working.
Maurice
On Mon, Mar 10, 2008 at 11:39 AM, Jörn Zaefferer
[EMAIL PROTECTED] wrote:
Hi,
our application has a login form on every page, defined in a Base
WebPage. So far we have to use
setResponsePage(getApplication().getHomePage()); to update the page,
otherwise it looks like the login didn't work, even if it did. But
we
don't want to go to the homepage, the user wants to stay on the
current page instead.
How can I flush the current page?
Thanks
Jörn Zaefferer
-
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]
-
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: Display text depending on user being logged in and intercept pages
Thanks, that worked.
Jörn
On Mon, Mar 10, 2008 at 1:25 PM, Martijn Dashorst
[EMAIL PROTECTED] wrote:
wicket:message key=beforeLink/wicket:messagea
href=#wicket:message
key=insideLink/wicket:message/awicket:message
key=afterLink/wicket:message
On 3/10/08, Jörn Zaefferer [EMAIL PROTECTED] wrote:
Hi Martijn,
thanks for the response.
Though your suggestion doesn't solve the problem of embedding a Link
within a Label. I need to be able to translate the text surrounding
the link and the text of the link itself. Depending on the language,
the position of the link varies. I can't embed a Link within a Label
and I can't wrap the Link with Labels, because then the position would
be fixed.
In other words: How would you implement the HaveToSigninFragment?
Thanks
Jörn
On Mon, Mar 10, 2008 at 12:25 PM, Martijn Dashorst
[EMAIL PROTECTED] wrote:
Use fragments for that instead to switch between the two. So you have
a UserRegistrationPanel that provides this functionality. On the panel
you create 2 fragments: one for just the label, another for the label
and link. Now you can do in onbeforerender:
if(loggedIn)
addOrReplace(new WelcomeFragment());
else addOrReplace(new HaveToSigninFragment());
Martijn
On 3/10/08, Jörn Zaefferer [EMAIL PROTECTED] wrote:
Hi,
I'd need some help on getting the following to work properly:
If the user is logged in, display some text Hello {name}. If he
isn't logged in, display a text Please register or login instead,
where register is a link to the register page. If he clicks that
link and submits the register form, go back to the former page - use
the register page as an intercept page.
To start with, I don't know how to embed a link inside the label
only
if the user is logged in - how should I structure the markup for
that?
A Label component discards its body, so just nesting the link
doesn't
work.
The other problem is that redirectToInterceptPage does the redirect,
but if I submit the register form I get a MarkupException about a
missing component. It looks like the intercept mechanism redirects
back to the original page, but loads the wrong template, here the
register-page-template. I've got no idea how to get that to work, so
far I replaced the intercept with a normal setResponsePage, which is
far from optimal.
Thanks
Jörn Zaefferer
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.1 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.1
-
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]
--
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.1 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.1
-
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]
Revisited: How to mount a form?
Hi,
I'm trying to mount forms in my wicket application more appropiate
URLs. For example I want to replace this:
action=../?wicket:interface=:3:registerpanel:registerForm::IFormSubmitListener::
with something like this (I'm not sure yet if the version parameter is
necessary, or whatever that is):
action=../register/form/?version=3
What I have so far is this:
In Application#init: mount(new FormMount(/register/action/,
RegisterPanel.RegisterForm.class));
public class FormMount extends AbstractRequestTargetUrlCodingStrategy {
private final Class? extends Form formClass;
public FormMount(String mountPath, Class? extends Form formClass) {
super(mountPath);
this.formClass = formClass;
}
public IRequestTarget decode(RequestParameters requestParameters) {
return null;
}
public CharSequence encode(IRequestTarget requestTarget) {
return null;
}
public boolean matches(IRequestTarget requestTarget) {
if (requestTarget instanceof IListenerInterfaceRequestTarget) {
IListenerInterfaceRequestTarget target =
(IListenerInterfaceRequestTarget) requestTarget;
return target.getTarget().getClass().equals(formClass);
}
return false;
}
}
Now, I have no idea how to write the encode and decode
implementations. The existing implementations are all non-trivial and
I can't find a way to instantiate the appropiate IRequestTarget.
Thanks for any hints
Jörn
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Revisited: How to mount a form?
That is not an acceptable answer. And from what I've seen, Wickets
RequestCodingStrategy-architecture allows you to mount forms just as
well - its just not exactly easy.
Any others?
On Wed, Mar 12, 2008 at 10:14 AM, Martijn Dashorst
[EMAIL PROTECTED] wrote:
You can't mount a form. Only bookmarkable pages can be mounted.
Martijn
On 3/12/08, Jörn Zaefferer [EMAIL PROTECTED] wrote:
Hi,
I'm trying to mount forms in my wicket application more appropiate
URLs. For example I want to replace this:
action=../?wicket:interface=:3:registerpanel:registerForm::IFormSubmitListener::
with something like this (I'm not sure yet if the version parameter is
necessary, or whatever that is):
action=../register/form/?version=3
What I have so far is this:
In Application#init: mount(new FormMount(/register/action/,
RegisterPanel.RegisterForm.class));
public class FormMount extends AbstractRequestTargetUrlCodingStrategy {
private final Class? extends Form formClass;
public FormMount(String mountPath, Class? extends Form
formClass) {
super(mountPath);
this.formClass = formClass;
}
public IRequestTarget decode(RequestParameters requestParameters) {
return null;
}
public CharSequence encode(IRequestTarget requestTarget) {
return null;
}
public boolean matches(IRequestTarget requestTarget) {
if (requestTarget instanceof
IListenerInterfaceRequestTarget) {
IListenerInterfaceRequestTarget target =
(IListenerInterfaceRequestTarget) requestTarget;
return
target.getTarget().getClass().equals(formClass);
}
return false;
}
}
Now, I have no idea how to write the encode and decode
implementations. The existing implementations are all non-trivial and
I can't find a way to instantiate the appropiate IRequestTarget.
Thanks for any hints
Jörn
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.1 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.1
-
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: Revisited: How to mount a form?
Jay: I didn't ask for rendering a form without a page - I just want to
control the url in the form's action attribute.
Johan: I can mount a page, but that doesn't affect the
action-attribute of the form at all.
I need to make it non-trivial for an attacker to find out which web
framework I'm using. Currently the form-urls make it way too obvious
that Wicket is in charge. The same is true for ILinkListeners.
If this really isn't possible at all, I'll most likely have to drop
Wicket once we've got the prototype ready. I really hope that isn't
necessary, there is too much good stuff in Wicket.
I still think that WebApplication's mount-method is the way to go, I'd
just need a bit of help to get the encoding and decoding implemented.
Thanks all!
Jörn
On Wed, Mar 12, 2008 at 10:37 AM, Johan Compagner [EMAIL PROTECTED] wrote:
Forms point back to the page. So the url that is generated for the form is
the page its url
so you have to mount the page where the form is on
And if you want a nice url you could try to use HybridUrlEncoding
But why do you want nice url for forms? They are just in the markup
they will not show up (normally) in the url bar
johan
On Wed, Mar 12, 2008 at 10:23 AM, Jörn Zaefferer
[EMAIL PROTECTED] wrote:
That is not an acceptable answer. And from what I've seen, Wickets
RequestCodingStrategy-architecture allows you to mount forms just as
well - its just not exactly easy.
Any others?
On Wed, Mar 12, 2008 at 10:14 AM, Martijn Dashorst
[EMAIL PROTECTED] wrote:
You can't mount a form. Only bookmarkable pages can be mounted.
Martijn
On 3/12/08, Jörn Zaefferer [EMAIL PROTECTED] wrote:
Hi,
I'm trying to mount forms in my wicket application more appropiate
URLs. For example I want to replace this:
action=../?wicket:interface=:3:registerpanel:registerForm::IFormSubmitListener::
with something like this (I'm not sure yet if the version parameter
is
necessary, or whatever that is):
action=../register/form/?version=3
What I have so far is this:
In Application#init: mount(new FormMount(/register/action/,
RegisterPanel.RegisterForm.class));
public class FormMount extends
AbstractRequestTargetUrlCodingStrategy {
private final Class? extends Form formClass;
public FormMount(String mountPath, Class? extends Form
formClass) {
super(mountPath);
this.formClass = formClass;
}
public IRequestTarget decode(RequestParameters
requestParameters) {
return null;
}
public CharSequence encode(IRequestTarget requestTarget) {
return null;
}
public boolean matches(IRequestTarget requestTarget) {
if (requestTarget instanceof
IListenerInterfaceRequestTarget) {
IListenerInterfaceRequestTarget target =
(IListenerInterfaceRequestTarget) requestTarget;
return target.getTarget
().getClass().equals(formClass);
}
return false;
}
}
Now, I have no idea how to write the encode and decode
implementations. The existing implementations are all non-trivial
and
I can't find a way to instantiate the appropiate IRequestTarget.
Thanks for any hints
Jörn
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.1 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.1
-
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: Planning Wicket Next Generation
I'm one of those poor guys stuck with IBM Websphere Portal 5 and 6, which are both Java 1.4. We can still use Java 5 for the core of our application by seperating the frontend stuff into its own project, and having retrotranslator modify the core jar file before putting it into the 1.4 web application. It doesn't give you full Java 5 support, but at least its bearable and we can use generics and autoboxing. In other words: I'm all for Wicket 1.4 on Java 5 only, the sooner the better. Jörn On Tue, Mar 18, 2008 at 8:59 AM, Johan Compagner [EMAIL PROTECTED] wrote: Its not wicket that chooses for 1.4 this long. Its for example IBM (webspere) that takes a long long time to move to jdk versions. For example i dont think there is a webspere version in sight yet for 1.6 and how long do we have that now? (except mac thats also a small problem in that area) On 3/18/08, brian.diekelman [EMAIL PROTECTED] wrote: +1 for 'Option B': 1.4=generics, drop java 1.4 support This is coming from a large DoD application (notoriously behind the technology power curve), the only thing not generified is our UI (Wicket) stuff. I think maintaining 'one behind' JVM compatibility is sufficient. I mean, come on... Java 5 came out in 2003. -- View this message in context: http://www.nabble.com/Re%3A-Planning-Wicket-Next-Generation-tp16069837p16112094.html Sent from the Wicket - User mailing list archive at Nabble.com. - 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]
Mounting and intercept pages
Hi, I have a bookmarkable page with a single param, something like domain/item/id/1. Now, to edit the item, the user has to login or register first. After doing so, either using the login form on the same page or using the register form on a different page, the user must land on exactly the same page as before (domain/item/id/1). The register page must be bookmarkable as well (eg. domain/register). All my attempts of using Links, BookmarkablePageLinks and redirectToInterceptPage all yield nothing or yet another URL like /?wicket:interface=:2 either directly or after the redirect-back-to-original-target. Any ideas how to achieve that? Thanks Jörn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mounting and intercept pages
Thanks Martijn. I gave that a try:
add(new Link(register) {
@Override public void onClick() {
throw new
RestartResponseAtInterceptPageException(Register.class);
}
@Override
public boolean isVisible() {
return !UserSession.get().isSignedIn();
}
@Override protected CharSequence getURL() {
return urlFor(getPageMap(), Register.class,
getPageParameters());
}
});
Submitting the register form (page Register) doesn't redirect me back
to the page where was I coming from, instead only displays the
register form again (with a wicket:interface url).
What am I missing?
Jörn
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mounting and intercept pages
When throwing the Restart... exception,
continueToOriginalDestination() yields false.
On Thu, Mar 20, 2008 at 2:17 PM, Hoover, William [EMAIL PROTECTED] wrote:
Try the following:
if (!continueToOriginalDestination()) {
setResponsePage(getApplication().getHomePage());
}
-Original Message-
From: Jörn Zaefferer [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 20, 2008 9:13 AM
To: users@wicket.apache.org
Subject: Re: Mounting and intercept pages
Thanks Martijn. I gave that a try:
add(new Link(register) {
@Override public void onClick() {
throw new
RestartResponseAtInterceptPageException(Register.class);
}
@Override
public boolean isVisible() {
return !UserSession.get().isSignedIn();
}
@Override protected CharSequence getURL() {
return urlFor(getPageMap(), Register.class,
getPageParameters());
}
});
Submitting the register form (page Register) doesn't redirect me back
to the page where was I coming from, instead only displays the
register form again (with a wicket:interface url).
What am I missing?
Jörn
-
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]
Setting text content of component
I keep stumbling about components where I'm (afaik) forced to add child components just to set their text content. Common examples are ListView items and Links. I'd like to set the text content of a li or a element without adding another child component (to give it a wicket:id and add a Label). Any solution to that? Jörn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Setting text content of component
Thanks Maurice, that was exactly what I was looking for! Jörn On Wed, Mar 26, 2008 at 4:30 PM, Maurice Marrink [EMAIL PROTECTED] wrote: In wicket you have to assign a Label to an Item or a Link. The corresponding markup would then be something like: li wicket:id=itemspan wicket:id=label/span/li However it is possible to remove the span for the label from the final markup send to the browser by using label.setRenderBodyOnly(true); So where you markupfile would look like the above the user would see lisome text/li Maurice On Wed, Mar 26, 2008 at 4:01 PM, Jörn Zaefferer [EMAIL PROTECTED] wrote: I keep stumbling about components where I'm (afaik) forced to add child components just to set their text content. Common examples are ListView items and Links. I'd like to set the text content of a li or a element without adding another child component (to give it a wicket:id and add a Label). Any solution to that? Jörn - 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]
