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 Thomerson 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 >> Thomerson 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 >> >> Thomerson 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: >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>
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 Vaynberg 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 > Zaefferer 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 Vaynberg >> 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: [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 Vaynberg 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: Announcing: Scala-Wicket Extensions Project
I'll take a look at the archetype. Still, a simple page with some
example code would help a lot - Maven archetypes can be quite annoying
when the repository isn't directly available.
Also I don't know where to get the test-jars.
About that arrow character: Eclipse 3.4.x on Windows XP. Default
workspace characterset is set to UTF-8 and usually that works just
fine. It probably was only the class file viewer (with attached
source) that had troubles displaying the character. But worse, I still
don't know how to type that character, which makes it extremely
impractical.
Jörn
On Tue, Aug 18, 2009 at 3:40 PM, Antony Stubbs wrote:
>
> Not sure how I missed this response Sorry!
>
> No there isn't, there's only the source code, the sample app, the archetype
> and the specification tests.
> But creating the Wicketstuff page is in the list of things to do, but it's
> not that close to the front of the queue unfort. If someone else wants to
> take a crack by my guess! Or even get me started with a template and I can
> fill in some details...
>
> The spec files are in the test-jars, but I guess wicketstuff projects aren't
> configured to deploy their test jars. Best thing to do is download the
> source, and have a look at the sample app.
>
> You should also be able to use the archetype by using a variation of (taken
> from the README for the archetype):
> "To use or test the archetype, run install, then either just run
> archetype:generate and select it from the list, or run a variant of:
>
> mvn archetype:generate -DarchetypeGroupId=org.wicketstuff.scala
> -DarchetypeArtifactId=wicket-scala-archetype -DgroupId=com.sharca
> -DartifactId=scalawicket-archetypetest -DarchetypeVersion=1.4-SNAPSHOT"
>
> note, if you have the wicketsuff repo in your settings.xml, you probably
> won't have to install the archetype yourself.
>
> The link to Nathan's page was only to give credit for the Fodel where credit
> was due - not as a source of documentation. Sorry for the confusion.
>
> Yes, the ⇒ is actually what the "=>" is supposed to be in Scala, and is a
> UTF8 character, which I'm sure would be supported by all modern editors. I'm
> surprised you can't see it properly. What OS and version of Eclipse are you
> viewing them with? I am toying around with ⇒ atm and haven't really reached
> a decision on which I prefer. But if it causes trouble for people, and it's
> an open library, then causing _less_ trouble for people is preferable :)
>
> Cheers,
> Antony.
>
> stubbisms.wordpress.com
> illegalargument.com
> sharca.com
>
>
> Jörn Zaefferer-2 wrote:
>>
>> 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 Stubbs
>> 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 SPrope
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 Stubbs 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:
>
> org.wicketstuff.scala
> wicket-scala
> 1.4-SNAPSHOT
>
>
> 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: 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 Sachs 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:
>>
>> org.wicketstuff.scala
>> wicket-scala
>> 1.4-SNAPSHOT
>>
>>
>> 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: 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 Vaynberg 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 : >> 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: 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 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 > 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: 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, IModel 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(""));
super.onComponentTagBody(markupStream, openTag);
}
Jörn
On Tue, May 26, 2009 at 2:23 PM, Jörn Zaefferer
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
> 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
>>> 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
>>> > 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 HiddenField("csrf-protection", new
>>> >> Model(csrfProtection())).setRequired(true).add(new
>>> >> IValidator() {
>>> >> public void validate(IValidatable 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
>>> 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
>>> >>> wrote:
>>> >>>> Hi,
>>> >>>>
>>> >>>> my application uses a form subclass everywhere for CSRF protection.
>>> >>>> Each form needs a hidden field like this: >> >>>> 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
>
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
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
>> 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
>> > 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 HiddenField("csrf-protection", new
>> >> Model(csrfProtection())).setRequired(true).add(new
>> >> IValidator() {
>> >> public void validate(IValidatable 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
>> 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
>> >>> wrote:
>> >>>> Hi,
>> >>>>
>> >>>> my application uses a form subclass everywhere for CSRF protection.
>> >>>> Each form needs a hidden field like this: > >>>> 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(
>> >>>> "> />");
>> >>>> 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?
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 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
> 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 HiddenField("csrf-protection", new
>> Model(csrfProtection())).setRequired(true).add(new
>> IValidator() {
>> public void validate(IValidatable 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
>> 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
>>> wrote:
>>>> Hi,
>>>>
>>>> my application uses a form subclass everywhere for CSRF protection.
>>>> Each form needs a hidden field like this: >>> 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(
>>>> "");
>>>> 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?
That was the idea. But Wicket still can't find the component markup
when looking for it. The form adds this elsewhere:
add(new HiddenField("csrf-protection", new
Model(csrfProtection())).setRequired(true).add(new
IValidator() {
public void validate(IValidatable 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 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
> wrote:
>> Hi,
>>
>> my application uses a form subclass everywhere for CSRF protection.
>> Each form needs a hidden field like this: > 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(
>> "");
>> 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
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
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:
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(
"");
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
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 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 > 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/) >> >> >>wicket-filter >>/* >>REQUEST >>ERROR >> >> >> >>404 >>/404 >> >> >> 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
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/) wicket-filter /* REQUEST ERROR 404 /404 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: 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: [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: >>> >>> >>>org.apache.wicket >>>wicket >>>1.4-rc1 >>> >>> >>> 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-
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: > > >org.apache.wicket >wicket >1.4-rc1 > > > 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 >*
Re: Render a Wicket page to a string for HTML email
No voodoo neccessary, got it working:
protected String renderPage(Class 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]
>
>
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: 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 sho
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: 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: 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: @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: CSRF Protection: double submitted cookie
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 whil
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: 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 gue
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 >> >
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: 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] > >
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: 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:
For an input with min/max value:
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?
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: "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'
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)
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)
Wicket.replaceOuterHTML(element, ""); would be this in jQuery:
$(element).after("").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, "");
> 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.
>>>>
>>>>
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 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
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
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 >> drag&drop, 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: [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: 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: >> > >> > >> > >> > 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: 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=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310561&fixfor=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: 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:) >>> &
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?
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: 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?
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: 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: 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: https flips to http
Setting the following security-constraint in your web.xml should fix that: secure / CONFIDENTIAL 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: 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 > > >
Wicket in Action
My copy of Wicket in Action just arrived - kudos to Martjin and Eelco! Great work! Jörn
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
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] > >
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 doe
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:
>
>
>wicket-snaps
>http://wicketstuff.org/maven/repository
>
>true
>
>
>true
>
>
>
>
>
> org.wicketstuff
> wicketstuff-merged-resources
> 1.3.4-SNAPSHOT
>
>
> 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 exp
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"
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"
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: [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: "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 drag&drop, 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: 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: [announce] Openlayers contrib upgraded to 1.4-SNAPSHOT
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] > >
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]
>
>
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: 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: > > 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 > some text > > 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]
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: [vote] Release 1.4 with only generics and stop support for 1.3
+1 On Thu, Mar 20, 2008 at 4:30 AM, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > This is starting to look like a voting record! Will me reach 100? :-) > Eelco > > > > On Wed, Mar 19, 2008 at 8:22 PM, Penn <[EMAIL PROTECTED]> wrote: > > > > > +1 > > > > Penn > > > > > > Martijn Dashorst wrote: > > > > > > This thread is for voting only. Use the [discuss] thread for voicing > > > your opinion or asking questions. This makes counting the votes much > > > easier. > > > > > > The discussion on our development list makes it clear that a lot of > > > folks are anxious for generified models. Most users if not all wish us > > > to release a quick release which is 1.3 + generics. The consequence is > > > that the core team will stop to support 1.3, and that everybody that > > > wishes updates will have to migrate to 1.4, and upgrade to Java 5. > > > > > > Everybody is invited to vote! Please use > > > > > > [ ] +1, Wicket 1.4 is 1.3 + generics, drop support for 1.3 > > > [ ] -1, I need a supported version running on Java 1.4 > > > > > > Let your voices be heard! > > > > > > Martijn > > > -- > > > Buy Wicket in Action: http://manning.com/dashorst > > > Apache Wicket 1.3.2 is released > > > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.2 > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > -- > > View this message in context: > > > http://www.nabble.com/-vote--Release-1.4-with-only-generics-and-stop-support-for-1.3-tp16090054p16170790.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: Mounting and intercept pages
I don't have or use any security strategy (yet). The user can visit every page, but can't use everything until logged in. Though I don't see how that should interfere with manual intercepts and bookmarkable links. Other ideas? Jörn On Thu, Mar 20, 2008 at 5:55 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > it all depends on what url your security strategy intercepts - that is > the url continuetoorigdest will use. so if your strategy intercepts a > bookmarkable url you should be good, but if it intercepts a link url > like ?wicket:interface that is where you will go back to... > > -igor > > > On Thu, Mar 20, 2008 at 2:55 AM, Jörn Zaefferer > > <[EMAIL PROTECTED]> wrote: > > > > 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] > > > > > > - > 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: 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]
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]
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: 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]
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 formClass;
> > > >
> > > > public FormMount(String mountPath, Class
> > 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: 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 formClass;
> >
> > public FormMount(String mountPath, Class
> 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]
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 formClass;
public FormMount(String mountPath, Class 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: 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:
> href="#"> key="insideLink"> key="afterLink">
>
>
>
>
>
> 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]
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: 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: 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]
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]
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 inject Spring Application context into WicketTester
Hi, my wicket applicatin uses the SpringComponentInjector and @SpringBean annotations, which works great at runtime where the application context is present. I'd like to use WicketTester for JUnit tests: tester = new WicketTester(new MyApplication()); In MyApplication#init, the component injector is created: addComponentInstantiationListener(new SpringComponentInjector(this)); That constructor loads the ApplicationContext via WebApplicationContextUtils.getRequiredWebApplicationContext(webapp.getServletContext() That is the part which fails in my test, because there is no ApplicationContext stored in the servlet context. How can I fix that? My attempts so far: The description here doesn't help: http://cwiki.apache.org/WICKET/spring.html#Spring-UnitTestingtheProxyApproach The injector is already configured at that point. The alternative would be to put the application context into the ServletContext, so that WebApplicationContextUtils can find it. I've found no way to access MockWebApplication.context to set it manually, though I was able to set it by overwriting newServletContext. Though .setAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE, context); where context is of type AnnotApplicationContextMock yields an IllegalStateException, because AnnotApplicationContextMock doesn't implement WebApplicationContext. 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 . 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]
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]
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: (Server-independent) Comet support in Wicket?
Thanks Erik and Stefan, that helps a lot. At least I'm now mostly convinced that Jetty 6 continuations are the way to go for Comet support. wicketstuff-push, based on dojo and cometd isn't that convincing though. I can't compile wicketstuff-push because there is no wicketstuff-dojo snapshot, as referenced in the pom.xml. Also, as a jQuery developer I'd much rather stick with jQuery instead of relying on dojo, which does way more than just supporting comet. The wicketstuff-push project is a good reference for implementing comet with wicket and jQuery, so it would be quite helpful to get that running. Jörn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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]
(Server-independent) Comet support in Wicket?
Hi, I've started evaluating Wicket today for an application written from scratch. First impressions are very well, there is just one requirement on which I couldn't find enough useful information yet: Comet support in Wicket or Comet with Wicket. Before looking at Wicket I tried to use lift which has Comet support built in (based on Scala Actors). This post (http://blogs.webtide.com/gregw/2006/07/25/1153845234453.html) suggests that its not possible to implement scaleable Comet support within a web framework, instead it must be supported by the application server, eg. Jetty 6. Post about Comet and Wicket, eg. this one (http://www.mail-archive.com/[EMAIL PROTECTED]/msg17308.html) don't give me any actual information about the current state of afairs (its from 2006, the linked sf.net issue is now private). This issue (http://wicketstuff.org/jira/browse/DOJO-23) about integration with cometd isn't too helpful either, I can't find any documentation on that. To provide some information on the actual requirements I have: 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. While the exact number of simultaneous users isn't clear yet, up to 10k must be possible with the appropriate hardware. Thanks Jörn Zaefferer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
