Re: I think it's time for a new book.... Igor and Co ?
+1 :) Cheers, Stefan Am 27.07.2012 09:27, schrieb Josh Kamau: What if the developers donate (or do a fund raising... ) to fund the writing of the book? We could set a budget ... then start pledging for the same.. when the pledge amount is enough, we pay and the work begins. Then we get the book for free . or something like that. Josh On Fri, Jul 27, 2012 at 10:23 AM, Michael Mosmann wrote: Am 27.07.2012 00:16, schrieb Igor Vaynberg: On Fri, Jul 27, 2012 at 12:20 AM, Bertrand Guay-Paquet wrote: Seeing how the previous book authors became less active after writing a book I think this is not a very good idea... :-/ Is this because the books didn't sell well enough? i can only speak for myself, define enough :) i agreed to work on the book knowing full well it was not going to sell a million copies. i wrote it so the community has an easily accessible resource. same for me.. but a german market differ from a more global one:) I don't know the authors personally and I don't know much about the publishing world so it could very well be another reason altogether. writing the book was a very long and a very exhausting effort, much much more then i thought it would be. when i was done the book was actually twice as long as what was published, but the publisher wanted me to trim it down to keep the cost low... they would have to charge more if the book had more pages :/ I had to come upfront with how much pages it would be in the end. The publisher made their calculation based on it, so the page count is more strict than some one may think. the combination of those two things has burned me out somewhat. at least enough to make me want to go play with other things for a while. -igor same for me, but more time has passed, so i would take the pain again:) maybe i am a fool:) Michael:) --**--**- To unsubscribe, e-mail: users-unsubscribe@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
Twitter Bootstrap Navigation and JQuery Impromptu demo / tutorial
Hi list, I have written a quick and small tutorial (with demo app and source) about building dynamic menus and breadcrumbs with Twitter Bootstrap and about modal and confirmation dialogs with the Improptu JQuery lib... check it out here if interested: http://www.rent-a-hero.de/cms/node/10 Will be extended with some more details in the next days propably... Comments, suggestions and improvements welcome :) Cheers, Stefan - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: logout
Hi Tom, we are using wicket auth and we can only logout if we use a dedicated Signout page (with template) - if we only logout (and e.g. try to forward right to the homepage with setResponsePage()) it doesn't work and the user always stays logged in as you describe it. We'd love to get rid of the additional Signout page though (because it only says "Good bye" and is rather annoying for regular users I think ...) :) Stefan Am 25.06.2012 13:38, schrieb Tom Eugelink: Ok. The actual problem I have is that wicket auth keeps logging in automatically. This is a side effect of a.o. BASIC authentication (not sure if that is used in this case, but the behavior is similar) which sends the login credentials with every request, even if you have logged out in the mean time. To enforce a new login via the login page, one usually places some marker in the session telling the authenticator class that it should not accept the current credentials until a valid login page submit was done. But since Wicket keeps doing things to the session, I'm not able to get this marker to work. Are there any people using auth and that are able to fully log out? Tom On 2012-06-25 13:29, Martin Grigorov wrote: Hi Tom, I agree with your vision. But since Wicket is a framework around the Servlet API we call HttpSession.invalidate(). This triggers some web container internal workings and at some point Wicket is called back (see javax.servlet.http.HttpSessionListener/HttpSessionBindingListener) and Wicket clears everything that it added to this session. What happens with this session later is not our business. It may be teared down or recycled, we really don't care. Next time we need to store something in the http session we just call: httpRequest.getSession(true) and use it. I know you use recent version of Wicket (6.x ?) and there are no pagemaps since Wicket 1.5.0 but if you find that anything leaks then it is a bug and it should be fixed. On Sat, Jun 23, 2012 at 11:31 AM, Tom Eugelink wrote: Which means that upon logout, these values should be removed / cleared. A session does not represent a user, it is a construct to bind request, no more no less. All other usages are bolted on and should be bolted off. You don't tear down the house, just because you are moving. Tom On 2012-06-23 10:18, Bert wrote: But Wicket also stores the page map in the session to support back button functionality. If you only change the status, than the user could possibly (depending on how you construct your page) go back after the logout and see the last pages. This could be a problem on public computers. You could also see a session as representing a user, not a browser. Than, invalidating the session on logout makes perfect sense to me. regards - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket 1.5 and nested forms
Thank you very much, Thomas, I was struggling with exactly this problem
for a couple of hours yesterday... I think this should be changed back
or at least be configurable in the next versions !
Cheers,
Stefan
Am 13.06.2012 17:14, schrieb Thomas Heigl:
Hello,
In case anyone else is encountering this problem when migrating from 1.4 to
1.5, I solved it by overriding delegateSubmit in my form:
public static enum SubmitOrder {
/** Submit form submitter before forms (1.5 Default) */
OUTSIDE_IN,
/** Submit form submitter after forms (1.4 Default) */
INSIDE_OUT
}
private SubmitOrder submitOrder = SubmitOrder.OUTSIDE_IN;
@Override
protected void delegateSubmit(IFormSubmitter submittingComponent) {
switch (submitOrder) {
case OUTSIDE_IN:
super.delegateSubmit(submittingComponent);
break;
case INSIDE_OUT:
super.delegateSubmit(null);
if (submittingComponent != null) {
submittingComponent.onSubmit();
}
break;
}
}
Cheers,
Thomas
On Wed, May 9, 2012 at 3:07 PM, Thomas Heigl wrote:
Hey Martin,
WICKET-3705 links to https://issues.apache.org/jira/browse/WICKET-1894
which says that this order is changed in 1.4.15
I upgraded to Wicket 1.5 from Wicket 1.4.20 and it still has been working
with 1.4.20.
This is the way how it works in 1.5/6.x. I'm not sure why it is not
documented.
But there are different opinions about it:
https://issues.apache.org/jira/browse/WICKET-3705
I just thought about it some more and I think the new behavior is quite
counter intuitive. For instance my following usecase:
final class CompoundForm extends BaseForm {
public CompoundSearchRequestForm(String id, final IModel model) {
super(id, model);
add(new BaseForm("baseForm", model));
add(new ConfigurationForm("configurationForm", model));
add(new SettingsForm("settingsForm", model));
add(new AjaxButton("save") {
@Override
protected void onSubmit(AjaxRequestTarget target, Form form) {
// do nothing -> delegated to form's onSubmit
}
});
}
@Override
protected void onSubmit() {
super.onSubmit();
listener.saveModel(getModelObject());
}
}
I moved the buttons onSubmit logic to the form's logic to mimic Wicket 1.4
behavior. This works, but the button is now pretty useless and just
triggers a form submit. In the form's onSubmit on the other hand I don't
have (direct) access to the AjaxRequestTarget so I'd have to split
functionality into the two handlers and always think about which order they
are called in.
The problems get harder if you don't have complete control over the nested
form structure. For instance, when you are using the Wizards from
wicket-extensions. They always wrap their contents in a compound form. We
use ajaxified versions of Wizards extensively and the new form submit flow
makes them very hard to use. The next/finish/previous links of the wizard
are now called before any of the actual forms inside the wizard had their
onSubmit handler called. The buttons in fact *replace* the inner form
before it has been submitted and I had to move the wizards state change
logic to onConfigure to make it work again:
@Override
public void onActiveStepChanged(IWizardStep newStep) {
// do nothing -> logic moved to #onConfigure to prevent replacement of
the form before validation of nested forms
}
@Override
protected void onConfigure() {
super.onConfigure();
final IWizardStep activeStep = getActiveStep();
getForm().replace(activeStep.getView(VIEW_ID, this, this));
getForm().replace(activeStep.getHeader(HEADER_ID, this, this));
}
I worked around these problems but I'd greatly prefer a way to configure
the form submit order somewhere. Ideally on the compound form or the ajax
button.
Thomas
On Wed, May 9, 2012 at 1:24 PM, Martin Grigorovwrote:
On Wed, May 9, 2012 at 2:22 PM, Martin Grigorov
wrote:
Hi Thomas,
On Wed, May 9, 2012 at 2:12 PM, Thomas Heigl
wrote:
Hello,
I notices a strange behavior after upgrading to Wicket 1.5. Nested
forms
are submitted in a different order.
I have structures like this:
- Compound Form
-- Subform 1
-- Subform 2
-- Subform 3
- Submit Link/Button for Compound Form
In Wicket 1.4 the order of calls to onSubmit was like this:
1. Subforms
2. Compound Form
3. Submit Link/Button
In multiple locations I had logic in the subforms' onSubmit handlers
that
do cleanup, re-attaching of models to entities etc. before my links
submit
handler is called and persists my model object.
In Wicket 1.5 the submit link's handler that I use for my main logic is
actually called before the subforms:
1. Submit Link
2. Subforms
3. Compound Form
I can fix this by moving all my compound form logic from the
link/buttons
onSubmit handler to the compound form's handler, but wanted to check
first
if this behavior is intentional?
Is this the way to do it in Wicket 1.5?
This is the way how it works in 1.5/6.x. I'm not sure why it is not
documented.
But there are different opinions about it:
https://issues.apache.org/jira/browse/WICKET-3705
WICKET-3705 links to https://issues.
Open WiQuery modal dialog as message / feedback panel
Hi there,
I am trying to open a WiQuery dialog on certain events, e.g. after a row
of an Inmethod datagrid is edited and saved...
the dialog opens fine when using a link on the page (adding a
WiQueryEventBehavior to it, as explained in the WiQuery quickstart example).
But if I try to open it on saving an edited row, I get a Javascript error:
*ERROR:*Wicket.Ajax.Call.processEvaluation: Exception evaluating javascript:
TypeError: Cannot call method 'dialog' of null
This is in my datagrid panel:
SubmitCancelColumn submitCancelColumn = new SubmitCancelColumn(
"esd", new Model("Edit")) {
@Override
protected void onSubmitted(AjaxRequestTarget target,
IModel rowModel, WebMarkupContainer rowComponent) {
super.onSubmitted(target, rowModel, rowComponent);
try {
saveOrUpdateTgl(glid, rowModel.getObject());
// try to open dialog in parent page
*findParent(GlTglDetailPage.class).showInfoDialog(getString("save_pos_success"),
target);*
...
Here is the code of the parent page:
in the Constructor:
dialog = new Dialog("dialog");
dialog.setModal(true);
content = new Label("content", new
AbstractReadOnlyModel() {
private static final long serialVersionUID = 1L;
@Override
public String getObject() {
return contentString;
}
});
content.setOutputMarkupId(true);
dialog.add(content);
add(dialog);
...
And a function where I want to open the dialog with the updated content:
public void showInfoDialog(String msg, AjaxRequestTarget target) {
contentString = msg;
target.add(content);
dialog.open(target);
If I print out the target in the function it contains this:
[AjaxRequestTarget@-830155084 markupIdToComponent [{id1e=[RowItem
[Component id = 1]], feedback5=[FeedbackPanel [Component id =
feedback]], content17=[Component id = content]}], prependJavaScript
[[]], appendJavaScript [[new Effect.Highlight($('feedback5'), {
startcolor: '#C9DBE7', duration: 4.0 });, new
Effect.Fade($('feedback5'), { duration: 5.0 });,
$('#dialog2').dialog('open');]]
So to me it looks ok, it adds
$('#dialog2').dialog('open');
to the target... I am not quite sure what the target really is in this
case, though?
Does anybody know what the problem may be?
I've found this http://code.google.com/p/wiquery/issues/detail?id=143,
but I'm not sure this is really related to my problem and if there is a
real solution to this...
Thanks a lot in advance,
Stefan
Re: wiquery, wicket 1.5.6 and wicket authroles
Hi,
yes, invalidateNow() gets called and it seems to go into all the session
cleanup/remove stuff that comes after that...
but somehow, I get to the homepage in the end and I'm still (again?)
logged in :O
But only if WiQuery is involved... although I didn't see any WiQuery
related call while stepping through the debug session :(
Any more ideas?
Best,
Stefan
Am 10.05.2012 10:58, schrieb Martin Grigorov:
On Thu, May 10, 2012 at 11:48 AM, Stefan Moises wrote:
Hi,
hm, that's weird... if I set the response page I get redirected to the home
page, but I am NOT logged out... even if ...logout() and ...invalidate()
seem to get called... ?
No error, no exception, no nothing...
Any ideas?
Put a breakpoint in Session#detach() and see whether #invalidateNow()
is executed.
Thanks,
Stefan
Am 10.05.2012 10:34, schrieb Martin Grigorov:
Hi,
On Thu, May 10, 2012 at 11:31 AM, Stefan Moises
wrote:
Hi there,
I have integrated WiQuery 1.5.5 in Wicket 1.5.6 and I am using Wicket
Authroles for a login functionality (combined with Apache Shiro) for more
complex rights/rules.
Everything works fine, but when I try to logout using my Signout page, I
get
an infinite redirect loop in the browser (too many redirects, stating a
302
HTTP error) ... if I remove WiQuery, everything is working fine again and
I
can properly logout.
Now I have no idea where to even start to identify the problem...
My Signout page really doesn't do much:
public class GlSignoutPage extends GlBasePage {
public GlSignoutPage(PageParameters parameters) {
super(parameters);
SecurityUtils.getSubject().logout();
getSession().invalidate();
try with adding here:
setResponsePage(getApplication().getHomePage());
}
}
The Signin page, however, is working... so it shouldn't be a problem that
there is no valid session yet or something like that...
Now my questions are:
1. does anybody use WiQuery with Authroles (or maybe even Shiro)
2. is there any known incompatibility between WiQuery 1.5.5 and Wicket
1.5.6? If so, when will WiQuery 1.5.6. be released?
3. does anybody have any clues what the problem may be?
Thanks a lot,
Stefan
--
Mit den besten Grüßen aus Nürnberg,
Stefan Moises
***********
Stefan Moises
Senior Softwareentwickler
Leiter Modulentwicklung
shoptimax GmbH
Guntherstraße 45 a
90461 Nürnberg
Amtsgericht Nürnberg HRB 21703
GF Friedrich Schreieck
Tel.: 0911/25566-0
Fax: 0911/25566-29
moi...@shoptimax.de
http://www.shoptimax.de
***
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Mit den besten Grüßen aus Nürnberg,
Stefan Moises
***********
Stefan Moises
Senior Softwareentwickler
Leiter Modulentwicklung
shoptimax GmbH
Guntherstraße 45 a
90461 Nürnberg
Amtsgericht Nürnberg HRB 21703
GF Friedrich Schreieck
Tel.: 0911/25566-0
Fax: 0911/25566-29
moi...@shoptimax.de
http://www.shoptimax.de
***
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Mit den besten Grüßen aus Nürnberg,
Stefan Moises
***********
Stefan Moises
Senior Softwareentwickler
Leiter Modulentwicklung
shoptimax GmbH
Guntherstraße 45 a
90461 Nürnberg
Amtsgericht Nürnberg HRB 21703
GF Friedrich Schreieck
Tel.: 0911/25566-0
Fax: 0911/25566-29
moi...@shoptimax.de
http://www.shoptimax.de
***
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: wiquery, wicket 1.5.6 and wicket authroles
Hi,
hm, that's weird... if I set the response page I get redirected to the
home page, but I am NOT logged out... even if ...logout() and
...invalidate() seem to get called... ?
No error, no exception, no nothing...
Any ideas?
Thanks,
Stefan
Am 10.05.2012 10:34, schrieb Martin Grigorov:
Hi,
On Thu, May 10, 2012 at 11:31 AM, Stefan Moises wrote:
Hi there,
I have integrated WiQuery 1.5.5 in Wicket 1.5.6 and I am using Wicket
Authroles for a login functionality (combined with Apache Shiro) for more
complex rights/rules.
Everything works fine, but when I try to logout using my Signout page, I get
an infinite redirect loop in the browser (too many redirects, stating a 302
HTTP error) ... if I remove WiQuery, everything is working fine again and I
can properly logout.
Now I have no idea where to even start to identify the problem...
My Signout page really doesn't do much:
public class GlSignoutPage extends GlBasePage {
public GlSignoutPage(PageParameters parameters) {
super(parameters);
SecurityUtils.getSubject().logout();
getSession().invalidate();
try with adding here:
setResponsePage(getApplication().getHomePage());
}
}
The Signin page, however, is working... so it shouldn't be a problem that
there is no valid session yet or something like that...
Now my questions are:
1. does anybody use WiQuery with Authroles (or maybe even Shiro)
2. is there any known incompatibility between WiQuery 1.5.5 and Wicket
1.5.6? If so, when will WiQuery 1.5.6. be released?
3. does anybody have any clues what the problem may be?
Thanks a lot,
Stefan
--
Mit den besten Grüßen aus Nürnberg,
Stefan Moises
*******
Stefan Moises
Senior Softwareentwickler
Leiter Modulentwicklung
shoptimax GmbH
Guntherstraße 45 a
90461 Nürnberg
Amtsgericht Nürnberg HRB 21703
GF Friedrich Schreieck
Tel.: 0911/25566-0
Fax: 0911/25566-29
moi...@shoptimax.de
http://www.shoptimax.de
***
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Mit den besten Grüßen aus Nürnberg,
Stefan Moises
*******
Stefan Moises
Senior Softwareentwickler
Leiter Modulentwicklung
shoptimax GmbH
Guntherstraße 45 a
90461 Nürnberg
Amtsgericht Nürnberg HRB 21703
GF Friedrich Schreieck
Tel.: 0911/25566-0
Fax: 0911/25566-29
moi...@shoptimax.de
http://www.shoptimax.de
***
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
wiquery, wicket 1.5.6 and wicket authroles
Hi there,
I have integrated WiQuery 1.5.5 in Wicket 1.5.6 and I am using Wicket
Authroles for a login functionality (combined with Apache Shiro) for
more complex rights/rules.
Everything works fine, but when I try to logout using my Signout page, I
get an infinite redirect loop in the browser (too many redirects,
stating a 302 HTTP error) ... if I remove WiQuery, everything is working
fine again and I can properly logout.
Now I have no idea where to even start to identify the problem...
My Signout page really doesn't do much:
public class GlSignoutPage extends GlBasePage {
public GlSignoutPage(PageParameters parameters) {
super(parameters);
SecurityUtils.getSubject().logout();
getSession().invalidate();
}
}
The Signin page, however, is working... so it shouldn't be a problem
that there is no valid session yet or something like that...
Now my questions are:
1. does anybody use WiQuery with Authroles (or maybe even Shiro)
2. is there any known incompatibility between WiQuery 1.5.5 and Wicket
1.5.6? If so, when will WiQuery 1.5.6. be released?
3. does anybody have any clues what the problem may be?
Thanks a lot,
Stefan
--
Mit den besten Grüßen aus Nürnberg,
Stefan Moises
*******
Stefan Moises
Senior Softwareentwickler
Leiter Modulentwicklung
shoptimax GmbH
Guntherstraße 45 a
90461 Nürnberg
Amtsgericht Nürnberg HRB 21703
GF Friedrich Schreieck
Tel.: 0911/25566-0
Fax: 0911/25566-29
moi...@shoptimax.de
http://www.shoptimax.de
***
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
