Re: Managing Pagemaps
Premature optimization. Don't try to do this type of stuff unless it is actually a problem. Why not make sure you have applications first and then see if it is actually a problem? Martijn On Sat, Mar 14, 2009 at 2:40 AM, subbu_tce wrote: > > I mean two different wicket applications running in the same JVM.. > > And i launch the first wicket application in a window.. i navigate among > different pages in the first wicket application. now since i have navigated > through different pages, i understand that multiple versions of the pages > would have been maintained in page maps. > > Now i navigate to the second wicket application from the first wicket > application. From the second wicket application, i might never navigate back > to the first wicket application. so i would need to clean up everything that > would be maintained in session with respect to the first wicket application > when i navigate to the second application. thatz y i was wondering whether > any hooks are there for the same. > > > Johan Compagner wrote: >> >> do you mean multiply wicket applications on the same host? >> (just like our example?) >> >> then yes you have a pagemap set per wicket app in your session (prefixed >> with the wicket app name) >> >> There are no such hooks because a wicket app 1 is independent on wicket >> app >> 2, they should be isolated. >> (they could be in 1 context like exampels but also could be under >> different >> contexts) >> >> Why do you want to clean up pagemaps.. A pagemap only holds they active >> page >> and nothing more. >> What you can do is destroy the session on a logout button, but i guess you >> cant invalidate the http session if it is shared over multiply apps... >> >> johan >> >> >> >> On Fri, Mar 13, 2009 at 00:58, subbu_tce >> wrote: >> >>> >>> I understand that wicket maintains page maps by windows / tabs opened. >>> >>> If the user navigates to pages in multiple wicket applications in the >>> same >>> window, how are the page maps maintained? >>> >>> Will a new page map be created / maintained for every wicket application >>> navigated in the same window? >>> >>> And does wicket provide any hook points to clean up page maps when a user >>> navigates to different applications with in the same window? >>> >>> Thanks, >>> Subbu. >>> -- >>> View this message in context: >>> http://www.nabble.com/Managing-Pagemaps-tp22487669p22487669.html >>> Sent from the Wicket - User mailing list archive at Nabble.com. >>> >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>> For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> >> >> > > -- > View this message in context: > http://www.nabble.com/Managing-Pagemaps-tp22487669p22508300.html > Sent from the Wicket - User mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.3.5 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Two Wicket Apps in a single web app
Sure. You just have to sort out the URL space so they don't conflict. Mount a bunch of Wicket filters on various URLs, each referencing a different Application instance. W On Mar 13, 2009, at 9:46 PM, subbu_tce wrote: Is it possible to two or more wicket apps in a single web appliation? -- View this message in context: http://www.nabble.com/Two-Wicket-Apps-in-a-single-web-app-tp22508361p22508361.html Sent from the Wicket - User mailing list archive at Nabble.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: Two Wicket Apps in a single web app
see wicket-examples, that runs like 10 wicket applications in a single webapp. -igor On Fri, Mar 13, 2009 at 6:46 PM, subbu_tce wrote: > > Is it possible to two or more wicket apps in a single web appliation? > -- > View this message in context: > http://www.nabble.com/Two-Wicket-Apps-in-a-single-web-app-tp22508361p22508361.html > Sent from the Wicket - User mailing list archive at Nabble.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
Two Wicket Apps in a single web app
Is it possible to two or more wicket apps in a single web appliation? -- View this message in context: http://www.nabble.com/Two-Wicket-Apps-in-a-single-web-app-tp22508361p22508361.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Managing Pagemaps
I mean two different wicket applications running in the same JVM.. And i launch the first wicket application in a window.. i navigate among different pages in the first wicket application. now since i have navigated through different pages, i understand that multiple versions of the pages would have been maintained in page maps. Now i navigate to the second wicket application from the first wicket application. From the second wicket application, i might never navigate back to the first wicket application. so i would need to clean up everything that would be maintained in session with respect to the first wicket application when i navigate to the second application. thatz y i was wondering whether any hooks are there for the same. Johan Compagner wrote: > > do you mean multiply wicket applications on the same host? > (just like our example?) > > then yes you have a pagemap set per wicket app in your session (prefixed > with the wicket app name) > > There are no such hooks because a wicket app 1 is independent on wicket > app > 2, they should be isolated. > (they could be in 1 context like exampels but also could be under > different > contexts) > > Why do you want to clean up pagemaps.. A pagemap only holds they active > page > and nothing more. > What you can do is destroy the session on a logout button, but i guess you > cant invalidate the http session if it is shared over multiply apps... > > johan > > > > On Fri, Mar 13, 2009 at 00:58, subbu_tce > wrote: > >> >> I understand that wicket maintains page maps by windows / tabs opened. >> >> If the user navigates to pages in multiple wicket applications in the >> same >> window, how are the page maps maintained? >> >> Will a new page map be created / maintained for every wicket application >> navigated in the same window? >> >> And does wicket provide any hook points to clean up page maps when a user >> navigates to different applications with in the same window? >> >> Thanks, >> Subbu. >> -- >> View this message in context: >> http://www.nabble.com/Managing-Pagemaps-tp22487669p22487669.html >> Sent from the Wicket - User mailing list archive at Nabble.com. >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > -- View this message in context: http://www.nabble.com/Managing-Pagemaps-tp22487669p22508300.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Managing Pagemaps
do you mean multiply wicket applications on the same host? (just like our example?) then yes you have a pagemap set per wicket app in your session (prefixed with the wicket app name) There are no such hooks because a wicket app 1 is independent on wicket app 2, they should be isolated. (they could be in 1 context like exampels but also could be under different contexts) Why do you want to clean up pagemaps.. A pagemap only holds they active page and nothing more. What you can do is destroy the session on a logout button, but i guess you cant invalidate the http session if it is shared over multiply apps... johan On Fri, Mar 13, 2009 at 00:58, subbu_tce wrote: > > I understand that wicket maintains page maps by windows / tabs opened. > > If the user navigates to pages in multiple wicket applications in the same > window, how are the page maps maintained? > > Will a new page map be created / maintained for every wicket application > navigated in the same window? > > And does wicket provide any hook points to clean up page maps when a user > navigates to different applications with in the same window? > > Thanks, > Subbu. > -- > View this message in context: > http://www.nabble.com/Managing-Pagemaps-tp22487669p22487669.html > Sent from the Wicket - User mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: memcached session store
like igor already also stated but just want to stress this out a bit more If you are really in the big numbers then round robin dividing sticky sessions will be just as good as just round robin I cant believe that there is any difference, its all about statistics for example you have 3 servers and you get 900 new sessions that are round robin divided when started. then the 3 servers have 300 sessions each.. Then if from those 900 sessions 300 session are logged off What do you think the division will be? My big guess is that all the server are still pretty even and all of them are around 200 (+/- a few) If now of those 600 sessions that are left, 30 of them are really heavy users with some big stuff what is the change that they are all on 1 server? 0% if you ask me Again i think that heavy sessions are evenly divided over the 3 servers So +/- 10 on each. Its just statistics, how bigger the numbers are how closer they will evenly divide over all your servers. Besides that if you use round robin request, does your load balancer really look at the server which is now doing the most? (then it is not round robin ofcourse) Because only then you can somehow really divide it. But i think this is pretty tricky, because what is heavy use at 1 point in time So saying that none sticky sessions dont balance that well is just not true, i think they will balance just as good and that balance will be even more balanced when the numbers are getting higher. johan On Fri, Mar 13, 2009 at 20:08, Victor Igumnov wrote: > @martin > > REDIRECT_TO_RENDER did not work in my case as well. Possibly I might have > screwed something up? > > @Johan > > The point of non-sticky sessions is to have even load distribution on your > cluster. What happens when you have 1,000 users dependent > on server1 that is processing some heavy background task for one of the > users? Server2 and Server3 will sit idle. > > That said, in our case, a two server sticky session setup has been working > out wonderfully. It all comes down to a decent site architecture > that will make or break your site under load. > > -Victor > > > > > On Mar 13, 2009, at 3:58 AM, Martin Grotzke wrote: > > On Wed, 2009-03-11 at 20:09 +0100, Johan Compagner wrote: >> >>> thats impossible to do completely >>> A refresh of a browser is for example 1 >>> >> Ok, from a technical/academical point of view this is valid. However, >> GET requests should not modify any data. For POST-requests the user also >> has to confirm that form data is resent. Also users pressing F5 (and >> confirming resending of data) all the time are not as common as the well >> known double-clickers... >> >> Did you really had issues with this? What was the setup/conditions in >> this case? >> >> >>> And that would be quite annoying that you have to do that because you >>> have >>> some kind of configuration on the serverside >>> >> What do you want to say with this? I don't understand this. >> >> Cheers, >> Martin >> >> >> >>> johan >>> >>> >>> On Wed, Mar 11, 2009 at 18:17, Martin Grotzke >>> wrote: >>> >>> Hi, One would need to handle this on the client side, by disabling buttons/links when they are clicked. Also AJAX communicatoin has to be handled, as this is also often a candidate that triggers multiple requests running in parallel. Cheers, Martin On Wed, 2009-03-11 at 17:45 +0100, Johan Compagner wrote: > In my point of view none sticky sessions are just broken or can be > broken > very easily > I dont know exactly how all the implementations work but does this > example > all ways work? > > a user clicks on a button > that button click does take some time and in the mean time a user > clicks > on > the same or another button > > In a sticky session configuration this works fine. Wicket makes sure > that > they are synced and a page wont be altered by 2 threads at the same > time\ > > But how does a none sticky configuration work? Will the second request > go > to > another server? And just alter there the page state? > It can do that because our sync block doesnt work then ofcourse. > > But if this happens, what happens after that? now the same page > instance > is > altered on both places.. Which one takes precedence ? > Because it is impossible for the container to merge the objects. So it > should take 1 or the other.. > So the first click that took longer then the second click will > overwrite > the > second click page. But that now overwritten page is now shown to the > user > So if you then click on something that was on the page of the second > click > but wasnt on the page of the first click. Then you will get an page > expired > or something like that.. > > maybe somehow conta
Re: WYSIWYG component
Great :) Thanks :)
The Exception stopped from ocurring, but I still have the problem of only
showing a TextArea without the look of an WYSWYG edit text area.
I looked inside
https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-core/tinymce-parent/tinymce-examples/src/main/java/wicket/contrib/examples/tinymce/and
subdirs but did not find any war file that I could look inside for how
the markup html is written. I did as the example showed, but did not have
success.
If anyone can help me...
This is my implementation
---
NewsletterForm.java
---
package com.jasp.ecommfwk.pages.newsleter.forms;
import org.apache.wicket.ajax.AjaxRequestTarget;
import org.apache.wicket.ajax.markup.html.form.AjaxButton;
import org.apache.wicket.markup.html.basic.Label;
import org.apache.wicket.markup.html.form.Form;
import org.apache.wicket.markup.html.form.TextArea;
import org.apache.wicket.markup.html.panel.FeedbackPanel;
import org.apache.wicket.model.Model;
import org.apache.wicket.model.StringResourceModel;
import wicket.contrib.tinymce.TinyMceBehavior;
import wicket.contrib.tinymce.settings.ContextMenuPlugin;
import wicket.contrib.tinymce.settings.DateTimePlugin;
import wicket.contrib.tinymce.settings.DirectionalityPlugin;
import wicket.contrib.tinymce.settings.EmotionsPlugin;
import wicket.contrib.tinymce.settings.FullScreenPlugin;
import wicket.contrib.tinymce.settings.IESpellPlugin;
import wicket.contrib.tinymce.settings.MediaPlugin;
import wicket.contrib.tinymce.settings.PastePlugin;
import wicket.contrib.tinymce.settings.PreviewPlugin;
import wicket.contrib.tinymce.settings.PrintPlugin;
import wicket.contrib.tinymce.settings.SavePlugin;
import wicket.contrib.tinymce.settings.SearchReplacePlugin;
import wicket.contrib.tinymce.settings.SpellCheckPlugin;
import wicket.contrib.tinymce.settings.TablePlugin;
import wicket.contrib.tinymce.settings.TinyMCESettings;
import com.jasp.ecommfwk.pages.forms.BaseForm;
import com.jasp.persistence.admin.Newsletter;
public class NewsletterForm extends BaseForm {
private static final String TEXT = ""
+ "TinyMCE is a platform independent web based Javascript HTML
WYSIWYG editor control released as Open Source under LGPL
by Moxiecode Systems AB. "
+ "It has the ability to convert HTML TEXTAREA fields or other HTML
elements to editor instances. TinyMCE is very easy to integrate into other
Content Management Systems."
+ "We recommend http://www.getfirefox.com\";
target=\"_blank\">Firefox and http://www.google.com\";
target=\"_blank\">Google ";
private static final long serialVersionUID = 2335975457449309765L;
private final StringResourceModel labelNewsletterValue = new
StringResourceModel(
"news.newsletter", this, null, new Object[] { getLocale() });
private Label labelNews;
private TextArea newsLetterContent;
private AjaxButton cadastrar;
private FeedbackPanel feedbackPanel;
private Newsletter newsletter = new Newsletter();
private TinyMCESettings settings;
private ContextMenuPlugin contextMenuPlugin;
public NewsletterForm(String id) {
super(id);
inicializaComponentesForm();
AddComponentToForm();
// TODO Auto-generated constructor stub
}
@Override
protected void AddComponentToForm() {
this.add(labelNews);
this.add(cadastrar);
this.add(newsLetterContent);
this.add(feedbackPanel);
}
@Override
protected void inicializaComponentesForm() {
labelNews = new Label("labelNews", labelNewsletterValue);
settings = new TinyMCESettings(TinyMCESettings.Theme.advanced);
contextMenuPlugin = new ContextMenuPlugin();
settings.register(contextMenuPlugin);
// first toolbar
SavePlugin savePlugin = new SavePlugin();
settings.add(savePlugin.getSaveButton(),
TinyMCESettings.Toolbar.first, TinyMCESettings.Position.before);
settings.add(wicket.contrib.tinymce.settings.Button.newdocument,
TinyMCESettings.Toolbar.first, TinyMCESettings.Position.before);
settings.add(wicket.contrib.tinymce.settings.Button.separator,
TinyMCESettings.Toolbar.first, TinyMCESettings.Position.before);
settings.add(wicket.contrib.tinymce.settings.Button.fontselect,
TinyMCESettings.Toolbar.first, TinyMCESettings.Position.after);
settings.add(wicket.contrib.tinymce.settings.Button.fontsizeselect,
TinyMCESettings.Toolbar.first, TinyMCESettings.Position.after);
// second toolbar
PastePlugin pastePlugin = new PastePlugin();
SearchReplacePlugin searchReplacePlugin = new SearchReplacePlugin();
DateTimePlugin dateTimePlugin = new DateTimePlugin();
dateTimePlugin.setDateFormat("Date: %m-%d-%Y");
dateTimePlugin.setTimeFormat("Time: %H:%M");
PreviewPlugin previewPlugin = new PreviewPlugin();
settings.add(wicke
Re: can we get this patch applied to the current snapshot?
yes, you are right, the red squiggle i got in the ide was actually :
error: this variable might not have been initialized :|
-igor
On Fri, Mar 13, 2009 at 1:39 PM, James Carman
wrote:
> As I said before, my patch for WICKET-2165 doesn't change any test or
> example code at all and everything builds just fine. There are plenty
> of examples in the test and example code where you pass in a
> IModel> to the constructor and it all is still working. Take
> for example the FileListView class in the MultiUploadPage example from
> wicket-examples. It's passing an IModel> to its
> superclass' (ListView) constructor. No issues.
>
> On Fri, Mar 13, 2009 at 4:33 PM, James Carman
> wrote:
>> I did! I added a simple class to my wicket development project that
>> has all of my changes applied for WICKET-2165. In IDEA when I hit
>> Ctrl-B (go to declaration) it takes me to a constructor with this
>> signature:
>>
>> public ListView(final String id, final IModel> T>> model)
>>
>> If you don't believe me, just try this to verify:
>>
>> public class ListManager extends Panel
>> {
>> public ListManager(String id, IModel> entries)
>> {
>> super(id);
>> someMethod(entries);
>> }
>>
>> private void someMethod(IModel> model)
>> {
>> // Do nothing!
>> }
>> }
>>
>> This compiles just fine.
>>
>> On Fri, Mar 13, 2009 at 4:25 PM, Igor Vaynberg
>> wrote:
>>> now change listview to take imodel>
>>>
>>> -igor
>>>
>>> On Fri, Mar 13, 2009 at 1:00 PM, James Carman
>>> wrote:
Ok, what part are you talking about that doesn't compile? In my IDE
right now, I have:
public class ListManager extends Panel
{
public ListManager(String id, IModel> entries)
{
super(id);
add(new ListView("list", entries)
{
protected void populateItem(ListItem item)
{
}
});
}
}
This all checks out fine. I didn't use the form part because Panel's
getDefaultModelObject() method returns Object, and you can't call
add() on that, so I assumed that was just for illustrative purposes.
On Fri, Mar 13, 2009 at 2:57 PM, Igor Vaynberg
wrote:
> yes, sorry
>
> class listmanager extends panel {
>
> public listmanager(string id, imodel> entries) {
> add(new form("form") { onsubmit() {
> listmanager.this.getmodelobject().add(someentry);}}
> add(new listview("list", entries){});
>
>
> -igor
>
> On Fri, Mar 13, 2009 at 11:51 AM, James Carman
> wrote:
>> If T is the element type, then you can't use an IModel for the
>> choices.
>> You can't do that with the current API. Did you mean to pass in an
>> IModel> to the constructor?
>>
>> On Mar 13, 2009 2:45 PM, "Igor Vaynberg" wrote:
>>
>> t is the type of a list element, see below
>>
>> class listmanager extends panel {
>>
>> public listmanager(string id, imodel entries) {
>> add(new form("form") { onsubmit() {
>> listmanager.this.getmodelobject().add(someentry);}}
>> add(new listview("list", entries){});
>>
>> ^ wont compile because you cant assign imodel to imodel> list> extends t>> so we ha...
>>
>> On Fri, Mar 13, 2009 at 8:59 AM, James Carman
>>
>> wrote: > T has to be a ...
>>
>
> -
> 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: Propper Way to Use StringResourceModel
i said COMPONENT not a MODEL
-igor
On Fri, Mar 13, 2009 at 2:50 PM, Daniel Ferreira Castro
wrote:
> If I declare
> *private final* StringResourceModel labelCategoriaValue = new
> StringResourceModel("categoria.label", *this, null, new* Object[] {
> getLocale() });
>
> The labelCategoriaValue is not a ResourceBundle. The method signature
> getString does not have input parameters.
> So, as seems, it is not a ResourceBundle.
>
>
> On Fri, Mar 13, 2009 at 11:46 AM, Igor Vaynberg
> wrote:
>
>> each component is a resource bundle, not a model. you can use
>> component's getstring(..) to read any resource you want.
>>
>> -igor
>>
>> On Fri, Mar 13, 2009 at 4:19 AM, Daniel Ferreira Castro
>> wrote:
>> > I have seen some examples of Pages that uses the StringResourceModel to
>> read
>> > properties inside property files. But the examples that I saw shows that
>> I
>> > need to create a StringResourceModel for each property that is inside my
>> > property file. So, If I have a Login page that have 3 properties, like
>> > login.username , login.password and login.button I must create also 3
>> > StringResourceModels and use each one on the constructor of the Labels.
>> >
>> > I do not think it is a practical solution because I see the
>> > StringResourceModel as a ResourceBundle.
>> >
>> > Am I right? What is the real deal when using it?
>> > Is it the propper way to internationalize a resource?
>> > Is there a way to make a single StringResourceModel and use it to read a
>> > property file so, instead of creating several resources I create a single
>> > one and pass the key that I wanna retrieve its value?
>> >
>> > --
>> > "Two rules to succeed in life:
>> > 1 - don´t tell people everything you know."
>> >
>> > We shall go on to the end.
>> > We shall fight in France
>> > We shall fightover the seas and oceans.
>> > We shall fight with growing confidence and growing strength in the air.
>> > We shall defend our island whatever the cost may be
>> > We shall fight on beaches, we shall fight on the landing grounds,
>> > We shall fight in the fields and in the streets,
>> > We shall fight on the hills.
>> > We shall never surrender.
>> > Winston Churchill
>> >
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
>
> --
> "Two rules to succeed in life:
> 1 - don´t tell people everything you know."
>
> We shall go on to the end.
> We shall fight in France
> We shall fightover the seas and oceans.
> We shall fight with growing confidence and growing strength in the air.
> We shall defend our island whatever the cost may be
> We shall fight on beaches, we shall fight on the landing grounds,
> We shall fight in the fields and in the streets,
> We shall fight on the hills.
> We shall never surrender.
> Winston Churchill
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Propper Way to Use StringResourceModel
If I declare
*private final* StringResourceModel labelCategoriaValue = new
StringResourceModel("categoria.label", *this, null, new* Object[] {
getLocale() });
The labelCategoriaValue is not a ResourceBundle. The method signature
getString does not have input parameters.
So, as seems, it is not a ResourceBundle.
On Fri, Mar 13, 2009 at 11:46 AM, Igor Vaynberg wrote:
> each component is a resource bundle, not a model. you can use
> component's getstring(..) to read any resource you want.
>
> -igor
>
> On Fri, Mar 13, 2009 at 4:19 AM, Daniel Ferreira Castro
> wrote:
> > I have seen some examples of Pages that uses the StringResourceModel to
> read
> > properties inside property files. But the examples that I saw shows that
> I
> > need to create a StringResourceModel for each property that is inside my
> > property file. So, If I have a Login page that have 3 properties, like
> > login.username , login.password and login.button I must create also 3
> > StringResourceModels and use each one on the constructor of the Labels.
> >
> > I do not think it is a practical solution because I see the
> > StringResourceModel as a ResourceBundle.
> >
> > Am I right? What is the real deal when using it?
> > Is it the propper way to internationalize a resource?
> > Is there a way to make a single StringResourceModel and use it to read a
> > property file so, instead of creating several resources I create a single
> > one and pass the key that I wanna retrieve its value?
> >
> > --
> > "Two rules to succeed in life:
> > 1 - don´t tell people everything you know."
> >
> > We shall go on to the end.
> > We shall fight in France
> > We shall fightover the seas and oceans.
> > We shall fight with growing confidence and growing strength in the air.
> > We shall defend our island whatever the cost may be
> > We shall fight on beaches, we shall fight on the landing grounds,
> > We shall fight in the fields and in the streets,
> > We shall fight on the hills.
> > We shall never surrender.
> > Winston Churchill
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
--
"Two rules to succeed in life:
1 - don´t tell people everything you know."
We shall go on to the end.
We shall fight in France
We shall fightover the seas and oceans.
We shall fight with growing confidence and growing strength in the air.
We shall defend our island whatever the cost may be
We shall fight on beaches, we shall fight on the landing grounds,
We shall fight in the fields and in the streets,
We shall fight on the hills.
We shall never surrender.
Winston Churchill
Open popup window in an ajax-response
Hello Guys, I am looking for some suggestions on this one issue i am trying to resolve. I have an ajax enabled form which consists of an input field and a submit button. Basically the input needs to be validated against some validation-rules and if successful a popup window should be opened up, ELSE IF the input validation fails a validation-message should be shown and NO popup window should be opened. Now i was able to work out a solution by basically appending the javascript of a PopupSettings class as below in the onSubmit method of the Ajax Enabled Form if the validation is successful (else add a feedback-message) target.appendJavascript(popupSettings.getPopupJavaScript()); Though this works fine and gives the desired behavior, the only problem is the popup-blockers, which when enabled block the window.open() call... So all i am looking for is work arounds, now one way is to make this ajax-form submission to be actually an SYNCHRONOUS call and program the the window.open() call on the client side only (instead of appending the PopupSettings script in the onSubmit()) on the onClick-Event and based on the ajax-response signifying input-validation success or failure, open the popup window(). NOW if i do opt for this approach of blocking call, is there an easy way to achieve this ? that is making a call synchronous ? though i know its not ideal but seems like the only way to avoid the blockers... Any suggestion or work around ? -- View this message in context: http://www.nabble.com/Open-popup-window-in-an-ajax-response-tp22502811p22502811.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: can we get this patch applied to the current snapshot?
As I said before, my patch for WICKET-2165 doesn't change any test or
example code at all and everything builds just fine. There are plenty
of examples in the test and example code where you pass in a
IModel> to the constructor and it all is still working. Take
for example the FileListView class in the MultiUploadPage example from
wicket-examples. It's passing an IModel> to its
superclass' (ListView) constructor. No issues.
On Fri, Mar 13, 2009 at 4:33 PM, James Carman
wrote:
> I did! I added a simple class to my wicket development project that
> has all of my changes applied for WICKET-2165. In IDEA when I hit
> Ctrl-B (go to declaration) it takes me to a constructor with this
> signature:
>
> public ListView(final String id, final IModel T>> model)
>
> If you don't believe me, just try this to verify:
>
> public class ListManager extends Panel
> {
> public ListManager(String id, IModel> entries)
> {
> super(id);
> someMethod(entries);
> }
>
> private void someMethod(IModel> model)
> {
> // Do nothing!
> }
> }
>
> This compiles just fine.
>
> On Fri, Mar 13, 2009 at 4:25 PM, Igor Vaynberg
> wrote:
>> now change listview to take imodel>
>>
>> -igor
>>
>> On Fri, Mar 13, 2009 at 1:00 PM, James Carman
>> wrote:
>>> Ok, what part are you talking about that doesn't compile? In my IDE
>>> right now, I have:
>>>
>>> public class ListManager extends Panel
>>> {
>>> public ListManager(String id, IModel> entries)
>>> {
>>> super(id);
>>> add(new ListView("list", entries)
>>> {
>>> protected void populateItem(ListItem item)
>>> {
>>>
>>> }
>>> });
>>> }
>>> }
>>>
>>> This all checks out fine. I didn't use the form part because Panel's
>>> getDefaultModelObject() method returns Object, and you can't call
>>> add() on that, so I assumed that was just for illustrative purposes.
>>>
>>>
>>> On Fri, Mar 13, 2009 at 2:57 PM, Igor Vaynberg
>>> wrote:
yes, sorry
class listmanager extends panel {
public listmanager(string id, imodel> entries) {
add(new form("form") { onsubmit() {
listmanager.this.getmodelobject().add(someentry);}}
add(new listview("list", entries){});
-igor
On Fri, Mar 13, 2009 at 11:51 AM, James Carman
wrote:
> If T is the element type, then you can't use an IModel for the choices.
> You can't do that with the current API. Did you mean to pass in an
> IModel> to the constructor?
>
> On Mar 13, 2009 2:45 PM, "Igor Vaynberg" wrote:
>
> t is the type of a list element, see below
>
> class listmanager extends panel {
>
> public listmanager(string id, imodel entries) {
> add(new form("form") { onsubmit() {
> listmanager.this.getmodelobject().add(someentry);}}
> add(new listview("list", entries){});
>
> ^ wont compile because you cant assign imodel to imodel list extends t>> so we ha...
>
> On Fri, Mar 13, 2009 at 8:59 AM, James Carman
>
> wrote: > T has to be a ...
>
-
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: wicketstuff-jamon
Started tracing where the null monitor is being created. For my Wicket application, the null target values are associated with Wicket packaged resources such as images and JavaScript files. -- View this message in context: http://www.nabble.com/wicketstuff-jamon-tp16125597p22501465.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: can we get this patch applied to the current snapshot?
I did! I added a simple class to my wicket development project that
has all of my changes applied for WICKET-2165. In IDEA when I hit
Ctrl-B (go to declaration) it takes me to a constructor with this
signature:
public ListView(final String id, final IModel> model)
If you don't believe me, just try this to verify:
public class ListManager extends Panel
{
public ListManager(String id, IModel> entries)
{
super(id);
someMethod(entries);
}
private void someMethod(IModel> model)
{
// Do nothing!
}
}
This compiles just fine.
On Fri, Mar 13, 2009 at 4:25 PM, Igor Vaynberg wrote:
> now change listview to take imodel>
>
> -igor
>
> On Fri, Mar 13, 2009 at 1:00 PM, James Carman
> wrote:
>> Ok, what part are you talking about that doesn't compile? In my IDE
>> right now, I have:
>>
>> public class ListManager extends Panel
>> {
>> public ListManager(String id, IModel> entries)
>> {
>> super(id);
>> add(new ListView("list", entries)
>> {
>> protected void populateItem(ListItem item)
>> {
>>
>> }
>> });
>> }
>> }
>>
>> This all checks out fine. I didn't use the form part because Panel's
>> getDefaultModelObject() method returns Object, and you can't call
>> add() on that, so I assumed that was just for illustrative purposes.
>>
>>
>> On Fri, Mar 13, 2009 at 2:57 PM, Igor Vaynberg
>> wrote:
>>> yes, sorry
>>>
>>> class listmanager extends panel {
>>>
>>> public listmanager(string id, imodel> entries) {
>>> add(new form("form") { onsubmit() {
>>> listmanager.this.getmodelobject().add(someentry);}}
>>> add(new listview("list", entries){});
>>>
>>>
>>> -igor
>>>
>>> On Fri, Mar 13, 2009 at 11:51 AM, James Carman
>>> wrote:
If T is the element type, then you can't use an IModel for the choices.
You can't do that with the current API. Did you mean to pass in an
IModel> to the constructor?
On Mar 13, 2009 2:45 PM, "Igor Vaynberg" wrote:
t is the type of a list element, see below
class listmanager extends panel {
public listmanager(string id, imodel entries) {
add(new form("form") { onsubmit() {
listmanager.this.getmodelobject().add(someentry);}}
add(new listview("list", entries){});
^ wont compile because you cant assign imodel to imodel>>> extends t>> so we ha...
On Fri, Mar 13, 2009 at 8:59 AM, James Carman
wrote: > T has to be a ...
>>>
>>> -
>>> 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: can we get this patch applied to the current snapshot?
now change listview to take imodel>
-igor
On Fri, Mar 13, 2009 at 1:00 PM, James Carman
wrote:
> Ok, what part are you talking about that doesn't compile? In my IDE
> right now, I have:
>
> public class ListManager extends Panel
> {
> public ListManager(String id, IModel> entries)
> {
> super(id);
> add(new ListView("list", entries)
> {
> protected void populateItem(ListItem item)
> {
>
> }
> });
> }
> }
>
> This all checks out fine. I didn't use the form part because Panel's
> getDefaultModelObject() method returns Object, and you can't call
> add() on that, so I assumed that was just for illustrative purposes.
>
>
> On Fri, Mar 13, 2009 at 2:57 PM, Igor Vaynberg
> wrote:
>> yes, sorry
>>
>> class listmanager extends panel {
>>
>> public listmanager(string id, imodel> entries) {
>> add(new form("form") { onsubmit() {
>> listmanager.this.getmodelobject().add(someentry);}}
>> add(new listview("list", entries){});
>>
>>
>> -igor
>>
>> On Fri, Mar 13, 2009 at 11:51 AM, James Carman
>> wrote:
>>> If T is the element type, then you can't use an IModel for the choices.
>>> You can't do that with the current API. Did you mean to pass in an
>>> IModel> to the constructor?
>>>
>>> On Mar 13, 2009 2:45 PM, "Igor Vaynberg" wrote:
>>>
>>> t is the type of a list element, see below
>>>
>>> class listmanager extends panel {
>>>
>>> public listmanager(string id, imodel entries) {
>>> add(new form("form") { onsubmit() {
>>> listmanager.this.getmodelobject().add(someentry);}}
>>> add(new listview("list", entries){});
>>>
>>> ^ wont compile because you cant assign imodel to imodel>> extends t>> so we ha...
>>>
>>> On Fri, Mar 13, 2009 at 8:59 AM, James Carman
>>> wrote: > T has to be a ...
>>>
>>
>> -
>> 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: can we get this patch applied to the current snapshot?
Ok, what part are you talking about that doesn't compile? In my IDE
right now, I have:
public class ListManager extends Panel
{
public ListManager(String id, IModel> entries)
{
super(id);
add(new ListView("list", entries)
{
protected void populateItem(ListItem item)
{
}
});
}
}
This all checks out fine. I didn't use the form part because Panel's
getDefaultModelObject() method returns Object, and you can't call
add() on that, so I assumed that was just for illustrative purposes.
On Fri, Mar 13, 2009 at 2:57 PM, Igor Vaynberg wrote:
> yes, sorry
>
> class listmanager extends panel {
>
> public listmanager(string id, imodel> entries) {
> add(new form("form") { onsubmit() {
> listmanager.this.getmodelobject().add(someentry);}}
> add(new listview("list", entries){});
>
>
> -igor
>
> On Fri, Mar 13, 2009 at 11:51 AM, James Carman
> wrote:
>> If T is the element type, then you can't use an IModel for the choices.
>> You can't do that with the current API. Did you mean to pass in an
>> IModel> to the constructor?
>>
>> On Mar 13, 2009 2:45 PM, "Igor Vaynberg" wrote:
>>
>> t is the type of a list element, see below
>>
>> class listmanager extends panel {
>>
>> public listmanager(string id, imodel entries) {
>> add(new form("form") { onsubmit() {
>> listmanager.this.getmodelobject().add(someentry);}}
>> add(new listview("list", entries){});
>>
>> ^ wont compile because you cant assign imodel to imodel> extends t>> so we ha...
>>
>> On Fri, Mar 13, 2009 at 8:59 AM, James Carman
>> wrote: > T has to be a ...
>>
>
> -
> 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: memcached session store
why would server one have 1000 users while server two and three are empty? do you mean that in the time between user starting a heavy task and your loadbalancer receiving a cpu-load update from server one it has already received 1000 new requests from 1000 users while server two and three have not received any? while roundrobin allows you to *more* evenly distribute the load, sticky sessions do a pretty good job as well. further, you should not have any heavy tasks running inside servlet threads. as soon as you have any state roundrobin becomes inefficient because you either have to replicate the state to all other nodes or to a central resource like a db. with stickysessions you simply have a backup-buddy node and only replicate state between those two. so i guess what i am trying to say is: round-robin is great for serving static content, for webapps its uselss unless your application is completely stateless. just my two cents, if it were up to me we wouldnt even introduce the complexity of supporting round robin with direct render strategy. -igor On Fri, Mar 13, 2009 at 12:08 PM, Victor Igumnov wrote: > @martin > > REDIRECT_TO_RENDER did not work in my case as well. Possibly I might have > screwed something up? > > @Johan > > The point of non-sticky sessions is to have even load distribution on your > cluster. What happens when you have 1,000 users dependent > on server1 that is processing some heavy background task for one of the > users? Server2 and Server3 will sit idle. > > That said, in our case, a two server sticky session setup has been working > out wonderfully. It all comes down to a decent site architecture > that will make or break your site under load. > > -Victor > > > > On Mar 13, 2009, at 3:58 AM, Martin Grotzke wrote: > >> On Wed, 2009-03-11 at 20:09 +0100, Johan Compagner wrote: >>> >>> thats impossible to do completely >>> A refresh of a browser is for example 1 >> >> Ok, from a technical/academical point of view this is valid. However, >> GET requests should not modify any data. For POST-requests the user also >> has to confirm that form data is resent. Also users pressing F5 (and >> confirming resending of data) all the time are not as common as the well >> known double-clickers... >> >> Did you really had issues with this? What was the setup/conditions in >> this case? >> >>> >>> And that would be quite annoying that you have to do that because you >>> have >>> some kind of configuration on the serverside >> >> What do you want to say with this? I don't understand this. >> >> Cheers, >> Martin >> >> >>> >>> johan >>> >>> >>> On Wed, Mar 11, 2009 at 18:17, Martin Grotzke >>> wrote: >>> Hi, One would need to handle this on the client side, by disabling buttons/links when they are clicked. Also AJAX communicatoin has to be handled, as this is also often a candidate that triggers multiple requests running in parallel. Cheers, Martin On Wed, 2009-03-11 at 17:45 +0100, Johan Compagner wrote: > > In my point of view none sticky sessions are just broken or can be > broken > very easily > I dont know exactly how all the implementations work but does this example > > all ways work? > > a user clicks on a button > that button click does take some time and in the mean time a user > clicks on > > the same or another button > > In a sticky session configuration this works fine. Wicket makes sure that > > they are synced and a page wont be altered by 2 threads at the same > time\ > > But how does a none sticky configuration work? Will the second request > go to > > another server? And just alter there the page state? > It can do that because our sync block doesnt work then ofcourse. > > But if this happens, what happens after that? now the same page > instance is > > altered on both places.. Which one takes precedence ? > Because it is impossible for the container to merge the objects. So it > should take 1 or the other.. > So the first click that took longer then the second click will > overwrite the > > second click page. But that now overwritten page is now shown to the > user > So if you then click on something that was on the page of the second click > > but wasnt on the page of the first click. Then you will get an page expired > > or something like that.. > > maybe somehow containers do some synching across concurrent request of > 1 > session (hopefully the will send them to the same server) > But i dont know. Synching over servers is very expensive.. then the > whole > usage of having none sticky sessions is completely gone in my eyes. > > johan > > On Tue, Mar 10, 2009 at 10:49, Martin Grotzke > wrote: > >> On Mon, 2009-03-09
Re: memcached session store
@martin REDIRECT_TO_RENDER did not work in my case as well. Possibly I might have screwed something up? @Johan The point of non-sticky sessions is to have even load distribution on your cluster. What happens when you have 1,000 users dependent on server1 that is processing some heavy background task for one of the users? Server2 and Server3 will sit idle. That said, in our case, a two server sticky session setup has been working out wonderfully. It all comes down to a decent site architecture that will make or break your site under load. -Victor On Mar 13, 2009, at 3:58 AM, Martin Grotzke wrote: On Wed, 2009-03-11 at 20:09 +0100, Johan Compagner wrote: thats impossible to do completely A refresh of a browser is for example 1 Ok, from a technical/academical point of view this is valid. However, GET requests should not modify any data. For POST-requests the user also has to confirm that form data is resent. Also users pressing F5 (and confirming resending of data) all the time are not as common as the well known double-clickers... Did you really had issues with this? What was the setup/conditions in this case? And that would be quite annoying that you have to do that because you have some kind of configuration on the serverside What do you want to say with this? I don't understand this. Cheers, Martin johan On Wed, Mar 11, 2009 at 18:17, Martin Grotzke wrote: Hi, One would need to handle this on the client side, by disabling buttons/links when they are clicked. Also AJAX communicatoin has to be handled, as this is also often a candidate that triggers multiple requests running in parallel. Cheers, Martin On Wed, 2009-03-11 at 17:45 +0100, Johan Compagner wrote: In my point of view none sticky sessions are just broken or can be broken very easily I dont know exactly how all the implementations work but does this example all ways work? a user clicks on a button that button click does take some time and in the mean time a user clicks on the same or another button In a sticky session configuration this works fine. Wicket makes sure that they are synced and a page wont be altered by 2 threads at the same time\ But how does a none sticky configuration work? Will the second request go to another server? And just alter there the page state? It can do that because our sync block doesnt work then ofcourse. But if this happens, what happens after that? now the same page instance is altered on both places.. Which one takes precedence ? Because it is impossible for the container to merge the objects. So it should take 1 or the other.. So the first click that took longer then the second click will overwrite the second click page. But that now overwritten page is now shown to the user So if you then click on something that was on the page of the second click but wasnt on the page of the first click. Then you will get an page expired or something like that.. maybe somehow containers do some synching across concurrent request of 1 session (hopefully the will send them to the same server) But i dont know. Synching over servers is very expensive.. then the whole usage of having none sticky sessions is completely gone in my eyes. johan On Tue, Mar 10, 2009 at 10:49, Martin Grotzke wrote: On Mon, 2009-03-09 at 22:54 -0700, Victor Igumnov wrote: Even if you have the memcached store in place, wicket still requires session affinity. Wicket buffers redirect responses locally so the client needs to go to the same server twice or the client will receive an expired session. Wicket is a stateful framework, session affinity is a must. Are there other things (besides the buffered response when doing a redirect-after-post with the REDIRECT_TO_BUFFER setting) that require sticky sessions? We'd like to use wicket in a stateless mode and defer session creation as long as it's possible for a user. Even if wicket is made with a statefull programming model in mind we think there are still many advantages over other (non-component-based) frameworks. Also we need a dynamic structure which would be rather hard to realize/simulate with some other component oriented frameworks ;) Cheers, Martin On Mar 9, 2009, at 7:03 AM, Martin Grotzke wrote: On Mon, 2009-03-09 at 13:07 +0100, Martijn Dashorst wrote: Starts to sound like a form of premature optimization. If you are new to Wicket, why do you want to implement a memcached session store? What is the usecase? We're starting a new project (the relaunch of a big ecommerce system) and want to be able to scale out (just throw in new hardware when traffic grows). Additionally we have the requirement of session failover, both in standard operations and for deployments. We're discussing non-sticky vs. sticky sessions here and for non- sticky sessions memcached (as caching layer in addition to sessions stored in a database) is a good candidate, as you don't re
Re: can we get this patch applied to the current snapshot?
yes, sorry
class listmanager extends panel {
public listmanager(string id, imodel> entries) {
add(new form("form") { onsubmit() {
listmanager.this.getmodelobject().add(someentry);}}
add(new listview("list", entries){});
-igor
On Fri, Mar 13, 2009 at 11:51 AM, James Carman
wrote:
> If T is the element type, then you can't use an IModel for the choices.
> You can't do that with the current API. Did you mean to pass in an
> IModel> to the constructor?
>
> On Mar 13, 2009 2:45 PM, "Igor Vaynberg" wrote:
>
> t is the type of a list element, see below
>
> class listmanager extends panel {
>
> public listmanager(string id, imodel entries) {
> add(new form("form") { onsubmit() {
> listmanager.this.getmodelobject().add(someentry);}}
> add(new listview("list", entries){});
>
> ^ wont compile because you cant assign imodel to imodel extends t>> so we ha...
>
> On Fri, Mar 13, 2009 at 8:59 AM, James Carman
> wrote: > T has to be a ...
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: can we get this patch applied to the current snapshot?
If T is the element type, then you can't use an IModel for the choices.
You can't do that with the current API. Did you mean to pass in an
IModel> to the constructor?
On Mar 13, 2009 2:45 PM, "Igor Vaynberg" wrote:
t is the type of a list element, see below
class listmanager extends panel {
public listmanager(string id, imodel entries) {
add(new form("form") { onsubmit() {
listmanager.this.getmodelobject().add(someentry);}}
add(new listview("list", entries){});
^ wont compile because you cant assign imodel to imodel> so we ha...
On Fri, Mar 13, 2009 at 8:59 AM, James Carman
wrote: > T has to be a ...
Re: can we get this patch applied to the current snapshot?
t is the type of a list element, see below
class listmanager extends panel {
public listmanager(string id, imodel entries) {
add(new form("form") { onsubmit() {
listmanager.this.getmodelobject().add(someentry);}}
add(new listview("list", entries){});
^ wont compile because you cant assign imodel to imodel> so we have to cast???
-igor
On Fri, Mar 13, 2009 at 8:59 AM, James Carman
wrote:
> T has to be a list of some sort in this case and you would want to
> convey that in your API. Are you wanting T to be the element type
> here or the list type itself. I'm really having a hard time following
> what you're trying to do here. What type parameter are you passing
> into your listview?
>
> On Fri, Mar 13, 2009 at 11:53 AM, Igor Vaynberg
> wrote:
>> the problem remains.
>>
>> lets say we change listview to take imodel>
>>
>> i want to do something like this:
>>
>> class listmanger extends panel {
>> public listmanager(string id, imodel entries) {
>> addformtoaddtems();
>> add(new listview("list", entities));
>> ^ wont compile because you cant assign imodel to imodel> extends list> so we have to cast???
>>
>> -igor
>>
>> On Fri, Mar 13, 2009 at 8:02 AM, James Carman
>> wrote:
>>> Yes, but that's fine. The idea is that I want to collect a
>>> List, but I want to choose from a List. That
>>> should be allowed.
>>>
>>>
>>> On Fri, Mar 13, 2009 at 10:42 AM, Igor Vaynberg
>>> wrote:
so then again you are back to something taking imodel> and a
widened version in the same constructor.
-igor
On Fri, Mar 13, 2009 at 3:54 AM, James Carman
wrote:
> Again, ListMultipleChoice is okay in this instance. You don't want to
> "widen" the model. You want to widen what can go in it (the choices),
> which I have.
>
> On Fri, Mar 13, 2009 at 3:40 AM, Igor Vaynberg
> wrote:
>> taking ListMultipleChoice as another example, your patch leaves it us
>>
>> public class ListMultipleChoice extends AbstractChoice,
>> T>
>>
>> when in fact it should be properly declared as
>>
>> public class ListMultipleChoice extends AbstractChoice> extends T>, T>
>>
>> so that getModelObject() properly returns Collection
>> instead of the unsafe variant Collection
>>
>> which, once again, will break updatemodel()
>>
>> in your experience you havent ran into a situation where a component
>> updates its collection model object. my experience is quiet the
>> opposite. just trying to make sure we do not paint ourselves into a
>> corner.
>>
>> -igor
>>
>> On Fri, Mar 13, 2009 at 12:31 AM, Igor Vaynberg
>> wrote:
>>> your patch works because it does not properly refactor
>>> Palette#getModelCollection(). you left it us:
>>>
>>> public Collection getModelCollection()
>>> {
>>> return (Collection)getDefaultModelObject();
>>> }
>>>
>>> which is incorrect, it should in fact now return Collection>> T>, which will break Palette#updateModel()
>>>
>>> -igor
>>>
>>> On Thu, Mar 12, 2009 at 11:32 PM, James Carman
>>> wrote:
FYI,
I have created a new JIRA issue for my proposed API changes:
https://issues.apache.org/jira/browse/WICKET-2165
I've attached a patch. I've "fixed" all of the places I could find
thus far. If I find anymore, I'll upload a new patch.
James
On Fri, Mar 13, 2009 at 1:59 AM, James Carman
wrote:
> "Feeding" the list to your component isn't the issue (the constructor
> will take what you throw at it). It's using the
> getDefaultModelObject() method and trying to modify that list once
> you've passed it in that will cause you to have to cast.
>
> On Fri, Mar 13, 2009 at 1:54 AM, Brill Pappin wrote:
>> I'm really not sure of all the use-cases... all I know is that I
>> spent some
>> time trying to get the darn thing to compile using a fairly basic
>> wicket
>> pattern.
>>
>> If such a simple thing as feeding a list of items to a component
>> that draws
>> a list using them is going to give me that much trouble (knowing a
>> workaround or not), then there is something definitely broken.
>>
>> - Brill
>>
>> On 13-Mar-09, at 1:43 AM, James Carman wrote:
>>
>>> To be clear, the only potential for breakage is where user code
>>> tries
>>> to modify the returned "model object" (of type List)
>>> without casting it. However, that's a rare usecase (in my opinion)
>>> and again it's easily overcome by a simple cast.
>>>
>>> On Thu, Mar 12, 2009 at 5:10 PM, Igor Vaynberg
>>>
>>> wrote:
before app
Re: Refresh an invisible component via ajax
Daniele, Try setOutputMarkupPlaceholderTag(true). Regards - Cemal http://jWeekend.com jWeekend Daniele Dellafiore wrote: > > Hi. > Today again I lost some time cause a panel was not being refresh after > being correctly added to AjaxRequestTarget. > > The reason is one I already know but forgot: if the panel is invisible > when the page is rendered, it's html is not rendered at all so you are > calling a refresh on a Component without any DOM connection. . > > I think that this should result in some sort of exception, instead > wicket (as of 1.3.3) do not tell anything. > > Maybe this problem is already being discussed/addressed/solved, I have > searched and found nothing specific. If so, please point me to the > jira issue or something. > > Thanks. > > -- > Daniele Dellafiore > http://blog.ildella.net/ > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > > -- View this message in context: http://www.nabble.com/Refresh-an-invisible-component-via-ajax-tp22501008p22501202.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Refresh an invisible component via ajax
Hi. Today again I lost some time cause a panel was not being refresh after being correctly added to AjaxRequestTarget. The reason is one I already know but forgot: if the panel is invisible when the page is rendered, it's html is not rendered at all so you are calling a refresh on a Component without any DOM connection. . I think that this should result in some sort of exception, instead wicket (as of 1.3.3) do not tell anything. Maybe this problem is already being discussed/addressed/solved, I have searched and found nothing specific. If so, please point me to the jira issue or something. Thanks. -- Daniele Dellafiore http://blog.ildella.net/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Security in a Spring & Wicket layered application
we just finished (yesterday) to implement authorization in a wicket app.
basically, we end up with integration of WASP, Spring Security and a
little beat of SWARM with a home made User-Group-Permission mechanism
that is really simple and string based, and persisted on DB (via
hibernate)
We have an implementation of WaspAuthorizationStrategy with basicalle
login, logoff and this other method implemented:
@Override
public boolean isComponentAuthorized(Component component,
WaspAction action) {
if (component instanceof SecureWebPage) {
return isUserAuthenticated();
}
return checkPermission(component, action);
}
in our app, authenticated user can see all pages (so the first if),
but some component can have further restrictions, there is the
second method that goes into out custom permission check. In that
method, we ask spring the Authentication in the session, so we get the
User (a custom class) and from there we can check permissions.
If you are interested, I can write a more specific essay on our implementation.
I am happy with that becouse it integrates with wicket and spring
security using some of the mechanism and facility but without being a
slave of the framework, so the granularity of authorization is
completely domain-side and so are the permission definitions.
In the end, define a permission on a button you now need just to
change a Button with a SecureButton (that has a very trivial
implementation). Then we create a Permission on the DB (a string) for
that button in some specific Page and assign the Permission to some
group. That's it.
We stayed away from SWARM and its hive replacing it with a simpler
home made mechanism. We just use the SwarmAction to have the "access,
render, enable" granularity for components already built in.
Permission implemented the Spring Security interface called
GrantedAuthority, that is the way spring guys calls permissions. In
fact, both are just a string and we are perfectly integrated.
For the point:
. Authorization before being able to run methods in the service layer
I think that spring security is the way to go, it allows use AOP to
restrict a method call, with also filtering and so on. I had not the
change to experiment with it actually, but I know it can for sure :)
On Sun, Mar 8, 2009 at 5:20 PM, Kent Larsson wrote:
> Hi,
>
> I know there has been some discussion on this. But I've had a hard
> time deciding how this project should use security anyway.
>
> The application in question is layered into three layers for
> presentation, services and persistence using Wicket, Spring and
> Hibernate.
>
> What we need:
> - Authentication
> - Authorization on pages, components
> - Authorization before being able to run methods in the service layer
> - Authorization for viewing/editing some domain objects using Access
> Control List's (ACL's)
>
> I have read Wicket in Action and it's custom security solution has some pros:
> - It's quite easy to understand
> - We have a lot of freedom in how to do authentication and authorization
>
> And some cons:
> - I don't know how to authorize calls of specific methods, and thus
> - All security will be in the presentation layer
> - It won't be usable if we want security on web services later (which
> we do not need now, so maybe this can be disregarded)
>
> It would be nice if we could have a common solution to our security
> needs that integrates well with Wicket and Spring. I know that the
> Auth Roles project is out there as well as Swarm. But I don't know
> which will meet our needs and which will most likely be an option to
> us when we later move to Wicket 1.4 or a higher version.
>
> Best regards,
> Kent
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
--
Daniele Dellafiore
http://blog.ildella.net/
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: can we get this patch applied to the current snapshot?
T has to be a list of some sort in this case and you would want to
convey that in your API. Are you wanting T to be the element type
here or the list type itself. I'm really having a hard time following
what you're trying to do here. What type parameter are you passing
into your listview?
On Fri, Mar 13, 2009 at 11:53 AM, Igor Vaynberg wrote:
> the problem remains.
>
> lets say we change listview to take imodel>
>
> i want to do something like this:
>
> class listmanger extends panel {
> public listmanager(string id, imodel entries) {
> addformtoaddtems();
> add(new listview("list", entities));
> ^ wont compile because you cant assign imodel to imodel extends list> so we have to cast???
>
> -igor
>
> On Fri, Mar 13, 2009 at 8:02 AM, James Carman
> wrote:
>> Yes, but that's fine. The idea is that I want to collect a
>> List, but I want to choose from a List. That
>> should be allowed.
>>
>>
>> On Fri, Mar 13, 2009 at 10:42 AM, Igor Vaynberg
>> wrote:
>>> so then again you are back to something taking imodel> and a
>>> widened version in the same constructor.
>>>
>>> -igor
>>>
>>> On Fri, Mar 13, 2009 at 3:54 AM, James Carman
>>> wrote:
Again, ListMultipleChoice is okay in this instance. You don't want to
"widen" the model. You want to widen what can go in it (the choices),
which I have.
On Fri, Mar 13, 2009 at 3:40 AM, Igor Vaynberg
wrote:
> taking ListMultipleChoice as another example, your patch leaves it us
>
> public class ListMultipleChoice extends AbstractChoice,
> T>
>
> when in fact it should be properly declared as
>
> public class ListMultipleChoice extends AbstractChoice extends T>, T>
>
> so that getModelObject() properly returns Collection
> instead of the unsafe variant Collection
>
> which, once again, will break updatemodel()
>
> in your experience you havent ran into a situation where a component
> updates its collection model object. my experience is quiet the
> opposite. just trying to make sure we do not paint ourselves into a
> corner.
>
> -igor
>
> On Fri, Mar 13, 2009 at 12:31 AM, Igor Vaynberg
> wrote:
>> your patch works because it does not properly refactor
>> Palette#getModelCollection(). you left it us:
>>
>> public Collection getModelCollection()
>> {
>> return (Collection)getDefaultModelObject();
>> }
>>
>> which is incorrect, it should in fact now return Collection> T>, which will break Palette#updateModel()
>>
>> -igor
>>
>> On Thu, Mar 12, 2009 at 11:32 PM, James Carman
>> wrote:
>>> FYI,
>>>
>>> I have created a new JIRA issue for my proposed API changes:
>>>
>>> https://issues.apache.org/jira/browse/WICKET-2165
>>>
>>> I've attached a patch. I've "fixed" all of the places I could find
>>> thus far. If I find anymore, I'll upload a new patch.
>>>
>>> James
>>>
>>> On Fri, Mar 13, 2009 at 1:59 AM, James Carman
>>> wrote:
"Feeding" the list to your component isn't the issue (the constructor
will take what you throw at it). It's using the
getDefaultModelObject() method and trying to modify that list once
you've passed it in that will cause you to have to cast.
On Fri, Mar 13, 2009 at 1:54 AM, Brill Pappin wrote:
> I'm really not sure of all the use-cases... all I know is that I
> spent some
> time trying to get the darn thing to compile using a fairly basic
> wicket
> pattern.
>
> If such a simple thing as feeding a list of items to a component that
> draws
> a list using them is going to give me that much trouble (knowing a
> workaround or not), then there is something definitely broken.
>
> - Brill
>
> On 13-Mar-09, at 1:43 AM, James Carman wrote:
>
>> To be clear, the only potential for breakage is where user code tries
>> to modify the returned "model object" (of type List)
>> without casting it. However, that's a rare usecase (in my opinion)
>> and again it's easily overcome by a simple cast.
>>
>> On Thu, Mar 12, 2009 at 5:10 PM, Igor Vaynberg
>>
>> wrote:
>>>
>>> before applying an api-breaking patch to an rc release we should
>>> have
>>> a vote on the dev list.
>>>
>>> -igor
>>>
>>> On Thu, Mar 12, 2009 at 12:59 PM, Jeremy Thomerson
>>> wrote:
Unless I'm seeing double - this patch has two problems:
1 - It is the opposite of what was voted on. The vote was to make
IModel> into IModel>. Your patch makes
it
IModel>.
2 - The patch causes compile
Re: BaseWicketTester.clickLink call onBeginRequest two times
On Fri, Mar 13, 2009 at 4:33 PM, Igor Vaynberg wrote: > probably has something to do with one of those wickettester-related issues. > > feel free to open a jira issue and provide a test case. ok, just want to be sure that is really strange or wrong that onBeginRequest is called two times in the same click. > > -igor > > On Fri, Mar 13, 2009 at 7:54 AM, Daniele Dellafiore wrote: >> On Fri, Mar 13, 2009 at 3:49 PM, Igor Vaynberg >> wrote: >>> did you look at the 1.3.4 changelog? >> >> yes and I did not see anything related to this specific issue unless >> there are a couple of tickets related to WicketTester. >> >> -- >> Daniele Dellafiore >> http://blog.ildella.net/ >> >> - >> 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 > > -- Daniele Dellafiore http://blog.ildella.net/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: can we get this patch applied to the current snapshot?
the problem remains.
lets say we change listview to take imodel>
i want to do something like this:
class listmanger extends panel {
public listmanager(string id, imodel entries) {
addformtoaddtems();
add(new listview("list", entities));
^ wont compile because you cant assign imodel to imodel> so we have to cast???
-igor
On Fri, Mar 13, 2009 at 8:02 AM, James Carman
wrote:
> Yes, but that's fine. The idea is that I want to collect a
> List, but I want to choose from a List. That
> should be allowed.
>
>
> On Fri, Mar 13, 2009 at 10:42 AM, Igor Vaynberg
> wrote:
>> so then again you are back to something taking imodel> and a
>> widened version in the same constructor.
>>
>> -igor
>>
>> On Fri, Mar 13, 2009 at 3:54 AM, James Carman
>> wrote:
>>> Again, ListMultipleChoice is okay in this instance. You don't want to
>>> "widen" the model. You want to widen what can go in it (the choices),
>>> which I have.
>>>
>>> On Fri, Mar 13, 2009 at 3:40 AM, Igor Vaynberg
>>> wrote:
taking ListMultipleChoice as another example, your patch leaves it us
public class ListMultipleChoice extends AbstractChoice, T>
when in fact it should be properly declared as
public class ListMultipleChoice extends AbstractChoice>>> extends T>, T>
so that getModelObject() properly returns Collection
instead of the unsafe variant Collection
which, once again, will break updatemodel()
in your experience you havent ran into a situation where a component
updates its collection model object. my experience is quiet the
opposite. just trying to make sure we do not paint ourselves into a
corner.
-igor
On Fri, Mar 13, 2009 at 12:31 AM, Igor Vaynberg
wrote:
> your patch works because it does not properly refactor
> Palette#getModelCollection(). you left it us:
>
> public Collection getModelCollection()
> {
> return (Collection)getDefaultModelObject();
> }
>
> which is incorrect, it should in fact now return Collection T>, which will break Palette#updateModel()
>
> -igor
>
> On Thu, Mar 12, 2009 at 11:32 PM, James Carman
> wrote:
>> FYI,
>>
>> I have created a new JIRA issue for my proposed API changes:
>>
>> https://issues.apache.org/jira/browse/WICKET-2165
>>
>> I've attached a patch. I've "fixed" all of the places I could find
>> thus far. If I find anymore, I'll upload a new patch.
>>
>> James
>>
>> On Fri, Mar 13, 2009 at 1:59 AM, James Carman
>> wrote:
>>> "Feeding" the list to your component isn't the issue (the constructor
>>> will take what you throw at it). It's using the
>>> getDefaultModelObject() method and trying to modify that list once
>>> you've passed it in that will cause you to have to cast.
>>>
>>> On Fri, Mar 13, 2009 at 1:54 AM, Brill Pappin wrote:
I'm really not sure of all the use-cases... all I know is that I spent
some
time trying to get the darn thing to compile using a fairly basic
wicket
pattern.
If such a simple thing as feeding a list of items to a component that
draws
a list using them is going to give me that much trouble (knowing a
workaround or not), then there is something definitely broken.
- Brill
On 13-Mar-09, at 1:43 AM, James Carman wrote:
> To be clear, the only potential for breakage is where user code tries
> to modify the returned "model object" (of type List)
> without casting it. However, that's a rare usecase (in my opinion)
> and again it's easily overcome by a simple cast.
>
> On Thu, Mar 12, 2009 at 5:10 PM, Igor Vaynberg
>
> wrote:
>>
>> before applying an api-breaking patch to an rc release we should have
>> a vote on the dev list.
>>
>> -igor
>>
>> On Thu, Mar 12, 2009 at 12:59 PM, Jeremy Thomerson
>> wrote:
>>>
>>> Unless I'm seeing double - this patch has two problems:
>>>
>>> 1 - It is the opposite of what was voted on. The vote was to make
>>> IModel> into IModel>. Your patch makes it
>>> IModel>.
>>>
>>> 2 - The patch causes compile errors that were not fixed.
>>>
>>> I have unassigned myself from the task until those issues are
>>> addressed
>>> or I
>>> have time to create my own patch. The best solution would be for
>>> someone to
>>> submit a proper patch that fixes the two problems above or explain
>>> to me
>>> what I missed.
>>>
>>> Thanks!
>>>
>>> --
>>> Jeremy Thomerson
>>> http://www.wickettraining.com
>>>
>>>
>
Re: wicketstuff-jamon
I started it and left it in a very basic state, mainly because of my lack of css skills. It is funcationally usable and checked in. See the JamonAdminPage. Lars On Fri, Mar 13, 2009 at 2:42 PM, shetc wrote: > > Thanks, Lars. I also have seen a null monitor as well, and was going to > look > into that -- I'll let > you know how I get on. Did you finish Wicketising the Admin pages? > -- > View this message in context: > http://www.nabble.com/wicketstuff-jamon-tp16125597p22496658.html > Sent from the Wicket - User mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: BaseWicketTester.clickLink call onBeginRequest two times
probably has something to do with one of those wickettester-related issues. feel free to open a jira issue and provide a test case. -igor On Fri, Mar 13, 2009 at 7:54 AM, Daniele Dellafiore wrote: > On Fri, Mar 13, 2009 at 3:49 PM, Igor Vaynberg > wrote: >> did you look at the 1.3.4 changelog? > > yes and I did not see anything related to this specific issue unless > there are a couple of tickets related to WicketTester. > > -- > Daniele Dellafiore > http://blog.ildella.net/ > > - > 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: Possible to retrieve previous page from PageMap
igor, i would agree with you if i wanted to mimic the browser back
button functionality.
but i do not. we intensively use panel swapping and we're only
interested in registering when users click on certain pages (we can
fine-tune pages which pages should be "back-clickable").
we actually considered using history.go(-1), but if you want your app
to seriously take into account usability / user experience, it's
useless -- for instance think panel swapping, or rendering links such
as "back to your search for ice-cream". personally i'm not someone who
likes complexity just for the sake of it.
francisco
On Fri, Mar 13, 2009 at 3:43 PM, Igor Vaynberg wrote:
> its really a lot of work to duplicate what the back button in the
> browser already does. or a simple onclick="history.go(-1)">back will do as well.
>
> -igor
>
> On Fri, Mar 13, 2009 at 5:02 AM, francisco treacy
> wrote:
>> to be honest i haven't read the whole thread, but we are also trying
>> to achieve roughly the same thing.
>>
>> as of wicket 1.4-m1 there is a class called PageId that you may want
>> to consider.
>>
>> i created a "back state holder" class that holds a PageId and an
>> IModel for the text of the back link. so for every visited
>> page (in the onBeforeRender - could be placed in the base page), we
>> set a holder in the session and in our base page we call
>> Session.get.getHolder. pretty simple really.
>> as the PageId class is a unique identifier of the page you can use it
>> to distinguish between pagemaps, etc. (so navigation doesn't interfere
>> between tabs / windows)
>>
>> this fulfills our usecase, as this is just a helper link to "go back
>> where you were". we don't completely rely on this link because we also
>> do keep traditional navigation links in our pages.
>>
>> however i still need to solve the double click problem, i.e. if a user
>> clicks twice on a link, the last rendered page will be the same as the
>> one he is in. thus, the back link points to the same page. it is
>> actually quite tricky to get it right, yet i believe possible. i will
>> definitely try to avoid the link handing over pageparams in the url
>> "like in the good old days" :)
>>
>> i will post it once i get everything working together.
>>
>> francisco
>>
>>
>>
>>
>>
>> On Fri, Mar 13, 2009 at 10:29 AM, pixologe wrote:
>>>
>>> Just a thought which I did not think about when implementing this (thus I
>>> had
>>> to change this stuff all over afterwards), perhaps it helps someone avoiding
>>> the same mistake:
>>>
>>> The latest rendered page is not neccessarily the page that lead the user to
>>> the current page.
>>> I.e. retrieving the last page this way might result in strange behavior if
>>> the user uses two browser windows or tabs simulaneously. Same applies for
>>> clicking the browser's back button.
>>>
>>> Thus I had to go back to a rather old-fashioned solution, where every link
>>> hands over a page param :-/ like in the good old days ;-)
>>>
>>>
>>>
>>>
>>>
>>> rolandpeng wrote:
great! after delare a ineer class below:
class PageIdVersion {
public int id;
public int version;
public PageIdVersion last;
}
then the track function works.
John Patterson wrote:
>
>
> // must declare hash map because meta data must be serializable
> private MetaDataKey>
> lastPageIdVersionKey
> = new MetaDataKey>() {};
>
>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Possible-to-retrieve-previous-page-from-PageMap-tp20861106p22492628.html
>>> Sent from the Wicket - User mailing list archive at Nabble.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
>>
>>
>
> -
> 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: Have a feature, want to contribute
Marat, as you can see people are interested and waiting for this feature to be published somewhere Alex Marat Radchenko-2 wrote: > > Wicket pages/components can be either stateful or stateless. Wicket > manages hem transparently and it is very easy to write any complex > page you want. Stateful pages are much more powerful than stateless. > However that comes at a cost of using page store for their state. On > highload sites it is usually desired to minimize session-scope data, > and move it to request-scope. That's when Wicket users approach a task > of making stateful pages stateless. However stateless state (sic!) is > very fragile, if you add a single stateful component to a page, it > instantly becomes stateful (and you even might not notice that if your > other page content can work in both modes. And here comes my lovely > feature - @StatelessComponent. It is an annotation that you should put > on components which you want to be stateless. It doesn't do any magic, > it simply uses postComponentOnBeforeRender to assert that annotated > component (and all its children) are stateless. If it doesn't, an > exception is thrown, indicating what component tries to be stateful. > > This feature isn't large enough to be put in a separate project (just > one annotation and one listener) but wee find it extremely useful on > our project. > > I'd be happy to give it to Wicket project (or wicketstuff?) at > absolutely no cost (tests included) under same license as wicket > itself, if Wicket developers are interested in it. > > I'll file a feature request with a patch, if Wicket team finds this > useful in Wicket core. > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > > -- View this message in context: http://www.nabble.com/Have-a-feature%2C-want-to-contribute-tp21079751p22498471.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: can we get this patch applied to the current snapshot?
Yes, but that's fine. The idea is that I want to collect a
List, but I want to choose from a List. That
should be allowed.
On Fri, Mar 13, 2009 at 10:42 AM, Igor Vaynberg wrote:
> so then again you are back to something taking imodel> and a
> widened version in the same constructor.
>
> -igor
>
> On Fri, Mar 13, 2009 at 3:54 AM, James Carman
> wrote:
>> Again, ListMultipleChoice is okay in this instance. You don't want to
>> "widen" the model. You want to widen what can go in it (the choices),
>> which I have.
>>
>> On Fri, Mar 13, 2009 at 3:40 AM, Igor Vaynberg
>> wrote:
>>> taking ListMultipleChoice as another example, your patch leaves it us
>>>
>>> public class ListMultipleChoice extends AbstractChoice, T>
>>>
>>> when in fact it should be properly declared as
>>>
>>> public class ListMultipleChoice extends AbstractChoice>> extends T>, T>
>>>
>>> so that getModelObject() properly returns Collection
>>> instead of the unsafe variant Collection
>>>
>>> which, once again, will break updatemodel()
>>>
>>> in your experience you havent ran into a situation where a component
>>> updates its collection model object. my experience is quiet the
>>> opposite. just trying to make sure we do not paint ourselves into a
>>> corner.
>>>
>>> -igor
>>>
>>> On Fri, Mar 13, 2009 at 12:31 AM, Igor Vaynberg
>>> wrote:
your patch works because it does not properly refactor
Palette#getModelCollection(). you left it us:
public Collection getModelCollection()
{
return (Collection)getDefaultModelObject();
}
which is incorrect, it should in fact now return Collection>>> T>, which will break Palette#updateModel()
-igor
On Thu, Mar 12, 2009 at 11:32 PM, James Carman
wrote:
> FYI,
>
> I have created a new JIRA issue for my proposed API changes:
>
> https://issues.apache.org/jira/browse/WICKET-2165
>
> I've attached a patch. I've "fixed" all of the places I could find
> thus far. If I find anymore, I'll upload a new patch.
>
> James
>
> On Fri, Mar 13, 2009 at 1:59 AM, James Carman
> wrote:
>> "Feeding" the list to your component isn't the issue (the constructor
>> will take what you throw at it). It's using the
>> getDefaultModelObject() method and trying to modify that list once
>> you've passed it in that will cause you to have to cast.
>>
>> On Fri, Mar 13, 2009 at 1:54 AM, Brill Pappin wrote:
>>> I'm really not sure of all the use-cases... all I know is that I spent
>>> some
>>> time trying to get the darn thing to compile using a fairly basic wicket
>>> pattern.
>>>
>>> If such a simple thing as feeding a list of items to a component that
>>> draws
>>> a list using them is going to give me that much trouble (knowing a
>>> workaround or not), then there is something definitely broken.
>>>
>>> - Brill
>>>
>>> On 13-Mar-09, at 1:43 AM, James Carman wrote:
>>>
To be clear, the only potential for breakage is where user code tries
to modify the returned "model object" (of type List)
without casting it. However, that's a rare usecase (in my opinion)
and again it's easily overcome by a simple cast.
On Thu, Mar 12, 2009 at 5:10 PM, Igor Vaynberg
wrote:
>
> before applying an api-breaking patch to an rc release we should have
> a vote on the dev list.
>
> -igor
>
> On Thu, Mar 12, 2009 at 12:59 PM, Jeremy Thomerson
> wrote:
>>
>> Unless I'm seeing double - this patch has two problems:
>>
>> 1 - It is the opposite of what was voted on. The vote was to make
>> IModel> into IModel>. Your patch makes it
>> IModel>.
>>
>> 2 - The patch causes compile errors that were not fixed.
>>
>> I have unassigned myself from the task until those issues are
>> addressed
>> or I
>> have time to create my own patch. The best solution would be for
>> someone to
>> submit a proper patch that fixes the two problems above or explain
>> to me
>> what I missed.
>>
>> Thanks!
>>
>> --
>> Jeremy Thomerson
>> http://www.wickettraining.com
>>
>>
>>
>> On Thu, Mar 12, 2009 at 2:53 PM, Jeremy Thomerson
>> >>
>>> wrote:
>>
>>> I'm reviewing it now. Assuming that it looks fine, and is line with
>>> what
>>> was proposed by the vote thread earlier, I will apply. The vote
>>> passed, so
>>> I don't see a reason not to. I'm not sure how many were binding /
>>> non-binding, but there were eight for, two against.
>>>
>>> --
>>> Jeremy Thomerson
>>> http://www.wi
Re: BaseWicketTester.clickLink call onBeginRequest two times
On Fri, Mar 13, 2009 at 3:49 PM, Igor Vaynberg wrote: > did you look at the 1.3.4 changelog? yes and I did not see anything related to this specific issue unless there are a couple of tickets related to WicketTester. -- Daniele Dellafiore http://blog.ildella.net/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: BaseWicketTester.clickLink call onBeginRequest two times
did you look at the 1.3.4 changelog? -igor On Fri, Mar 13, 2009 at 6:40 AM, Daniele Dellafiore wrote: > Hi. > > I am trying to upgrade an application from wicket 1.3.3 to 1.3.4 or .5 > some tests I have failse couse the new BaseWicketTester implementation > treat the AjaxLink in a different way that results in > RequestCycle.onBeginRequest to be called two times: > > callOnBeginRequest(requestCycle); > processRequestCycle(requestCycle); > > In the other statement of the clickLink, this does not happen. > > Any idea on why it works this way? > > -- > Daniele Dellafiore > http://blog.ildella.net/ > > - > 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: [NEWBEE] How to get a property from context-param ?
see webapplication#getservletcontext, as far as system props a simple System#getProperty() will do -igor On Fri, Mar 13, 2009 at 6:08 AM, Ista Pouss wrote: > Hi, > > How is it possible to get a key from the context-param from web.xml in wicket > ? > > Or how is it possible to set some systems properties in a wicket webapp ? > > Thank for your help. > > - > 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: Propper Way to Use StringResourceModel
each component is a resource bundle, not a model. you can use component's getstring(..) to read any resource you want. -igor On Fri, Mar 13, 2009 at 4:19 AM, Daniel Ferreira Castro wrote: > I have seen some examples of Pages that uses the StringResourceModel to read > properties inside property files. But the examples that I saw shows that I > need to create a StringResourceModel for each property that is inside my > property file. So, If I have a Login page that have 3 properties, like > login.username , login.password and login.button I must create also 3 > StringResourceModels and use each one on the constructor of the Labels. > > I do not think it is a practical solution because I see the > StringResourceModel as a ResourceBundle. > > Am I right? What is the real deal when using it? > Is it the propper way to internationalize a resource? > Is there a way to make a single StringResourceModel and use it to read a > property file so, instead of creating several resources I create a single > one and pass the key that I wanna retrieve its value? > > -- > "Two rules to succeed in life: > 1 - don´t tell people everything you know." > > We shall go on to the end. > We shall fight in France > We shall fightover the seas and oceans. > We shall fight with growing confidence and growing strength in the air. > We shall defend our island whatever the cost may be > We shall fight on beaches, we shall fight on the landing grounds, > We shall fight in the fields and in the streets, > We shall fight on the hills. > We shall never surrender. > Winston Churchill > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Base64UrlSafe violating RFC 3548?
feel free to file a bug report. -igor On Fri, Mar 13, 2009 at 1:28 AM, Jonas wrote: > Hi, > > I recently stumbled across Base64UrlSafe, which claims > 'Provides Base64 encoding and decoding with URL and filename safe > alphabet as defined by RFC 3548, section 4.' > In the mentioned section of the RFC [1], they use the '-' character > for value 62 and '_' for value 63. > Strangely, Base64UrlSafe uses '*' for 62 and '-' for 63. Is there any > particular reason why it > doesn't follow the RFC? > > Cheers, > Jonas > > [1] http://www.faqs.org/rfcs/rfc3548.html > > - > 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: Possible to retrieve previous page from PageMap
its really a lot of work to duplicate what the back button in the
browser already does. or a simple back will do as well.
-igor
On Fri, Mar 13, 2009 at 5:02 AM, francisco treacy
wrote:
> to be honest i haven't read the whole thread, but we are also trying
> to achieve roughly the same thing.
>
> as of wicket 1.4-m1 there is a class called PageId that you may want
> to consider.
>
> i created a "back state holder" class that holds a PageId and an
> IModel for the text of the back link. so for every visited
> page (in the onBeforeRender - could be placed in the base page), we
> set a holder in the session and in our base page we call
> Session.get.getHolder. pretty simple really.
> as the PageId class is a unique identifier of the page you can use it
> to distinguish between pagemaps, etc. (so navigation doesn't interfere
> between tabs / windows)
>
> this fulfills our usecase, as this is just a helper link to "go back
> where you were". we don't completely rely on this link because we also
> do keep traditional navigation links in our pages.
>
> however i still need to solve the double click problem, i.e. if a user
> clicks twice on a link, the last rendered page will be the same as the
> one he is in. thus, the back link points to the same page. it is
> actually quite tricky to get it right, yet i believe possible. i will
> definitely try to avoid the link handing over pageparams in the url
> "like in the good old days" :)
>
> i will post it once i get everything working together.
>
> francisco
>
>
>
>
>
> On Fri, Mar 13, 2009 at 10:29 AM, pixologe wrote:
>>
>> Just a thought which I did not think about when implementing this (thus I had
>> to change this stuff all over afterwards), perhaps it helps someone avoiding
>> the same mistake:
>>
>> The latest rendered page is not neccessarily the page that lead the user to
>> the current page.
>> I.e. retrieving the last page this way might result in strange behavior if
>> the user uses two browser windows or tabs simulaneously. Same applies for
>> clicking the browser's back button.
>>
>> Thus I had to go back to a rather old-fashioned solution, where every link
>> hands over a page param :-/ like in the good old days ;-)
>>
>>
>>
>>
>>
>> rolandpeng wrote:
>>>
>>> great! after delare a ineer class below:
>>> class PageIdVersion {
>>> public int id;
>>> public int version;
>>> public PageIdVersion last;
>>> }
>>> then the track function works.
>>>
>>>
>>> John Patterson wrote:
// must declare hash map because meta data must be serializable
private MetaDataKey>
lastPageIdVersionKey
= new MetaDataKey>() {};
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Possible-to-retrieve-previous-page-from-PageMap-tp20861106p22492628.html
>> Sent from the Wicket - User mailing list archive at Nabble.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
>
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: can we get this patch applied to the current snapshot?
so then again you are back to something taking imodel> and a
widened version in the same constructor.
-igor
On Fri, Mar 13, 2009 at 3:54 AM, James Carman
wrote:
> Again, ListMultipleChoice is okay in this instance. You don't want to
> "widen" the model. You want to widen what can go in it (the choices),
> which I have.
>
> On Fri, Mar 13, 2009 at 3:40 AM, Igor Vaynberg
> wrote:
>> taking ListMultipleChoice as another example, your patch leaves it us
>>
>> public class ListMultipleChoice extends AbstractChoice, T>
>>
>> when in fact it should be properly declared as
>>
>> public class ListMultipleChoice extends AbstractChoice> extends T>, T>
>>
>> so that getModelObject() properly returns Collection
>> instead of the unsafe variant Collection
>>
>> which, once again, will break updatemodel()
>>
>> in your experience you havent ran into a situation where a component
>> updates its collection model object. my experience is quiet the
>> opposite. just trying to make sure we do not paint ourselves into a
>> corner.
>>
>> -igor
>>
>> On Fri, Mar 13, 2009 at 12:31 AM, Igor Vaynberg
>> wrote:
>>> your patch works because it does not properly refactor
>>> Palette#getModelCollection(). you left it us:
>>>
>>> public Collection getModelCollection()
>>> {
>>> return (Collection)getDefaultModelObject();
>>> }
>>>
>>> which is incorrect, it should in fact now return Collection>> T>, which will break Palette#updateModel()
>>>
>>> -igor
>>>
>>> On Thu, Mar 12, 2009 at 11:32 PM, James Carman
>>> wrote:
FYI,
I have created a new JIRA issue for my proposed API changes:
https://issues.apache.org/jira/browse/WICKET-2165
I've attached a patch. I've "fixed" all of the places I could find
thus far. If I find anymore, I'll upload a new patch.
James
On Fri, Mar 13, 2009 at 1:59 AM, James Carman
wrote:
> "Feeding" the list to your component isn't the issue (the constructor
> will take what you throw at it). It's using the
> getDefaultModelObject() method and trying to modify that list once
> you've passed it in that will cause you to have to cast.
>
> On Fri, Mar 13, 2009 at 1:54 AM, Brill Pappin wrote:
>> I'm really not sure of all the use-cases... all I know is that I spent
>> some
>> time trying to get the darn thing to compile using a fairly basic wicket
>> pattern.
>>
>> If such a simple thing as feeding a list of items to a component that
>> draws
>> a list using them is going to give me that much trouble (knowing a
>> workaround or not), then there is something definitely broken.
>>
>> - Brill
>>
>> On 13-Mar-09, at 1:43 AM, James Carman wrote:
>>
>>> To be clear, the only potential for breakage is where user code tries
>>> to modify the returned "model object" (of type List)
>>> without casting it. However, that's a rare usecase (in my opinion)
>>> and again it's easily overcome by a simple cast.
>>>
>>> On Thu, Mar 12, 2009 at 5:10 PM, Igor Vaynberg
>>> wrote:
before applying an api-breaking patch to an rc release we should have
a vote on the dev list.
-igor
On Thu, Mar 12, 2009 at 12:59 PM, Jeremy Thomerson
wrote:
>
> Unless I'm seeing double - this patch has two problems:
>
> 1 - It is the opposite of what was voted on. The vote was to make
> IModel> into IModel>. Your patch makes it
> IModel>.
>
> 2 - The patch causes compile errors that were not fixed.
>
> I have unassigned myself from the task until those issues are
> addressed
> or I
> have time to create my own patch. The best solution would be for
> someone to
> submit a proper patch that fixes the two problems above or explain to
> me
> what I missed.
>
> Thanks!
>
> --
> Jeremy Thomerson
> http://www.wickettraining.com
>
>
>
> On Thu, Mar 12, 2009 at 2:53 PM, Jeremy Thomerson
> >
>> wrote:
>
>> I'm reviewing it now. Assuming that it looks fine, and is line with
>> what
>> was proposed by the vote thread earlier, I will apply. The vote
>> passed, so
>> I don't see a reason not to. I'm not sure how many were binding /
>> non-binding, but there were eight for, two against.
>>
>> --
>> Jeremy Thomerson
>> http://www.wickettraining.com
>>
>>
>>
>>
>> On Thu, Mar 12, 2009 at 9:52 AM, Brill Pappin
>> wrote:
>>
>>> https://issues.apache.org/jira/browse/WICKET-2137
>>>
>>> - Brill
>>>
>>> -
>
Re: building a wicket app with maven 1
mvn dependency:tree is your friend -Igor On 3/13/09, Stephen Swinsburg wrote: > Spot on, it's been a while since I've done Maven1 work and this has > caught me out previously I just didn't think of it this time! I'll > double check the jars that are in my Maven2 webapp and presume I will > find that jar missing from the Maven1 build. > > Thanks Linda and Adriano! > > > On 13/03/2009, at 8:05 AM, Linda van der Pal wrote: > >> Maven2 handles transitive dependencies, meaning that if a project >> you are dependent on is dependent on other projects, Maven will add >> them to the classpath. So that's why you didn't have to add that jar >> manually, Maven did it for you. I don't think Maven1 had this >> functionality. >> >> Linda >> >> Stephen Swinsburg wrote: >>> Thanks Adriano. I don't seem to need that for my Maven2 build >>> though, is there a reason for that? I'll try that though. >>> >>> >>> cheers, >>> Steve >>> >>> >>> >>> On 12/03/2009, at 8:02 PM, Adriano dos Santos Fernandes wrote: >>> Steve Swinsburg escreveu: > Hi all, > > I have a need to backport my wicket app that builds perfectly in > Maven2 to Maven1. I think I've adjusted all the pom.xml to > project.xml correctly as all the classes and dependent jars looks > like they are where they need to be, but on startup I get this: > > java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory > > Although in my WEB-INF/lib I have (amongst the others) the > required jars: > > slf4j-log4j12-1.4.2.jar > log4j-1.2.14.jar > > > Any idea what's missing? Does anyone else build under Maven1? You also need slf4j-api-*.jar. Adriano - 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 >>> >>> >>> >>> No virus found in this incoming message. >>> Checked by AVG - www.avg.com Version: 8.5.278 / Virus Database: >>> 270.11.10/1996 - Release Date: 03/11/09 20:42:00 >>> >>> >> >> >> - >> 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: Have a feature, want to contribute
Sounds very useful ! -especially in development model. We've spent much time debugging and searching for the one "stateful" component/behavior - in our large page hierarchies ! Marat Radchenko-2 wrote: > > Wicket pages/components can be either stateful or stateless. Wicket > manages hem transparently and it is very easy to write any complex > page you want. Stateful pages are much more powerful than stateless. > However that comes at a cost of using page store for their state. On > highload sites it is usually desired to minimize session-scope data, > and move it to request-scope. That's when Wicket users approach a task > of making stateful pages stateless. However stateless state (sic!) is > very fragile, if you add a single stateful component to a page, it > instantly becomes stateful (and you even might not notice that if your > other page content can work in both modes. And here comes my lovely > feature - @StatelessComponent. It is an annotation that you should put > on components which you want to be stateless. It doesn't do any magic, > it simply uses postComponentOnBeforeRender to assert that annotated > component (and all its children) are stateless. If it doesn't, an > exception is thrown, indicating what component tries to be stateful. > > This feature isn't large enough to be put in a separate project (just > one annotation and one listener) but wee find it extremely useful on > our project. > > I'd be happy to give it to Wicket project (or wicketstuff?) at > absolutely no cost (tests included) under same license as wicket > itself, if Wicket developers are interested in it. > > I'll file a feature request with a patch, if Wicket team finds this > useful in Wicket core. > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > > -- View this message in context: http://www.nabble.com/Have-a-feature%2C-want-to-contribute-tp21079751p22496841.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: wicketstuff-jamon
Thanks, Lars. I also have seen a null monitor as well, and was going to look into that -- I'll let you know how I get on. Did you finish Wicketising the Admin pages? -- View this message in context: http://www.nabble.com/wicketstuff-jamon-tp16125597p22496658.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
BaseWicketTester.clickLink call onBeginRequest two times
Hi. I am trying to upgrade an application from wicket 1.3.3 to 1.3.4 or .5 some tests I have failse couse the new BaseWicketTester implementation treat the AjaxLink in a different way that results in RequestCycle.onBeginRequest to be called two times: callOnBeginRequest(requestCycle); processRequestCycle(requestCycle); In the other statement of the clickLink, this does not happen. Any idea on why it works this way? -- Daniele Dellafiore http://blog.ildella.net/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Large Scale Applications using Wicket
Yeah as people say, it's the business logic that will really be the bottleneck.. 2009/3/13 Willis Blackburn > I don't think that page serialization is going to be your bottleneck. > > I don't know what you're thinking when you say "large scale." Some folks > think "large scale" means two server and others think Travelocity or Google. > I developed a system in PHP that served about 20-50 pages per second. This > was PHP 4. I don't know if things are different now, but in PHP 4, the PHP > module interpreted every PHP page from scratch, loaded the session state > from disk, rendered the page, and wrote the session state back to disk, with > every request. The time required to serialize the session to the disk and > read it back every time was negligible. > > I suggest you write your Wicket app first, then analyze the performance and > determine what you need to optimize. It almost certainly won't be the > serialization. It will be your own code: mostly database access and > synchronized blocks. > > W > > > > > On Mar 12, 2009, at 11:52 PM, subbu_tce wrote: > > >> Do we have any Clustering Solutions other than Terracotta that can >> integrate >> with Wicket to avoid serialization of pages to support development of >> applications in a large scale? >> >> Thanks, >> Subbu. >> -- >> View this message in context: >> http://www.nabble.com/Large-Scale-Applications-using-Wicket-tp22489752p22489752.html >> Sent from the Wicket - User mailing list archive at Nabble.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: wicketstuff-jamon
Hi Steve, I haven't worked on the code for a while, so feel free to commit, change or adjust it the way you like. I have used in in production code without problems. It is pretty monkey proof, so even if it fails it wont intervene with the normal process. The only thing that can "break" is the monitoring itself, I have seen Monitors with the name null from time to time but have never figured out what caused that. Regards, Lars 2009/3/12 shetc > > Hi Lars, > > Your Jamon implementation looks very good and I was able to easily > integrate > it with my Wicket > project. Please tell me what the current status of this code is, and will > it > be okay to add it to > a production application? > > Thanks, > Steve > -- > View this message in context: > http://www.nabble.com/wicketstuff-jamon-tp16125597p22476908.html > Sent from the Wicket - User mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
[NEWBEE] How to get a property from context-param ?
Hi, How is it possible to get a key from the context-param from web.xml in wicket ? Or how is it possible to set some systems properties in a wicket webapp ? Thank for your help. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: onComponentTag not processed for visible=false?
Well.. there is no such thing as a nested form in HTML so why lying to your children is better? ;) ** Martin 2009/3/13 Jeremy Thomerson : > Think of the children! :) When your children grow up and become > programmers and take over your code, they open it and see > - is that very clear? > > Wicket should enforce a form being rendered only with a form tag - that > makes sense. > > -- > Jeremy Thomerson > http://www.wickettraining.com > > > > On Fri, Mar 13, 2009 at 4:15 AM, Martin Makundi < > martin.maku...@koodaripalvelut.com> wrote: > >> > What is the use of being able to attach a form to a ? There is >> > absolutely NONE. >> >> Not necessary TABLE but it is very useful to replace with, for example TR. >> >> ** >> Martin >> >> > >> > On Fri, Mar 13, 2009 at 10:02 AM, Martin Makundi >> > wrote: >> I wonder if (nested) forms should simply be allowed to have any tag >> name the programmer desires? >> >>> >> >>> No. Because 99% of the time the programmer is not aware that the form >> >>> is used in a nested fashion: the form usually is on a Panel, that is >> >>> used inside another form. The panel is standalone and should use form >> >>> tags. >> >> >> >> Yes, but there is no harm done if it is ALLOWED to have another tag >> >> name. If the user uses > >> compatibility would take care of replacing with . >> >> >> >> ** >> >> Martin >> >> >> >> - >> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> >> >> >> > >> > >> > >> > -- >> > Become a Wicket expert, learn from the best: http://wicketinaction.com >> > Apache Wicket 1.3.5 is released >> > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. >> > >> > - >> > 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: onComponentTag not processed for visible=false?
Think of the children! :) When your children grow up and become programmers and take over your code, they open it and see - is that very clear? Wicket should enforce a form being rendered only with a form tag - that makes sense. -- Jeremy Thomerson http://www.wickettraining.com On Fri, Mar 13, 2009 at 4:15 AM, Martin Makundi < martin.maku...@koodaripalvelut.com> wrote: > > What is the use of being able to attach a form to a ? There is > > absolutely NONE. > > Not necessary TABLE but it is very useful to replace with, for example TR. > > ** > Martin > > > > > On Fri, Mar 13, 2009 at 10:02 AM, Martin Makundi > > wrote: > I wonder if (nested) forms should simply be allowed to have any tag > name the programmer desires? > >>> > >>> No. Because 99% of the time the programmer is not aware that the form > >>> is used in a nested fashion: the form usually is on a Panel, that is > >>> used inside another form. The panel is standalone and should use form > >>> tags. > >> > >> Yes, but there is no harm done if it is ALLOWED to have another tag > >> name. If the user uses >> compatibility would take care of replacing with . > >> > >> ** > >> Martin > >> > >> - > >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > >> For additional commands, e-mail: users-h...@wicket.apache.org > >> > >> > > > > > > > > -- > > Become a Wicket expert, learn from the best: http://wicketinaction.com > > Apache Wicket 1.3.5 is released > > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. > > > > - > > 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: Stop AjaxFallbackLink activity from the value of java script confirmation message
Maybe with an IAjaxCallDecorator and the script "if(!confirm('Delete'))
return false;"?
There are lots of exemple on the list ;)
vela a écrit :
Hello,
I have a AjaxFallbackLink and on click of it, it will delete the value from
the database. On click of the link, a java script confirmation dialog will
be shown. If option 'yes' is selected, then deleting should happen, else if
'no' is chosen, then deletion should not take place.
How to acheive it?
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: memcached session store
If you do have a lot of stateless pages then for those it doesnt matter what kind of sessions you use. The issues he is describing do map exactly on what i am saying. Why would you have none sticky sessions? What do you think you will gain? On Fri, Mar 13, 2009 at 12:14, Martin Grotzke wrote: > On Wed, 2009-03-11 at 12:06 -0700, Victor Igumnov wrote: > > I had issues when running non-sticky sessions with ONE_PASS_RENDERER, > > the results were mixed. Responses came back as a mixed bag, sometimes > > it worked or not. Expired sessions did happen from time to time with > > no rhyme or reason. Sticky sessions is a must on wicket. > Hmm, this does not improve confidence - at least not in the > implementation/handling of ONE_PASS_RENDERER. Did you address this issue > somehow on the users/dev mailing list or via the issue tracker? Also I > would cross the fingers that REDIRECT_TO_RENDER does not produce the > same issues. > > > > > I hate to say this but, if your writing a stateless oriented site, > > wicket might not be the best choice. Your fighting an uphill battle. > Our goal is to defer session creation as long as it's possible - > probably this is until the user submits the first form. With this we > asume we don't need any PageMap (0 versioned pages). > > Provided we use sticky sessions and REDIRECT_TO_BUFFER, would you say > there will be problems with this approach (statelessness as long as it's > possible and no pagemaps)? > > Thanx && cheers, > Martin > > > > > > On Mar 11, 2009, at 10:17 AM, Martin Grotzke wrote: > > > > > Hi, > > > > > > One would need to handle this on the client side, by disabling > > > buttons/links when they are clicked. Also AJAX communicatoin has to be > > > handled, as this is also often a candidate that triggers multiple > > > requests running in parallel. > > > > > > Cheers, > > > Martin > > > > > > > > > On Wed, 2009-03-11 at 17:45 +0100, Johan Compagner wrote: > > >> In my point of view none sticky sessions are just broken or can be > > >> broken > > >> very easily > > >> I dont know exactly how all the implementations work but does this > > >> example > > >> all ways work? > > >> > > >> a user clicks on a button > > >> that button click does take some time and in the mean time a user > > >> clicks on > > >> the same or another button > > >> > > >> In a sticky session configuration this works fine. Wicket makes > > >> sure that > > >> they are synced and a page wont be altered by 2 threads at the same > > >> time\ > > >> > > >> But how does a none sticky configuration work? Will the second > > >> request go to > > >> another server? And just alter there the page state? > > >> It can do that because our sync block doesnt work then ofcourse. > > >> > > >> But if this happens, what happens after that? now the same page > > >> instance is > > >> altered on both places.. Which one takes precedence ? > > >> Because it is impossible for the container to merge the objects. So > > >> it > > >> should take 1 or the other.. > > >> So the first click that took longer then the second click will > > >> overwrite the > > >> second click page. But that now overwritten page is now shown to > > >> the user > > >> So if you then click on something that was on the page of the > > >> second click > > >> but wasnt on the page of the first click. Then you will get an page > > >> expired > > >> or something like that.. > > >> > > >> maybe somehow containers do some synching across concurrent request > > >> of 1 > > >> session (hopefully the will send them to the same server) > > >> But i dont know. Synching over servers is very expensive.. then the > > >> whole > > >> usage of having none sticky sessions is completely gone in my eyes. > > >> > > >> johan > > >> > > >> On Tue, Mar 10, 2009 at 10:49, Martin Grotzke > > >> wrote: > > >> > > >>> On Mon, 2009-03-09 at 22:54 -0700, Victor Igumnov wrote: > > Even if you have the memcached store in place, wicket still > > requires > > session affinity. Wicket buffers redirect responses locally so the > > client needs to go to the same server twice or the client will > > receive > > an expired session. Wicket is a stateful framework, session > > affinity > > is a must. > > >>> Are there other things (besides the buffered response when doing a > > >>> redirect-after-post with the REDIRECT_TO_BUFFER setting) that > > >>> require > > >>> sticky sessions? > > >>> > > >>> We'd like to use wicket in a stateless mode and defer session > > >>> creation > > >>> as long as it's possible for a user. Even if wicket is made with a > > >>> statefull programming model in mind we think there are still many > > >>> advantages over other (non-component-based) frameworks. Also we > > >>> need a > > >>> dynamic structure which would be rather hard to realize/simulate > > >>> with > > >>> some other component oriented frameworks ;) > > >>> > > >>> Cheers, > > >>> Martin > > >>> > > >>> > > > > > > On Mar 9, 2009,
Stop AjaxFallbackLink activity from the value of java script confirmation message
Hello, I have a AjaxFallbackLink and on click of it, it will delete the value from the database. On click of the link, a java script confirmation dialog will be shown. If option 'yes' is selected, then deleting should happen, else if 'no' is chosen, then deletion should not take place. How to acheive it? -- View this message in context: http://www.nabble.com/Stop-AjaxFallbackLink-activity-from-the-value-of-java-script-confirmation-message-tp22495480p22495480.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Dutch Wicket workshop?
Not sure whether this is something you were looking for but..: http://cwiki.apache.org/WICKET/wicket-community-meetups-amsterdam.html regards Jeroen. -Oorspronkelijk bericht- Van: Linda van der Pal [mailto:lvd...@heritageagenturen.nl] Verzonden: vr 3/13/2009 12:41 Aan: users@wicket.apache.org Onderwerp: Dutch Wicket workshop? Triggered by the news of a London Wicket Event, I wondered if there is any (Dutch) Wicket guru who would like to give a workshop about Wicket? I am the founder and chairwoman of Duchess (http://jduchess.org) and we try to have workshops about five times a year. I've just started working with Wicket, and it would be cool to have a workshop about it. A location can be arranged if necessary. We're a small foundation, so we can only offer a link on our sponsor page in recompense. Regards, Linda - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: memcached session store
a get request will change the page. For example wicket always tries to redirect to the page. So that a post will always be a normal get to the current page. (so no resend of post data when pressing F5) But the page that you render can change. For example you can show a listview on that table and some rows are changed because others did do an update on that database data Then the component structure of the page will be changed. So it is not about resending data or do an action again on F5, no it is just getting the latest data from the server. Back to the none sticky sessions: A use clicks on the page (that is a listview with 5 rows) on a link or button That takes a lot of time. So a user does a refresh of that same page That goes to another server then the button click request which is still going on. That last request is fast and returns the same listview of 5 rows. So the page is now in sync with what the user sees. Then the first request goes on and alters the page and now on that point there where only 4 rows left (and i guess now the containter will overwrite this page with the page the user is currently showing in the browser) Then if a user clicks on row 5.. That element isnt there anymore... On Fri, Mar 13, 2009 at 11:58, Martin Grotzke wrote: > On Wed, 2009-03-11 at 20:09 +0100, Johan Compagner wrote: > > thats impossible to do completely > > A refresh of a browser is for example 1 > Ok, from a technical/academical point of view this is valid. However, > GET requests should not modify any data. For POST-requests the user also > has to confirm that form data is resent. Also users pressing F5 (and > confirming resending of data) all the time are not as common as the well > known double-clickers... > > Did you really had issues with this? What was the setup/conditions in > this case? > > > > > And that would be quite annoying that you have to do that because you > have > > some kind of configuration on the serverside > What do you want to say with this? I don't understand this. > > Cheers, > Martin > > > > > > johan > > > > > > On Wed, Mar 11, 2009 at 18:17, Martin Grotzke > > wrote: > > > > > Hi, > > > > > > One would need to handle this on the client side, by disabling > > > buttons/links when they are clicked. Also AJAX communicatoin has to be > > > handled, as this is also often a candidate that triggers multiple > > > requests running in parallel. > > > > > > Cheers, > > > Martin > > > > > > > > > On Wed, 2009-03-11 at 17:45 +0100, Johan Compagner wrote: > > > > In my point of view none sticky sessions are just broken or can be > broken > > > > very easily > > > > I dont know exactly how all the implementations work but does this > > > example > > > > all ways work? > > > > > > > > a user clicks on a button > > > > that button click does take some time and in the mean time a user > clicks > > > on > > > > the same or another button > > > > > > > > In a sticky session configuration this works fine. Wicket makes sure > > > that > > > > they are synced and a page wont be altered by 2 threads at the same > time\ > > > > > > > > But how does a none sticky configuration work? Will the second > request go > > > to > > > > another server? And just alter there the page state? > > > > It can do that because our sync block doesnt work then ofcourse. > > > > > > > > But if this happens, what happens after that? now the same page > instance > > > is > > > > altered on both places.. Which one takes precedence ? > > > > Because it is impossible for the container to merge the objects. So > it > > > > should take 1 or the other.. > > > > So the first click that took longer then the second click will > overwrite > > > the > > > > second click page. But that now overwritten page is now shown to the > user > > > > So if you then click on something that was on the page of the second > > > click > > > > but wasnt on the page of the first click. Then you will get an page > > > expired > > > > or something like that.. > > > > > > > > maybe somehow containers do some synching across concurrent request > of 1 > > > > session (hopefully the will send them to the same server) > > > > But i dont know. Synching over servers is very expensive.. then the > whole > > > > usage of having none sticky sessions is completely gone in my eyes. > > > > > > > > johan > > > > > > > > On Tue, Mar 10, 2009 at 10:49, Martin Grotzke > > > > wrote: > > > > > > > > > On Mon, 2009-03-09 at 22:54 -0700, Victor Igumnov wrote: > > > > > > Even if you have the memcached store in place, wicket still > requires > > > > > > session affinity. Wicket buffers redirect responses locally so > the > > > > > > client needs to go to the same server twice or the client will > > > receive > > > > > > an expired session. Wicket is a stateful framework, session > affinity > > > > > > is a must. > > > > > Are there other things (besides the buffered response when doing a > > > > > redirect-after-post with the REDIRECT_TO_BUFFER setting) that > require >
Re: Possible to retrieve previous page from PageMap
to be honest i haven't read the whole thread, but we are also trying
to achieve roughly the same thing.
as of wicket 1.4-m1 there is a class called PageId that you may want
to consider.
i created a "back state holder" class that holds a PageId and an
IModel for the text of the back link. so for every visited
page (in the onBeforeRender - could be placed in the base page), we
set a holder in the session and in our base page we call
Session.get.getHolder. pretty simple really.
as the PageId class is a unique identifier of the page you can use it
to distinguish between pagemaps, etc. (so navigation doesn't interfere
between tabs / windows)
this fulfills our usecase, as this is just a helper link to "go back
where you were". we don't completely rely on this link because we also
do keep traditional navigation links in our pages.
however i still need to solve the double click problem, i.e. if a user
clicks twice on a link, the last rendered page will be the same as the
one he is in. thus, the back link points to the same page. it is
actually quite tricky to get it right, yet i believe possible. i will
definitely try to avoid the link handing over pageparams in the url
"like in the good old days" :)
i will post it once i get everything working together.
francisco
On Fri, Mar 13, 2009 at 10:29 AM, pixologe wrote:
>
> Just a thought which I did not think about when implementing this (thus I had
> to change this stuff all over afterwards), perhaps it helps someone avoiding
> the same mistake:
>
> The latest rendered page is not neccessarily the page that lead the user to
> the current page.
> I.e. retrieving the last page this way might result in strange behavior if
> the user uses two browser windows or tabs simulaneously. Same applies for
> clicking the browser's back button.
>
> Thus I had to go back to a rather old-fashioned solution, where every link
> hands over a page param :-/ like in the good old days ;-)
>
>
>
>
>
> rolandpeng wrote:
>>
>> great! after delare a ineer class below:
>> class PageIdVersion {
>> public int id;
>> public int version;
>> public PageIdVersion last;
>> }
>> then the track function works.
>>
>>
>> John Patterson wrote:
>>>
>>>
>>> // must declare hash map because meta data must be serializable
>>> private MetaDataKey>
>>> lastPageIdVersionKey
>>> = new MetaDataKey>() {};
>>>
>>>
>>
>>
>
> --
> View this message in context:
> http://www.nabble.com/Possible-to-retrieve-previous-page-from-PageMap-tp20861106p22492628.html
> Sent from the Wicket - User mailing list archive at Nabble.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
Dutch Wicket workshop?
Triggered by the news of a London Wicket Event, I wondered if there is any (Dutch) Wicket guru who would like to give a workshop about Wicket? I am the founder and chairwoman of Duchess (http://jduchess.org) and we try to have workshops about five times a year. I've just started working with Wicket, and it would be cool to have a workshop about it. A location can be arranged if necessary. We're a small foundation, so we can only offer a link on our sponsor page in recompense. Regards, Linda - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: London Wicket Event - 1st of April @ Google
We've already had around 40 guests register (30 confirmed so far) for our next London Wicket Event, including several developers from WicketStuff and other Wicket based projects you may already be using or are interested in, so make sure you register early at http://jweekend.com/dev/LWUGReg/ the usual place if you would like to come along. Also, take a look at http://www.eu.apachecon.com/c/aceu2009/ ApacheCon Europe 2009 (Amsterdam, 23-27 March); lots of interesting stuff including several Wicket sessions and presentations. Regards - Cemal http://jWeekend.com jWeekend jWeekend wrote: > > Our next London Wicket Event will be on the evening of Wednesday, April > 1st, at Google. > Martijn Dashorst will be flyiing over from Holland for the evening; as > well as giving us a couple of interesting presentations, he will be > signing your copies of Wicket In Action. Manning are kindly sending over a > few copies too, so we'll be having another of our well-organised(?!) > raffles. > Al has fixed a bigger room for us at Google, who have been kindly hosting > our events, but we do expect a fairly full auditorium again so > http://jweekend.com/dev/LWUGReg/ register early. > > Al and I (and Martijn, no doubt, this time) will also run a general Wicket > Q&A to wrap things up as usual. > > We'll be getting in some hot Pizza for around 18:15 and then: > * http://jWeekend.com Cemal Bayramoglu : Welcome/Introduction > * Marc Ziman: My Agile Stack (Wicket, Spring, Hibernate, MySQL) > * http://wicketinaction.com Martijn Dashorst : Complex UIs With > Wicket > * Martijn Dashorst: Quality Control > * http://herebebeasties.com Al Maw : TBD > * Al Maw & Cemal Bayramoglu: General Wicket Q&A > If you're not in a rush to get away join us for the customary visit to a > local pub straight after the Q&A. > > We're lucky to attract a very good crowd and they say really nice things > about our events, so if you've never been, you'd most likely enjoy the > experience. > > Full details and registration are at at http://jweekend.com/dev/LWUGReg/ > the usual place - don't forget to confirm (or cancel) your registration > using the link in the automated email. > > Regards - Cemal > http://jWeekend.com jWeekend > -- View this message in context: http://www.nabble.com/London-Wicket-Event---1st-of-April-%40-Google-tp22327416p22494435.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Propper Way to Use StringResourceModel
I have seen some examples of Pages that uses the StringResourceModel to read properties inside property files. But the examples that I saw shows that I need to create a StringResourceModel for each property that is inside my property file. So, If I have a Login page that have 3 properties, like login.username , login.password and login.button I must create also 3 StringResourceModels and use each one on the constructor of the Labels. I do not think it is a practical solution because I see the StringResourceModel as a ResourceBundle. Am I right? What is the real deal when using it? Is it the propper way to internationalize a resource? Is there a way to make a single StringResourceModel and use it to read a property file so, instead of creating several resources I create a single one and pass the key that I wanna retrieve its value? -- "Two rules to succeed in life: 1 - don´t tell people everything you know." We shall go on to the end. We shall fight in France We shall fightover the seas and oceans. We shall fight with growing confidence and growing strength in the air. We shall defend our island whatever the cost may be We shall fight on beaches, we shall fight on the landing grounds, We shall fight in the fields and in the streets, We shall fight on the hills. We shall never surrender. Winston Churchill
Re: memcached session store
On Wed, 2009-03-11 at 12:06 -0700, Victor Igumnov wrote: > I had issues when running non-sticky sessions with ONE_PASS_RENDERER, > the results were mixed. Responses came back as a mixed bag, sometimes > it worked or not. Expired sessions did happen from time to time with > no rhyme or reason. Sticky sessions is a must on wicket. Hmm, this does not improve confidence - at least not in the implementation/handling of ONE_PASS_RENDERER. Did you address this issue somehow on the users/dev mailing list or via the issue tracker? Also I would cross the fingers that REDIRECT_TO_RENDER does not produce the same issues. > > I hate to say this but, if your writing a stateless oriented site, > wicket might not be the best choice. Your fighting an uphill battle. Our goal is to defer session creation as long as it's possible - probably this is until the user submits the first form. With this we asume we don't need any PageMap (0 versioned pages). Provided we use sticky sessions and REDIRECT_TO_BUFFER, would you say there will be problems with this approach (statelessness as long as it's possible and no pagemaps)? Thanx && cheers, Martin > > On Mar 11, 2009, at 10:17 AM, Martin Grotzke wrote: > > > Hi, > > > > One would need to handle this on the client side, by disabling > > buttons/links when they are clicked. Also AJAX communicatoin has to be > > handled, as this is also often a candidate that triggers multiple > > requests running in parallel. > > > > Cheers, > > Martin > > > > > > On Wed, 2009-03-11 at 17:45 +0100, Johan Compagner wrote: > >> In my point of view none sticky sessions are just broken or can be > >> broken > >> very easily > >> I dont know exactly how all the implementations work but does this > >> example > >> all ways work? > >> > >> a user clicks on a button > >> that button click does take some time and in the mean time a user > >> clicks on > >> the same or another button > >> > >> In a sticky session configuration this works fine. Wicket makes > >> sure that > >> they are synced and a page wont be altered by 2 threads at the same > >> time\ > >> > >> But how does a none sticky configuration work? Will the second > >> request go to > >> another server? And just alter there the page state? > >> It can do that because our sync block doesnt work then ofcourse. > >> > >> But if this happens, what happens after that? now the same page > >> instance is > >> altered on both places.. Which one takes precedence ? > >> Because it is impossible for the container to merge the objects. So > >> it > >> should take 1 or the other.. > >> So the first click that took longer then the second click will > >> overwrite the > >> second click page. But that now overwritten page is now shown to > >> the user > >> So if you then click on something that was on the page of the > >> second click > >> but wasnt on the page of the first click. Then you will get an page > >> expired > >> or something like that.. > >> > >> maybe somehow containers do some synching across concurrent request > >> of 1 > >> session (hopefully the will send them to the same server) > >> But i dont know. Synching over servers is very expensive.. then the > >> whole > >> usage of having none sticky sessions is completely gone in my eyes. > >> > >> johan > >> > >> On Tue, Mar 10, 2009 at 10:49, Martin Grotzke > >> wrote: > >> > >>> On Mon, 2009-03-09 at 22:54 -0700, Victor Igumnov wrote: > Even if you have the memcached store in place, wicket still > requires > session affinity. Wicket buffers redirect responses locally so the > client needs to go to the same server twice or the client will > receive > an expired session. Wicket is a stateful framework, session > affinity > is a must. > >>> Are there other things (besides the buffered response when doing a > >>> redirect-after-post with the REDIRECT_TO_BUFFER setting) that > >>> require > >>> sticky sessions? > >>> > >>> We'd like to use wicket in a stateless mode and defer session > >>> creation > >>> as long as it's possible for a user. Even if wicket is made with a > >>> statefull programming model in mind we think there are still many > >>> advantages over other (non-component-based) frameworks. Also we > >>> need a > >>> dynamic structure which would be rather hard to realize/simulate > >>> with > >>> some other component oriented frameworks ;) > >>> > >>> Cheers, > >>> Martin > >>> > >>> > > > On Mar 9, 2009, at 7:03 AM, Martin Grotzke wrote: > > > On Mon, 2009-03-09 at 13:07 +0100, Martijn Dashorst wrote: > >> Starts to sound like a form of premature optimization. If you > >> are new > >> to Wicket, why do you want to implement a memcached session > >> store? > >> What is the usecase? > > We're starting a new project (the relaunch of a big ecommerce > > system) > > and want to be able to scale out (just throw in new hardware when > >
Re: memcached session store
On Wed, 2009-03-11 at 20:09 +0100, Johan Compagner wrote: > thats impossible to do completely > A refresh of a browser is for example 1 Ok, from a technical/academical point of view this is valid. However, GET requests should not modify any data. For POST-requests the user also has to confirm that form data is resent. Also users pressing F5 (and confirming resending of data) all the time are not as common as the well known double-clickers... Did you really had issues with this? What was the setup/conditions in this case? > > And that would be quite annoying that you have to do that because you have > some kind of configuration on the serverside What do you want to say with this? I don't understand this. Cheers, Martin > > johan > > > On Wed, Mar 11, 2009 at 18:17, Martin Grotzke > wrote: > > > Hi, > > > > One would need to handle this on the client side, by disabling > > buttons/links when they are clicked. Also AJAX communicatoin has to be > > handled, as this is also often a candidate that triggers multiple > > requests running in parallel. > > > > Cheers, > > Martin > > > > > > On Wed, 2009-03-11 at 17:45 +0100, Johan Compagner wrote: > > > In my point of view none sticky sessions are just broken or can be broken > > > very easily > > > I dont know exactly how all the implementations work but does this > > example > > > all ways work? > > > > > > a user clicks on a button > > > that button click does take some time and in the mean time a user clicks > > on > > > the same or another button > > > > > > In a sticky session configuration this works fine. Wicket makes sure > > that > > > they are synced and a page wont be altered by 2 threads at the same time\ > > > > > > But how does a none sticky configuration work? Will the second request go > > to > > > another server? And just alter there the page state? > > > It can do that because our sync block doesnt work then ofcourse. > > > > > > But if this happens, what happens after that? now the same page instance > > is > > > altered on both places.. Which one takes precedence ? > > > Because it is impossible for the container to merge the objects. So it > > > should take 1 or the other.. > > > So the first click that took longer then the second click will overwrite > > the > > > second click page. But that now overwritten page is now shown to the user > > > So if you then click on something that was on the page of the second > > click > > > but wasnt on the page of the first click. Then you will get an page > > expired > > > or something like that.. > > > > > > maybe somehow containers do some synching across concurrent request of 1 > > > session (hopefully the will send them to the same server) > > > But i dont know. Synching over servers is very expensive.. then the whole > > > usage of having none sticky sessions is completely gone in my eyes. > > > > > > johan > > > > > > On Tue, Mar 10, 2009 at 10:49, Martin Grotzke > > > wrote: > > > > > > > On Mon, 2009-03-09 at 22:54 -0700, Victor Igumnov wrote: > > > > > Even if you have the memcached store in place, wicket still requires > > > > > session affinity. Wicket buffers redirect responses locally so the > > > > > client needs to go to the same server twice or the client will > > receive > > > > > an expired session. Wicket is a stateful framework, session affinity > > > > > is a must. > > > > Are there other things (besides the buffered response when doing a > > > > redirect-after-post with the REDIRECT_TO_BUFFER setting) that require > > > > sticky sessions? > > > > > > > > We'd like to use wicket in a stateless mode and defer session creation > > > > as long as it's possible for a user. Even if wicket is made with a > > > > statefull programming model in mind we think there are still many > > > > advantages over other (non-component-based) frameworks. Also we need a > > > > dynamic structure which would be rather hard to realize/simulate with > > > > some other component oriented frameworks ;) > > > > > > > > Cheers, > > > > Martin > > > > > > > > > > > > > > > > > > > > > > > On Mar 9, 2009, at 7:03 AM, Martin Grotzke wrote: > > > > > > > > > > > On Mon, 2009-03-09 at 13:07 +0100, Martijn Dashorst wrote: > > > > > >> Starts to sound like a form of premature optimization. If you are > > new > > > > > >> to Wicket, why do you want to implement a memcached session store? > > > > > >> What is the usecase? > > > > > > We're starting a new project (the relaunch of a big ecommerce > > system) > > > > > > and want to be able to scale out (just throw in new hardware when > > > > > > traffic grows). Additionally we have the requirement of session > > > > > > failover, both in standard operations and for deployments. > > > > > > > > > > > > We're discussing non-sticky vs. sticky sessions here and for non- > > > > > > sticky > > > > > > sessions memcached (as caching layer in addition to sessions stored > > > > > > in a > > > > > > database) is a good candidate, as you don't replicate the changed > > >
Re: can we get this patch applied to the current snapshot?
Again, ListMultipleChoice is okay in this instance. You don't want to
"widen" the model. You want to widen what can go in it (the choices),
which I have.
On Fri, Mar 13, 2009 at 3:40 AM, Igor Vaynberg wrote:
> taking ListMultipleChoice as another example, your patch leaves it us
>
> public class ListMultipleChoice extends AbstractChoice, T>
>
> when in fact it should be properly declared as
>
> public class ListMultipleChoice extends AbstractChoice extends T>, T>
>
> so that getModelObject() properly returns Collection
> instead of the unsafe variant Collection
>
> which, once again, will break updatemodel()
>
> in your experience you havent ran into a situation where a component
> updates its collection model object. my experience is quiet the
> opposite. just trying to make sure we do not paint ourselves into a
> corner.
>
> -igor
>
> On Fri, Mar 13, 2009 at 12:31 AM, Igor Vaynberg
> wrote:
>> your patch works because it does not properly refactor
>> Palette#getModelCollection(). you left it us:
>>
>> public Collection getModelCollection()
>> {
>> return (Collection)getDefaultModelObject();
>> }
>>
>> which is incorrect, it should in fact now return Collection> T>, which will break Palette#updateModel()
>>
>> -igor
>>
>> On Thu, Mar 12, 2009 at 11:32 PM, James Carman
>> wrote:
>>> FYI,
>>>
>>> I have created a new JIRA issue for my proposed API changes:
>>>
>>> https://issues.apache.org/jira/browse/WICKET-2165
>>>
>>> I've attached a patch. I've "fixed" all of the places I could find
>>> thus far. If I find anymore, I'll upload a new patch.
>>>
>>> James
>>>
>>> On Fri, Mar 13, 2009 at 1:59 AM, James Carman
>>> wrote:
"Feeding" the list to your component isn't the issue (the constructor
will take what you throw at it). It's using the
getDefaultModelObject() method and trying to modify that list once
you've passed it in that will cause you to have to cast.
On Fri, Mar 13, 2009 at 1:54 AM, Brill Pappin wrote:
> I'm really not sure of all the use-cases... all I know is that I spent
> some
> time trying to get the darn thing to compile using a fairly basic wicket
> pattern.
>
> If such a simple thing as feeding a list of items to a component that
> draws
> a list using them is going to give me that much trouble (knowing a
> workaround or not), then there is something definitely broken.
>
> - Brill
>
> On 13-Mar-09, at 1:43 AM, James Carman wrote:
>
>> To be clear, the only potential for breakage is where user code tries
>> to modify the returned "model object" (of type List)
>> without casting it. However, that's a rare usecase (in my opinion)
>> and again it's easily overcome by a simple cast.
>>
>> On Thu, Mar 12, 2009 at 5:10 PM, Igor Vaynberg
>> wrote:
>>>
>>> before applying an api-breaking patch to an rc release we should have
>>> a vote on the dev list.
>>>
>>> -igor
>>>
>>> On Thu, Mar 12, 2009 at 12:59 PM, Jeremy Thomerson
>>> wrote:
Unless I'm seeing double - this patch has two problems:
1 - It is the opposite of what was voted on. The vote was to make
IModel> into IModel>. Your patch makes it
IModel>.
2 - The patch causes compile errors that were not fixed.
I have unassigned myself from the task until those issues are addressed
or I
have time to create my own patch. The best solution would be for
someone to
submit a proper patch that fixes the two problems above or explain to
me
what I missed.
Thanks!
--
Jeremy Thomerson
http://www.wickettraining.com
On Thu, Mar 12, 2009 at 2:53 PM, Jeremy Thomerson
> wrote:
> I'm reviewing it now. Assuming that it looks fine, and is line with
> what
> was proposed by the vote thread earlier, I will apply. The vote
> passed, so
> I don't see a reason not to. I'm not sure how many were binding /
> non-binding, but there were eight for, two against.
>
> --
> Jeremy Thomerson
> http://www.wickettraining.com
>
>
>
>
> On Thu, Mar 12, 2009 at 9:52 AM, Brill Pappin wrote:
>
>> https://issues.apache.org/jira/browse/WICKET-2137
>>
>> - Brill
>>
>> -
>> 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.or
Re: can we get this patch applied to the current snapshot?
Your right, my patch was a bit off with respect to Palette, but not
because of this. I shouldn't have "widened" the second constructor.
It should take a IModel>. So, the getModelCollection()
doesn't have to change. When we're doing this widening, only the
"choices" (not the model) should be widened.
On Fri, Mar 13, 2009 at 3:31 AM, Igor Vaynberg wrote:
> your patch works because it does not properly refactor
> Palette#getModelCollection(). you left it us:
>
> public Collection getModelCollection()
> {
> return (Collection)getDefaultModelObject();
> }
>
> which is incorrect, it should in fact now return Collection T>, which will break Palette#updateModel()
>
> -igor
>
> On Thu, Mar 12, 2009 at 11:32 PM, James Carman
> wrote:
>> FYI,
>>
>> I have created a new JIRA issue for my proposed API changes:
>>
>> https://issues.apache.org/jira/browse/WICKET-2165
>>
>> I've attached a patch. I've "fixed" all of the places I could find
>> thus far. If I find anymore, I'll upload a new patch.
>>
>> James
>>
>> On Fri, Mar 13, 2009 at 1:59 AM, James Carman
>> wrote:
>>> "Feeding" the list to your component isn't the issue (the constructor
>>> will take what you throw at it). It's using the
>>> getDefaultModelObject() method and trying to modify that list once
>>> you've passed it in that will cause you to have to cast.
>>>
>>> On Fri, Mar 13, 2009 at 1:54 AM, Brill Pappin wrote:
I'm really not sure of all the use-cases... all I know is that I spent some
time trying to get the darn thing to compile using a fairly basic wicket
pattern.
If such a simple thing as feeding a list of items to a component that draws
a list using them is going to give me that much trouble (knowing a
workaround or not), then there is something definitely broken.
- Brill
On 13-Mar-09, at 1:43 AM, James Carman wrote:
> To be clear, the only potential for breakage is where user code tries
> to modify the returned "model object" (of type List)
> without casting it. However, that's a rare usecase (in my opinion)
> and again it's easily overcome by a simple cast.
>
> On Thu, Mar 12, 2009 at 5:10 PM, Igor Vaynberg
> wrote:
>>
>> before applying an api-breaking patch to an rc release we should have
>> a vote on the dev list.
>>
>> -igor
>>
>> On Thu, Mar 12, 2009 at 12:59 PM, Jeremy Thomerson
>> wrote:
>>>
>>> Unless I'm seeing double - this patch has two problems:
>>>
>>> 1 - It is the opposite of what was voted on. The vote was to make
>>> IModel> into IModel>. Your patch makes it
>>> IModel>.
>>>
>>> 2 - The patch causes compile errors that were not fixed.
>>>
>>> I have unassigned myself from the task until those issues are addressed
>>> or I
>>> have time to create my own patch. The best solution would be for
>>> someone to
>>> submit a proper patch that fixes the two problems above or explain to me
>>> what I missed.
>>>
>>> Thanks!
>>>
>>> --
>>> Jeremy Thomerson
>>> http://www.wickettraining.com
>>>
>>>
>>>
>>> On Thu, Mar 12, 2009 at 2:53 PM, Jeremy Thomerson
>>> >>>
wrote:
>>>
I'm reviewing it now. Assuming that it looks fine, and is line with
what
was proposed by the vote thread earlier, I will apply. The vote
passed, so
I don't see a reason not to. I'm not sure how many were binding /
non-binding, but there were eight for, two against.
--
Jeremy Thomerson
http://www.wickettraining.com
On Thu, Mar 12, 2009 at 9:52 AM, Brill Pappin wrote:
> https://issues.apache.org/jira/browse/WICKET-2137
>
> - Brill
>
> -
> 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 c
Regarding Tomcat web project customize xml (settings.xml)content is missing
hello experts, i tried to configure web based java application. but my customize settings.xml content is missing. so after saving the information. i am getting javax.servlet.ServletException: Servlet execution threw an exception please advise thanks -- View this message in context: http://www.nabble.com/Regarding-Tomcat-web-project-customize-xml-%28settings.xml%29content-is-missing-tp22493954p22493954.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Large Scale Applications using Wicket
I don't think that page serialization is going to be your bottleneck. I don't know what you're thinking when you say "large scale." Some folks think "large scale" means two server and others think Travelocity or Google. I developed a system in PHP that served about 20-50 pages per second. This was PHP 4. I don't know if things are different now, but in PHP 4, the PHP module interpreted every PHP page from scratch, loaded the session state from disk, rendered the page, and wrote the session state back to disk, with every request. The time required to serialize the session to the disk and read it back every time was negligible. I suggest you write your Wicket app first, then analyze the performance and determine what you need to optimize. It almost certainly won't be the serialization. It will be your own code: mostly database access and synchronized blocks. W On Mar 12, 2009, at 11:52 PM, subbu_tce wrote: Do we have any Clustering Solutions other than Terracotta that can integrate with Wicket to avoid serialization of pages to support development of applications in a large scale? Thanks, Subbu. -- View this message in context: http://www.nabble.com/Large-Scale-Applications-using-Wicket-tp22489752p22489752.html Sent from the Wicket - User mailing list archive at Nabble.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: Extensible wicket application
You will have to use bridge-servlet approach for that. As said the bridge-servlet will launch an equinox runtime and redirect your request to the "underlaying" http service. If you import the projects I mentioned into eclipse and then export them as plugin jar files into the plugins folder on the bridge "war" then you will be able to run your wicket application on any server. That is, if you mount the bridge servlet at *bridge*, then accessing the URL localhost:8080/bridge/demo-app should re-direct you to the previous wicket application. Of course, this is just the "big picture", and you will have to figure out the (sometime nasty) details by yourself. So in development you can use eclipse and for deployment you will to export any bundles you use to the a bridge war. This could be automated with an ANT file. There are some additional caveats, for some application servers, concerning class-loading if you plan to access things via JNDI from within the OSGi runtime... About the console I think there is flag -console or similar that allows you to disable/enable the console or even tell which port to use. I do not recall the details right now... Ernesto On Fri, Mar 13, 2009 at 10:21 AM, Daniel Dominik Holúbek < dankodo...@gmail.com> wrote: > Hello, > this seems to be helpful, thanks. > But still it does not solve the main problem. How do I put OSGi on the Sun > Java Application Server and then how do I install bundles in it? > (preferably > with no console available) > > Thanks again :) > > On Thu, Mar 12, 2009 at 10:24 PM, Ernesto Reinaldo Barreiro < > reier...@gmail.com> wrote: > > > Hi, > > > > I just created a very simple starting project for OSGi and wicket at: > > > > http://code.google.com/p/antilia/source/browse/#svn/trunk > > > > check out projects > > > > com.antilia.wstarter > > com.antilia.wstarter.demo > > > > Then you will have a equinox launcher called wicket-app (for eclipse > 3.4). > > Use it to launch your application and then browse at > > > > localhost:8080/demo-app > > > > Hope this helps. > > > > Ernesto > > > > On Thu, Mar 12, 2009 at 3:36 PM, Daniel Dominik Holúbek < > > dankodo...@gmail.com> wrote: > > > > > Hello :) > > > I looked at the links listed below, seemed interesting, but the main > > > problem > > > (how to set up such a project) remains unsolved. > > > So I think I really do need help :) > > > > > > It seems to me, though, that this whole thing is much too complicated. > I > > > need only some simple loading of multiple jars :) > > > But if it would work, I don't care how :) > > > > > > Thanks again! > > > > > > On Thu, Mar 12, 2009 at 10:07 AM, Ernesto Reinaldo Barreiro < > > > reier...@gmail.com> wrote: > > > > > > > Hi Daniel, > > > > Some comments inlined. > > > > > > > > On Thu, Mar 12, 2009 at 9:37 AM, Daniel Dominik Holúbek < > > > > dankodo...@gmail.com> wrote: > > > > > > > > > Firstly, thanks for you reply :) > > > > > I have already read that document regarding wicket and OSGi, but I > > > think > > > > it > > > > > is written for more experienced users at OSGi. As I wrote before, I > > > even > > > > do > > > > > not know how to build a simple web OSGi project (what should I > > deploy, > > > > how > > > > > to install those bundles - I can't access any console..) > > > > > > > > > > > > In my experience getting used to do things the OSGi way is difficult > at > > > > the beginning but latter on the effort will pay off... In fact it is > > > > relatively easy to set up a Wicket-OSGi project if you are using > > Eclipse > > > > for > > > > development and you don't mind using equinox as your OSGi > > > > implementation. You could easily build a WEB console to manage > plug-ins > > > > (bundles) on your application. > > > > > > > > > > > > > I imagine this application like this: I visit some administration > > page, > > > > > where can I upload a jar file containing the extension. The jar > file > > > then > > > > > installs into running application and creates some records in > > database. > > > I > > > > > can then decide where in the page should this extension appear. > > > > > The main problem is this. I think my application should have some > > "OSGi > > > > > container". I have already tried some "bridge.war" from some > webpage > > (I > > > > > don't remember now, which one was it), it is running correctly, but > I > > > > > really > > > > > do not know what to do now. Add some bundles? Where? How? :) > > > > > Btw, I am running Sun Java System Application Server. > > > > > > > > > > > > Probably yo are reffering to [1] ? You will have to export your > bundles > > > > into > > > > the plug-ins section inside this war. This war is just a WEB > > application > > > > that starts an OSGi runtime (an equinox) and uses a Servlet to manage > > it > > > > and > > > > to redirect requests to your application to the servlets you mount > > using > > > > the > > > > HTTP service provided by the equinox runtime. > > > > > > > > If you need more help I could help
Re: Generics question
Thanks!
Erik van Oosten wrote:
Hi Linda,
You are assuming that
IModel>
is a subtype of
IModel>
In java this is not the case (even if Subgenre extends DomainObject).
You'll need an explicit cast to make this work:
IModel> castedModel =
(IModel>) subgenreModel;
Regards,
Erik.
Linda van der Pal wrote:
This is not really Wicket related, but I don't quite know where else
to ask this. The question is: why won't this compile?
// I define a model
IModel> subgenreModel = new
AbstractReadOnlyModel>() {
...
}
// Here I try to use the model
FieldSwitchPanel subgenrefield = *new
SubgenreFieldSwitchPanel("subgenre", subgenreModel);*
// This is the constructor for the class SubgenreFieldSwithcPanel
public SubgenreFieldSwitchPanel(String id, IModelDomainObject>> choices) {
...
}
// Subgenre extends DomainObject
public class Subgenre extends DomainObject{
...
}
The complaint is: The constructor SubgenreFieldSwitchPanel(String,
IModel>) is undefined.
Thanks,
Linda
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.278 / Virus Database: 270.11.13/1999 - Release Date: 03/13/09 05:59:00
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Generics question
This looks exactly like the DropDownChoice issue that has been debated
recently. See the comments in JIRA:
https://issues.apache.org/jira/browse/WICKET-2137
The problem is that IModel> doesn't work
as we intuitively expect it to. It won't match IModel>
(nor IModel> for that matter).
As suggested by James, the correct generic type to achieve what you
want to do would be: IModel>
Olivier
2009/3/13 Linda van der Pal :
> This is not really Wicket related, but I don't quite know where else to ask
> this. The question is: why won't this compile?
>
> // I define a model
> IModel> subgenreModel = new
> AbstractReadOnlyModel>() {
> ...
> }
>
> // Here I try to use the model
> FieldSwitchPanel subgenrefield = *new SubgenreFieldSwitchPanel("subgenre",
> subgenreModel);*
>
>
> // This is the constructor for the class SubgenreFieldSwithcPanel
> public SubgenreFieldSwitchPanel(String id, IModel DomainObject>> choices) {
> ...
> }
>
>
> // Subgenre extends DomainObject
> public class Subgenre extends DomainObject{
> ...
> }
>
>
> The complaint is: The constructor SubgenreFieldSwitchPanel(String,
> IModel>) is undefined.
>
> Thanks,
> Linda
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Generics question
Hi Linda,
You are assuming that
IModel>
is a subtype of
IModel>
In java this is not the case (even if Subgenre extends DomainObject).
You'll need an explicit cast to make this work:
IModel> castedModel =
(IModel>) subgenreModel;
Regards,
Erik.
Linda van der Pal wrote:
This is not really Wicket related, but I don't quite know where else
to ask this. The question is: why won't this compile?
// I define a model
IModel> subgenreModel = new
AbstractReadOnlyModel>() {
...
}
// Here I try to use the model
FieldSwitchPanel subgenrefield = *new
SubgenreFieldSwitchPanel("subgenre", subgenreModel);*
// This is the constructor for the class SubgenreFieldSwithcPanel
public SubgenreFieldSwitchPanel(String id, IModelDomainObject>> choices) {
...
}
// Subgenre extends DomainObject
public class Subgenre extends DomainObject{
...
}
The complaint is: The constructor SubgenreFieldSwitchPanel(String,
IModel>) is undefined.
Thanks,
Linda
--
Erik van Oosten
http://day-to-day-stuff.blogspot.com/
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: AjaxFallbackButton not working when PasswordTextField is not entered
Hello, Thank you very much for your inputs. Its working fine. vela wrote: > > Hello, > I have a PasswordTextField, some text fields and AjaxFallbackButton in the > form. If PasswordTextField is not entered and on sumbit of the > AjaxFallbackButton, onSubmit(AjaxRequestTarget , ..) is not > getting called. But when I remove the PasswordTextField and without > entering the values for the other textfields, and on submit of the > AjaxFallbackButton, onSubmit(AjaxRequestTarget , ..) is > getting called. > > What is the reason for that? > How to make the onSubmit(AjaxRequestTarget , ..) getting > called event if no values are entered for PasswordTextField, on submit of > the AjaxFallbackButton. > > > -- View this message in context: http://www.nabble.com/AjaxFallbackButton-not-working-when-PasswordTextField-is-not-entered-tp22491712p22492629.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Possible to retrieve previous page from PageMap
Just a thought which I did not think about when implementing this (thus I had
to change this stuff all over afterwards), perhaps it helps someone avoiding
the same mistake:
The latest rendered page is not neccessarily the page that lead the user to
the current page.
I.e. retrieving the last page this way might result in strange behavior if
the user uses two browser windows or tabs simulaneously. Same applies for
clicking the browser's back button.
Thus I had to go back to a rather old-fashioned solution, where every link
hands over a page param :-/ like in the good old days ;-)
rolandpeng wrote:
>
> great! after delare a ineer class below:
> class PageIdVersion {
> public int id;
> public int version;
> public PageIdVersion last;
> }
> then the track function works.
>
>
> John Patterson wrote:
>>
>>
>> // must declare hash map because meta data must be serializable
>> private MetaDataKey> lastPageIdVersionKey
>> = new MetaDataKey>() {};
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/Possible-to-retrieve-previous-page-from-PageMap-tp20861106p22492628.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: building a wicket app with maven 1
Yes I do, but the particular framework they are building this app into requires Maven1 unfortunately. Recent iterations of it are now on M2 its just a legacy version they are running and can't upgrade due to various factors. cheers, Steve On 13 Mar 2009, at 08:55, Martijn Dashorst wrote: You (and presumably your client) do know that maven 1 is a technological, and evolutional dead end just like the dodo, right? Martijn On Fri, Mar 13, 2009 at 9:35 AM, Stephen Swinsburg wrote: Spot on, it's been a while since I've done Maven1 work and this has caught me out previously I just didn't think of it this time! I'll double check the jars that are in my Maven2 webapp and presume I will find that jar missing from the Maven1 build. Thanks Linda and Adriano! On 13/03/2009, at 8:05 AM, Linda van der Pal wrote: Maven2 handles transitive dependencies, meaning that if a project you are dependent on is dependent on other projects, Maven will add them to the classpath. So that's why you didn't have to add that jar manually, Maven did it for you. I don't think Maven1 had this functionality. Linda Stephen Swinsburg wrote: Thanks Adriano. I don't seem to need that for my Maven2 build though, is there a reason for that? I'll try that though. cheers, Steve On 12/03/2009, at 8:02 PM, Adriano dos Santos Fernandes wrote: Steve Swinsburg escreveu: Hi all, I have a need to backport my wicket app that builds perfectly in Maven2 to Maven1. I think I've adjusted all the pom.xml to project.xml correctly as all the classes and dependent jars looks like they are where they need to be, but on startup I get this: java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory Although in my WEB-INF/lib I have (amongst the others) the required jars: slf4j-log4j12-1.4.2.jar log4j-1.2.14.jar Any idea what's missing? Does anyone else build under Maven1? You also need slf4j-api-*.jar. Adriano - 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 No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.278 / Virus Database: 270.11.10/1996 - Release Date: 03/11/09 20:42:00 - 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 -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.3.5 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org smime.p7s Description: S/MIME cryptographic signature
Re: Extensible wicket application
Hello, this seems to be helpful, thanks. But still it does not solve the main problem. How do I put OSGi on the Sun Java Application Server and then how do I install bundles in it? (preferably with no console available) Thanks again :) On Thu, Mar 12, 2009 at 10:24 PM, Ernesto Reinaldo Barreiro < reier...@gmail.com> wrote: > Hi, > > I just created a very simple starting project for OSGi and wicket at: > > http://code.google.com/p/antilia/source/browse/#svn/trunk > > check out projects > > com.antilia.wstarter > com.antilia.wstarter.demo > > Then you will have a equinox launcher called wicket-app (for eclipse 3.4). > Use it to launch your application and then browse at > > localhost:8080/demo-app > > Hope this helps. > > Ernesto > > On Thu, Mar 12, 2009 at 3:36 PM, Daniel Dominik Holúbek < > dankodo...@gmail.com> wrote: > > > Hello :) > > I looked at the links listed below, seemed interesting, but the main > > problem > > (how to set up such a project) remains unsolved. > > So I think I really do need help :) > > > > It seems to me, though, that this whole thing is much too complicated. I > > need only some simple loading of multiple jars :) > > But if it would work, I don't care how :) > > > > Thanks again! > > > > On Thu, Mar 12, 2009 at 10:07 AM, Ernesto Reinaldo Barreiro < > > reier...@gmail.com> wrote: > > > > > Hi Daniel, > > > Some comments inlined. > > > > > > On Thu, Mar 12, 2009 at 9:37 AM, Daniel Dominik Holúbek < > > > dankodo...@gmail.com> wrote: > > > > > > > Firstly, thanks for you reply :) > > > > I have already read that document regarding wicket and OSGi, but I > > think > > > it > > > > is written for more experienced users at OSGi. As I wrote before, I > > even > > > do > > > > not know how to build a simple web OSGi project (what should I > deploy, > > > how > > > > to install those bundles - I can't access any console..) > > > > > > > > > In my experience getting used to do things the OSGi way is difficult at > > > the beginning but latter on the effort will pay off... In fact it is > > > relatively easy to set up a Wicket-OSGi project if you are using > Eclipse > > > for > > > development and you don't mind using equinox as your OSGi > > > implementation. You could easily build a WEB console to manage plug-ins > > > (bundles) on your application. > > > > > > > > > > I imagine this application like this: I visit some administration > page, > > > > where can I upload a jar file containing the extension. The jar file > > then > > > > installs into running application and creates some records in > database. > > I > > > > can then decide where in the page should this extension appear. > > > > The main problem is this. I think my application should have some > "OSGi > > > > container". I have already tried some "bridge.war" from some webpage > (I > > > > don't remember now, which one was it), it is running correctly, but I > > > > really > > > > do not know what to do now. Add some bundles? Where? How? :) > > > > Btw, I am running Sun Java System Application Server. > > > > > > > > > Probably yo are reffering to [1] ? You will have to export your bundles > > > into > > > the plug-ins section inside this war. This war is just a WEB > application > > > that starts an OSGi runtime (an equinox) and uses a Servlet to manage > it > > > and > > > to redirect requests to your application to the servlets you mount > using > > > the > > > HTTP service provided by the equinox runtime. > > > > > > If you need more help I could help you set up such a project (although > > > currently I do not have much spare time;-) > > > > > > Best, > > > > > > Ernesto > > > > > > References > > > > > > 1-http://www.eclipse.org/equinox/server/ > > > > > > > > > > > -- > > -danoh- > > > -- -danoh-
Re: onComponentTag not processed for visible=false?
> What is the use of being able to attach a form to a ? There is > absolutely NONE. Not necessary TABLE but it is very useful to replace with, for example TR. ** Martin > > On Fri, Mar 13, 2009 at 10:02 AM, Martin Makundi > wrote: I wonder if (nested) forms should simply be allowed to have any tag name the programmer desires? >>> >>> No. Because 99% of the time the programmer is not aware that the form >>> is used in a nested fashion: the form usually is on a Panel, that is >>> used inside another form. The panel is standalone and should use form >>> tags. >> >> Yes, but there is no harm done if it is ALLOWED to have another tag >> name. If the user uses > compatibility would take care of replacing with . >> >> ** >> Martin >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > > > -- > Become a Wicket expert, learn from the best: http://wicketinaction.com > Apache Wicket 1.3.5 is released > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. > > - > 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
Generics question
This is not really Wicket related, but I don't quite know where else to
ask this. The question is: why won't this compile?
// I define a model
IModel> subgenreModel = new
AbstractReadOnlyModel>() {
...
}
// Here I try to use the model
FieldSwitchPanel subgenrefield = *new
SubgenreFieldSwitchPanel("subgenre", subgenreModel);*
// This is the constructor for the class SubgenreFieldSwithcPanel
public SubgenreFieldSwitchPanel(String id, IModelDomainObject>> choices) {
...
}
// Subgenre extends DomainObject
public class Subgenre extends DomainObject{
...
}
The complaint is: The constructor SubgenreFieldSwitchPanel(String,
IModel>) is undefined.
Thanks,
Linda
Re: onComponentTag not processed for visible=false?
It is about clarity: the fact that the form tag is replaced by something else when used inside another form is a technological artifact, not something we're proud of. A form needs to attach to a form. There is no other reasonable alternative tag available. Wicket can't reasonably ensure validity of applications when we allow any tag to be attached to any component. What is the use of being able to attach a form to a ? There is absolutely NONE. Martijn On Fri, Mar 13, 2009 at 10:02 AM, Martin Makundi wrote: >>> I wonder if (nested) forms should simply be allowed to have any tag >>> name the programmer desires? >> >> No. Because 99% of the time the programmer is not aware that the form >> is used in a nested fashion: the form usually is on a Panel, that is >> used inside another form. The panel is standalone and should use form >> tags. > > Yes, but there is no harm done if it is ALLOWED to have another tag > name. If the user uses compatibility would take care of replacing with . > > ** > Martin > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.3.5 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: onComponentTag not processed for visible=false?
>> I wonder if (nested) forms should simply be allowed to have any tag >> name the programmer desires? > > No. Because 99% of the time the programmer is not aware that the form > is used in a nested fashion: the form usually is on a Panel, that is > used inside another form. The panel is standalone and should use form > tags. Yes, but there is no harm done if it is ALLOWED to have another tag name. If the user uses with . ** Martin - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: building a wicket app with maven 1
You (and presumably your client) do know that maven 1 is a technological, and evolutional dead end just like the dodo, right? Martijn On Fri, Mar 13, 2009 at 9:35 AM, Stephen Swinsburg wrote: > Spot on, it's been a while since I've done Maven1 work and this has caught > me out previously I just didn't think of it this time! I'll double check the > jars that are in my Maven2 webapp and presume I will find that jar missing > from the Maven1 build. > > Thanks Linda and Adriano! > > > On 13/03/2009, at 8:05 AM, Linda van der Pal wrote: > >> Maven2 handles transitive dependencies, meaning that if a project you are >> dependent on is dependent on other projects, Maven will add them to the >> classpath. So that's why you didn't have to add that jar manually, Maven did >> it for you. I don't think Maven1 had this functionality. >> >> Linda >> >> Stephen Swinsburg wrote: >>> >>> Thanks Adriano. I don't seem to need that for my Maven2 build though, is >>> there a reason for that? I'll try that though. >>> >>> >>> cheers, >>> Steve >>> >>> >>> >>> On 12/03/2009, at 8:02 PM, Adriano dos Santos Fernandes wrote: >>> Steve Swinsburg escreveu: > > Hi all, > > I have a need to backport my wicket app that builds perfectly in Maven2 > to Maven1. I think I've adjusted all the pom.xml to project.xml correctly > as > all the classes and dependent jars looks like they are where they need to > be, but on startup I get this: > > java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory > > Although in my WEB-INF/lib I have (amongst the others) the required > jars: > > slf4j-log4j12-1.4.2.jar > log4j-1.2.14.jar > > > Any idea what's missing? Does anyone else build under Maven1? You also need slf4j-api-*.jar. Adriano - 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 >>> >>> >>> >>> No virus found in this incoming message. >>> Checked by AVG - www.avg.com Version: 8.5.278 / Virus Database: >>> 270.11.10/1996 - Release Date: 03/11/09 20:42:00 >>> >>> >> >> >> - >> 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 > > -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.3.5 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: building a wicket app with maven 1
Spot on, it's been a while since I've done Maven1 work and this has caught me out previously I just didn't think of it this time! I'll double check the jars that are in my Maven2 webapp and presume I will find that jar missing from the Maven1 build. Thanks Linda and Adriano! On 13/03/2009, at 8:05 AM, Linda van der Pal wrote: Maven2 handles transitive dependencies, meaning that if a project you are dependent on is dependent on other projects, Maven will add them to the classpath. So that's why you didn't have to add that jar manually, Maven did it for you. I don't think Maven1 had this functionality. Linda Stephen Swinsburg wrote: Thanks Adriano. I don't seem to need that for my Maven2 build though, is there a reason for that? I'll try that though. cheers, Steve On 12/03/2009, at 8:02 PM, Adriano dos Santos Fernandes wrote: Steve Swinsburg escreveu: Hi all, I have a need to backport my wicket app that builds perfectly in Maven2 to Maven1. I think I've adjusted all the pom.xml to project.xml correctly as all the classes and dependent jars looks like they are where they need to be, but on startup I get this: java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory Although in my WEB-INF/lib I have (amongst the others) the required jars: slf4j-log4j12-1.4.2.jar log4j-1.2.14.jar Any idea what's missing? Does anyone else build under Maven1? You also need slf4j-api-*.jar. Adriano - 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 No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.278 / Virus Database: 270.11.10/1996 - Release Date: 03/11/09 20:42:00 - 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: onComponentTag not processed for visible=false?
On Fri, Mar 13, 2009 at 9:04 AM, Martin Makundi wrote: > I wonder if (nested) forms should simply be allowed to have any tag > name the programmer desires? No. Because 99% of the time the programmer is not aware that the form is used in a nested fashion: the form usually is on a Panel, that is used inside another form. The panel is standalone and should use form tags. Martijn - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Base64UrlSafe violating RFC 3548?
Hi, I recently stumbled across Base64UrlSafe, which claims 'Provides Base64 encoding and decoding with URL and filename safe alphabet as defined by RFC 3548, section 4.' In the mentioned section of the RFC [1], they use the '-' character for value 62 and '_' for value 63. Strangely, Base64UrlSafe uses '*' for 62 and '-' for 63. Is there any particular reason why it doesn't follow the RFC? Cheers, Jonas [1] http://www.faqs.org/rfcs/rfc3548.html - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Large Scale Applications using Wicket
Serialization is not that bad. Just take care not to serialize all your domain model objects (use LoadableDetachableModel/DataView/DataProvider) Perhaps you might want to have a look at DiskPageStore, too. subbu_tce wrote: > > Do we have any Clustering Solutions other than Terracotta that can > integrate with Wicket to avoid serialization of pages to support > development of applications in a large scale? > > Thanks, > Subbu. > -- View this message in context: http://www.nabble.com/Large-Scale-Applications-using-Wicket-tp22489752p22491990.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: AjaxFallbackButton not working when PasswordTextField is not entered
By default a PasswordTextField is required. So if you don't enter any value in it, the validation will fail and onError will be called instead of onSubmit. I'm guessing you didn't set the other fields to be required, so that's why they don't break the validation. Linda. vela wrote: Hello, I have a PasswordTextField, some text fields and AjaxFallbackButton in the form. If PasswordTextField is not entered and on sumbit of the AjaxFallbackButton, onSubmit(AjaxRequestTarget , ..) is not getting called. But when I remove the PasswordTextField and without entering the values for the other textfields, and on submit of the AjaxFallbackButton, onSubmit(AjaxRequestTarget , ..) is getting called. What is the reason for that? How to make the onSubmit(AjaxRequestTarget , ..) getting called event if no values are entered for PasswordTextField, on submit of the AjaxFallbackButton. No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.278 / Virus Database: 270.11.10/1996 - Release Date: 03/11/09 20:42:00 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: building a wicket app with maven 1
Maven2 handles transitive dependencies, meaning that if a project you are dependent on is dependent on other projects, Maven will add them to the classpath. So that's why you didn't have to add that jar manually, Maven did it for you. I don't think Maven1 had this functionality. Linda Stephen Swinsburg wrote: Thanks Adriano. I don't seem to need that for my Maven2 build though, is there a reason for that? I'll try that though. cheers, Steve On 12/03/2009, at 8:02 PM, Adriano dos Santos Fernandes wrote: Steve Swinsburg escreveu: Hi all, I have a need to backport my wicket app that builds perfectly in Maven2 to Maven1. I think I've adjusted all the pom.xml to project.xml correctly as all the classes and dependent jars looks like they are where they need to be, but on startup I get this: java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory Although in my WEB-INF/lib I have (amongst the others) the required jars: slf4j-log4j12-1.4.2.jar log4j-1.2.14.jar Any idea what's missing? Does anyone else build under Maven1? You also need slf4j-api-*.jar. Adriano - 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 No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.278 / Virus Database: 270.11.10/1996 - Release Date: 03/11/09 20:42:00 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: onComponentTag not processed for visible=false?
> ah, so this fails when the an innerform is invisible and you called
> setoutputmarkupplaceholdertag(true).
>
> that makes sense, and you are right - we do not handle this usecase right now.
>
> please open a jira issue, and if you do not want to wait for a
> snapshot subclass your form and overide it thusly:
Actually I have began using the nested form as follows:
But then I must override as follows (to avoid the form's "invalid tag
name" exception):
protected void onComponentTag(ComponentTag tag) {
tag.setName("form");
super.onComponentTag(tag);
tag.setName("tr");
}
This way I do not need to override the renderPlaceholderTag because it
uses the tag name given in the markup.
I wonder if (nested) forms should simply be allowed to have any tag
name the programmer desires?
Meanwhile, I opened the jira issue:
https://issues.apache.org/jira/browse/WICKET-2166
**
Martin
>
>
>@Override
>protected void renderPlaceholderTag(ComponentTag tag, Response
> response)
>{
>if (isRootForm())
>{
>super.renderPlaceholderTag(tag, response);
>}
>else
>{
>response.write("if (getOutputMarkupId())
>{
>response.write(" id=\"");
>response.write(getMarkupId());
>response.write("\"");
>}
>response.write(" style=\"display:none\">");
>}
>}
>
>
> -igor
>
> On Fri, Mar 13, 2009 at 12:22 AM, Martin Makundi
> wrote:
>>> wicket rewrites nested form tags for you to divs
>>
>> Is it a bug that wicket does not rewrite if the form is not visible?
>>
>> Component.render(final MarkupStream markupStream) {
>>
>> ...
>>
>> if (determineVisibility()) {
>>
>> // render -> replace form with div
>>
>> } else if (markupStream != null)
>> {
>> if (getFlag(FLAG_PLACEHOLDER))
>> {
>> final ComponentTag tag = markupStream.getTag();
>> renderPlaceholderTag(tag, getResponse()); ///
>> Here form does not replace "form" with "div"
>> }
>> markupStream.skipComponent();
>> }
>>
>>
>> **
>> Martin
>>
>>>
>>> -igor
>>>
>>> On Thu, Mar 12, 2009 at 11:52 PM, Martin Makundi
>>> wrote:
Hi!
onComponentTag is not processed when a component is not visible.
This has the implication that nested forms look like >>> style="display:none"> which potentially breaks form processing
in some browsers (ie7).
Is it a general guideline to override renderPlaceholderTag() in such
situations? Or should form override it automatically to handle nested
form tag names?
**
Martin
-
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
AjaxFallbackButton not working when PasswordTextField is not entered
Hello, I have a PasswordTextField, some text fields and AjaxFallbackButton in the form. If PasswordTextField is not entered and on sumbit of the AjaxFallbackButton, onSubmit(AjaxRequestTarget , ..) is not getting called. But when I remove the PasswordTextField and without entering the values for the other textfields, and on submit of the AjaxFallbackButton, onSubmit(AjaxRequestTarget , ..) is getting called. What is the reason for that? How to make the onSubmit(AjaxRequestTarget , ..) getting called event if no values are entered for PasswordTextField, on submit of the AjaxFallbackButton. -- View this message in context: http://www.nabble.com/AjaxFallbackButton-not-working-when-PasswordTextField-is-not-entered-tp22491712p22491712.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: onComponentTag not processed for visible=false?
ah, so this fails when the an innerform is invisible and you called
setoutputmarkupplaceholdertag(true).
that makes sense, and you are right - we do not handle this usecase right now.
please open a jira issue, and if you do not want to wait for a
snapshot subclass your form and overide it thusly:
@Override
protected void renderPlaceholderTag(ComponentTag tag, Response response)
{
if (isRootForm())
{
super.renderPlaceholderTag(tag, response);
}
else
{
response.write("");
}
}
-igor
On Fri, Mar 13, 2009 at 12:22 AM, Martin Makundi
wrote:
>> wicket rewrites nested form tags for you to divs
>
> Is it a bug that wicket does not rewrite if the form is not visible?
>
> Component.render(final MarkupStream markupStream) {
>
> ...
>
> if (determineVisibility()) {
>
> // render -> replace form with div
>
> } else if (markupStream != null)
> {
> if (getFlag(FLAG_PLACEHOLDER))
> {
> final ComponentTag tag = markupStream.getTag();
> renderPlaceholderTag(tag, getResponse()); ///
> Here form does not replace "form" with "div"
> }
> markupStream.skipComponent();
> }
>
>
> **
> Martin
>
>>
>> -igor
>>
>> On Thu, Mar 12, 2009 at 11:52 PM, Martin Makundi
>> wrote:
>>> Hi!
>>>
>>> onComponentTag is not processed when a component is not visible.
>>>
>>> This has the implication that nested forms look like >> style="display:none"> which potentially breaks form processing
>>> in some browsers (ie7).
>>>
>>> Is it a general guideline to override renderPlaceholderTag() in such
>>> situations? Or should form override it automatically to handle nested
>>> form tag names?
>>>
>>> **
>>> Martin
>>>
>>> -
>>> 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: can we get this patch applied to the current snapshot?
taking ListMultipleChoice as another example, your patch leaves it us
public class ListMultipleChoice extends AbstractChoice, T>
when in fact it should be properly declared as
public class ListMultipleChoice extends AbstractChoice, T>
so that getModelObject() properly returns Collection
instead of the unsafe variant Collection
which, once again, will break updatemodel()
in your experience you havent ran into a situation where a component
updates its collection model object. my experience is quiet the
opposite. just trying to make sure we do not paint ourselves into a
corner.
-igor
On Fri, Mar 13, 2009 at 12:31 AM, Igor Vaynberg wrote:
> your patch works because it does not properly refactor
> Palette#getModelCollection(). you left it us:
>
> public Collection getModelCollection()
> {
> return (Collection)getDefaultModelObject();
> }
>
> which is incorrect, it should in fact now return Collection T>, which will break Palette#updateModel()
>
> -igor
>
> On Thu, Mar 12, 2009 at 11:32 PM, James Carman
> wrote:
>> FYI,
>>
>> I have created a new JIRA issue for my proposed API changes:
>>
>> https://issues.apache.org/jira/browse/WICKET-2165
>>
>> I've attached a patch. I've "fixed" all of the places I could find
>> thus far. If I find anymore, I'll upload a new patch.
>>
>> James
>>
>> On Fri, Mar 13, 2009 at 1:59 AM, James Carman
>> wrote:
>>> "Feeding" the list to your component isn't the issue (the constructor
>>> will take what you throw at it). It's using the
>>> getDefaultModelObject() method and trying to modify that list once
>>> you've passed it in that will cause you to have to cast.
>>>
>>> On Fri, Mar 13, 2009 at 1:54 AM, Brill Pappin wrote:
I'm really not sure of all the use-cases... all I know is that I spent some
time trying to get the darn thing to compile using a fairly basic wicket
pattern.
If such a simple thing as feeding a list of items to a component that draws
a list using them is going to give me that much trouble (knowing a
workaround or not), then there is something definitely broken.
- Brill
On 13-Mar-09, at 1:43 AM, James Carman wrote:
> To be clear, the only potential for breakage is where user code tries
> to modify the returned "model object" (of type List)
> without casting it. However, that's a rare usecase (in my opinion)
> and again it's easily overcome by a simple cast.
>
> On Thu, Mar 12, 2009 at 5:10 PM, Igor Vaynberg
> wrote:
>>
>> before applying an api-breaking patch to an rc release we should have
>> a vote on the dev list.
>>
>> -igor
>>
>> On Thu, Mar 12, 2009 at 12:59 PM, Jeremy Thomerson
>> wrote:
>>>
>>> Unless I'm seeing double - this patch has two problems:
>>>
>>> 1 - It is the opposite of what was voted on. The vote was to make
>>> IModel> into IModel>. Your patch makes it
>>> IModel>.
>>>
>>> 2 - The patch causes compile errors that were not fixed.
>>>
>>> I have unassigned myself from the task until those issues are addressed
>>> or I
>>> have time to create my own patch. The best solution would be for
>>> someone to
>>> submit a proper patch that fixes the two problems above or explain to me
>>> what I missed.
>>>
>>> Thanks!
>>>
>>> --
>>> Jeremy Thomerson
>>> http://www.wickettraining.com
>>>
>>>
>>>
>>> On Thu, Mar 12, 2009 at 2:53 PM, Jeremy Thomerson
>>> >>>
wrote:
>>>
I'm reviewing it now. Assuming that it looks fine, and is line with
what
was proposed by the vote thread earlier, I will apply. The vote
passed, so
I don't see a reason not to. I'm not sure how many were binding /
non-binding, but there were eight for, two against.
--
Jeremy Thomerson
http://www.wickettraining.com
On Thu, Mar 12, 2009 at 9:52 AM, Brill Pappin wrote:
> https://issues.apache.org/jira/browse/WICKET-2137
>
> - Brill
>
> -
> 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 unsu
Re: can we get this patch applied to the current snapshot?
your patch works because it does not properly refactor
Palette#getModelCollection(). you left it us:
public Collection getModelCollection()
{
return (Collection)getDefaultModelObject();
}
which is incorrect, it should in fact now return Collection, which will break Palette#updateModel()
-igor
On Thu, Mar 12, 2009 at 11:32 PM, James Carman
wrote:
> FYI,
>
> I have created a new JIRA issue for my proposed API changes:
>
> https://issues.apache.org/jira/browse/WICKET-2165
>
> I've attached a patch. I've "fixed" all of the places I could find
> thus far. If I find anymore, I'll upload a new patch.
>
> James
>
> On Fri, Mar 13, 2009 at 1:59 AM, James Carman
> wrote:
>> "Feeding" the list to your component isn't the issue (the constructor
>> will take what you throw at it). It's using the
>> getDefaultModelObject() method and trying to modify that list once
>> you've passed it in that will cause you to have to cast.
>>
>> On Fri, Mar 13, 2009 at 1:54 AM, Brill Pappin wrote:
>>> I'm really not sure of all the use-cases... all I know is that I spent some
>>> time trying to get the darn thing to compile using a fairly basic wicket
>>> pattern.
>>>
>>> If such a simple thing as feeding a list of items to a component that draws
>>> a list using them is going to give me that much trouble (knowing a
>>> workaround or not), then there is something definitely broken.
>>>
>>> - Brill
>>>
>>> On 13-Mar-09, at 1:43 AM, James Carman wrote:
>>>
To be clear, the only potential for breakage is where user code tries
to modify the returned "model object" (of type List)
without casting it. However, that's a rare usecase (in my opinion)
and again it's easily overcome by a simple cast.
On Thu, Mar 12, 2009 at 5:10 PM, Igor Vaynberg
wrote:
>
> before applying an api-breaking patch to an rc release we should have
> a vote on the dev list.
>
> -igor
>
> On Thu, Mar 12, 2009 at 12:59 PM, Jeremy Thomerson
> wrote:
>>
>> Unless I'm seeing double - this patch has two problems:
>>
>> 1 - It is the opposite of what was voted on. The vote was to make
>> IModel> into IModel>. Your patch makes it
>> IModel>.
>>
>> 2 - The patch causes compile errors that were not fixed.
>>
>> I have unassigned myself from the task until those issues are addressed
>> or I
>> have time to create my own patch. The best solution would be for
>> someone to
>> submit a proper patch that fixes the two problems above or explain to me
>> what I missed.
>>
>> Thanks!
>>
>> --
>> Jeremy Thomerson
>> http://www.wickettraining.com
>>
>>
>>
>> On Thu, Mar 12, 2009 at 2:53 PM, Jeremy Thomerson
>> >>
>>> wrote:
>>
>>> I'm reviewing it now. Assuming that it looks fine, and is line with
>>> what
>>> was proposed by the vote thread earlier, I will apply. The vote
>>> passed, so
>>> I don't see a reason not to. I'm not sure how many were binding /
>>> non-binding, but there were eight for, two against.
>>>
>>> --
>>> Jeremy Thomerson
>>> http://www.wickettraining.com
>>>
>>>
>>>
>>>
>>> On Thu, Mar 12, 2009 at 9:52 AM, Brill Pappin wrote:
>>>
https://issues.apache.org/jira/browse/WICKET-2137
- Brill
-
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: onComponentTag not processed for visible=false?
> wicket rewrites nested form tags for you to divs
Is it a bug that wicket does not rewrite if the form is not visible?
Component.render(final MarkupStream markupStream) {
...
if (determineVisibility()) {
// render -> replace form with div
} else if (markupStream != null)
{
if (getFlag(FLAG_PLACEHOLDER))
{
final ComponentTag tag = markupStream.getTag();
renderPlaceholderTag(tag, getResponse()); ///
Here form does not replace "form" with "div"
}
markupStream.skipComponent();
}
**
Martin
>
> -igor
>
> On Thu, Mar 12, 2009 at 11:52 PM, Martin Makundi
> wrote:
>> Hi!
>>
>> onComponentTag is not processed when a component is not visible.
>>
>> This has the implication that nested forms look like > style="display:none"> which potentially breaks form processing
>> in some browsers (ie7).
>>
>> Is it a general guideline to override renderPlaceholderTag() in such
>> situations? Or should form override it automatically to handle nested
>> form tag names?
>>
>> **
>> Martin
>>
>> -
>> 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: onComponentTag not processed for visible=false?
wicket rewrites nested form tags for you to divs -igor On Thu, Mar 12, 2009 at 11:52 PM, Martin Makundi wrote: > Hi! > > onComponentTag is not processed when a component is not visible. > > This has the implication that nested forms look like style="display:none"> which potentially breaks form processing > in some browsers (ie7). > > Is it a general guideline to override renderPlaceholderTag() in such > situations? Or should form override it automatically to handle nested > form tag names? > > ** > Martin > > - > 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
