Vote/Veto: Should I put 1.5 RC1 on App Engine into production this week?
Hello fellow Wicketeers, I have pretty much completed upgrading my application to Wicket 1.5 RC1. I have rolled it out onto my QA system on Google App Engine, and except for some minor glitches in PersistentPageManager and PageManager (which I'll document later on) it was a rather uncomplicated upgrade. Not that the API changes were fun to work through, but I've seen much much worse upgrades in my life, so thanks for another awesome Wicket release guys!! Wicket 1.5 solves some issues 1.4 had on App Engine (multi tab support, back button, lack of control of the session size), so I feel even a mere Release Candidate is better than the stable 1.4.x releases. I am busy testing the app now, and I would really like to roll it out soon. Unless!! I do wonder if there are maybe any showstoppers I didn't learn about yet. I checked JIRA of course, and nothing in RC2 seems to blocking me. I couldn't find RC3 nor any issues in 1.5.0. So what do you think, yay or nay for putting RC1 into production this week? Cheers, Per -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Vote-Veto-Should-I-put-1-5-RC1-on-App-Engine-into-production-this-week-tp3303781p3303781.html Sent from the Users forum 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: usage of JavascriptFilteredIntoFooterHeaderResponse
Thank you! That's what I needed! - nothing is impossible -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/usage-of-JavascriptFilteredIntoFooterHeaderResponse-tp3302046p3303816.html Sent from the Users forum 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: Vote/Veto: Should I put 1.5 RC1 on App Engine into production this week?
Hi, On Sun, Feb 13, 2011 at 6:39 PM, Per p...@hamburg.de wrote: Hello fellow Wicketeers, I have pretty much completed upgrading my application to Wicket 1.5 RC1. I have rolled it out onto my QA system on Google App Engine, and except for some minor glitches in PersistentPageManager and PageManager (which I'll document later on) it was a rather uncomplicated upgrade. Not that the API changes were fun to work through, but I've seen much much worse upgrades in my life, so thanks for another awesome Wicket release guys!! Did you use https://github.com/wicketstuff/core/tree/master/jdk-1.5-parent/gae-initializer-parentby chance ? If not, then please take a look at GaeInitializer.java and tell us what else did you need to tweak. Wicket 1.5 solves some issues 1.4 had on App Engine (multi tab support, back button, lack of control of the session size), so I feel even a mere Release Candidate is better than the stable 1.4.x releases. I am busy testing the app now, and I would really like to roll it out soon. Unless!! I do wonder if there are maybe any showstoppers I didn't learn about yet. I checked JIRA of course, and nothing in RC2 seems to blocking me. I couldn't find RC3 nor any issues in 1.5.0. I also don't know of any stoppers. So what do you think, yay or nay for putting RC1 into production this week? If you don't find any issues in your testing then I'm 'yay'. Please report if you find something and we will try to fix it as soon as possible! Cheers, Per -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Vote-Veto-Should-I-put-1-5-RC1-on-App-Engine-into-production-this-week-tp3303781p3303781.html Sent from the Users forum 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: Vote/Veto: Should I put 1.5 RC1 on App Engine into production this week?
Hi Martin,
yes, I used your utility, it was great to get me started! Funny enough,
I had prepared several questions (which I then ended up answering by
myself and never posted), and in each of them I was referring to your
utility. Almost asked you directly, but figured it out before I did.
I'll make sure it's mentioned in the overall summary once I am through
with this.
Two items maybe worth mentioning already, since you asked: If you use
the always-on feature in GAE, there's a much higher chance that your
session gets deserialised on a node that was not in use yet. You get an
exception like this:
Caused by: java.lang.IllegalStateException: PageManager for application
quickstart not registered.
at
org.apache.wicket.page.MyPersistentPageManager$SessionEntry.getPageStore(MyPersistentPageManager.java:117)
at
org.apache.wicket.page.MyPersistentPageManager$SessionEntry.readObject(MyPersistentPageManager.java:292)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at
java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:991)
at
java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1865)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1770)
(Ignore the row numbers, that's just my version of the PPM)
It can also happen with a single node of course, but it really hit me
often when run with always-on enabled. I added a simple
getPageManager(); call right into the init() of the application, and
that seems to do the trick for me.
Also, since the PersistentPageManager's isReplicated() returns true,
the DefaultPageStore's prepareForSerialization() always keeps putting
null page objects into the session. This results in a NPE in the
PersistentPageManager's SessionEntry's findPage(), so I added a
null-check there:
private IManageablePage findPage(int id)
{
for (IManageablePage p : pages)
{
if (p==null) {
log.info(sigh, a null page);
}
else if (p.getPageId() == id)
{
return p;
}
}
return null;
}
To be honest, I have no idea why this works at all, given that every
page put into the session is null. But when I tried returning false in
isReplicated() in order to make it actually serialise things, it became
a HUGE mess. But then again that might also be related to that I was at
that time trying to use the default page render strategy. It seems that
1.5 on App Engine doesn't work at all with the default, so I used
getRequestCycleSettings().setRenderStrategy(IRequestCycleSettings.RenderStrategy.REDIRECT_TO_RENDER);
I had been using that render-strategy in 1.4 as well. Since it still
works (and the other doesn't) I guess that's the one for me.
Cheers,
Per
Hi,
On Sun, Feb 13, 2011 at 6:39 PM, Per [hidden email]
/user/SendEmail.jtp?type=nodenode=3303934i=0 wrote:
Hello fellow Wicketeers,
I have pretty much completed upgrading my application to Wicket 1.5
RC1. I
have rolled it out onto my QA system on Google App Engine, and
except for
some minor glitches in PersistentPageManager and PageManager (which
I'll
document later on) it was a rather uncomplicated upgrade. Not that
the API
changes were fun to work through, but I've seen much much worse
upgrades in
my life, so thanks for another awesome Wicket release guys!!
Did you use
https://github.com/wicketstuff/core/tree/master/jdk-1.5-parent/gae-initializer-parentby
chance ?
If not, then please take a look at GaeInitializer.java and tell us
what else
did you need to tweak.
Wicket 1.5 solves some issues 1.4 had on App Engine (multi tab support,
back
button, lack of control of the session size), so I feel even a mere
Release
Candidate is better than the stable 1.4.x releases. I am busy
testing the
app now, and I would really like to roll it out soon.
Unless!! I do wonder if there are maybe any showstoppers I didn't learn
about yet. I checked JIRA of course, and nothing in RC2 seems to
blocking
me. I couldn't find RC3 nor any issues in 1.5.0.
I also don't know of any stoppers.
So what do you think, yay or nay for putting RC1 into production
this week?
If you don't find any issues in your testing then I'm 'yay'.
Please report if you find something and we will try to fix it as soon as
possible!
Cheers,
Per
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Vote-Veto-Should-I-put-1-5-RC1-on-App-Engine-into-production-this-week-tp3303781p3303781.html
Re: Unfriendly Model.ofList etc. methods; can anything be done?
On Sat, Feb 12, 2011 at 8:49 AM, Willis Blackburn wbo...@panix.com wrote: jer...@wickettraining.com wrote: On Sat, Feb 12, 2011 at 7:56 AM, Willis Blackburn wbo...@panix.com wrote: As a side note, rarely should you ever use Model class for a list of things, especially things loaded from a database. If you then pass that model to a component, all the things in it will be serialized. I'm sorry that I said that I loaded the list from a database, since that has apparently created a distraction from my key point, which is that if you start with a ListC and pass it to Model.listOf, you get back something that is not a ListC, which is undesirable and perhaps unnecessary. I understood your key point, which is why I said as a side note but my point still remains. Loading a list and then sticking it into Model class is in almost all cases a *bad* idea. So use the Model constructors instead. The factory methods are just there to help remove some verbosity related to generics. Have you tried this yourself? Because it doesn't work. You can only instantiate Model with a Serializable instance, and java.util.List does not implement Serializable. The whole point of the ofList method is to generate serializable lists, and the documentation even says so: This factory method will automatically rebuild a nonserializable list into a serializable one. You're confusing Model.listOf with Model.of. Sorry, yes, it was early and I wasn't paying attention. Hadn't had my Wheaties yet :) Have you looked at the ListModel class? It may help with what you're looking for. Do you have a suggestion for a better method signature for that method? The problem you are describing, if I understand your description correctly, is a problem with Java generics, not with Wicket's use of them. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: usage of JavascriptFilteredIntoFooterHeaderResponse
Please let us know how it works for you. It is a fairly new feature added a couple releases ago. On Sun, Feb 13, 2011 at 11:09 AM, Zilvinas Vilutis cika...@gmail.comwrote: Thank you! That's what I needed! - nothing is impossible -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/usage-of-JavascriptFilteredIntoFooterHeaderResponse-tp3302046p3303816.html Sent from the Users forum 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 -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: DataTable and toolbar
WebMarkupContainer requires an ID. The magic here is happening in the ToolbarContainer class, which is delegating its rendering to the toolbar that you passed in. The requirement of the toolbar component ID appears to be somewhat arbitrary, probably just to remove confusion about what ID to use, or else for legacy reasons where it may have appeared in the markup. On Fri, Feb 11, 2011 at 7:48 AM, Alex Shubert alex.shub...@gmail.comwrote: It looks like WebMarkupContainer does not require ID at all. It somehow unusuall 2011/2/11 Robert Dahlström robert.dahlst...@bwin.org: As far as I can tell yes. But maybe someone with better knowledge can enlighten us? /Robert -- Best regards Alex - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: Unfriendly Model.ofList etc. methods; can anything be done?
A simpler API would be: public static C IModelListC ofList(final List? extends C list) or even: public static C IModelListC ofList(final ListC list) since you are calling this method with a specific List, and hence the type of the List is known. Scott On Sun, Feb 13, 2011 at 11:32 AM, Jeremy Thomerson jer...@wickettraining.com wrote: On Sat, Feb 12, 2011 at 8:49 AM, Willis Blackburn wbo...@panix.com wrote: jer...@wickettraining.com wrote: On Sat, Feb 12, 2011 at 7:56 AM, Willis Blackburn wbo...@panix.com wrote: As a side note, rarely should you ever use Model class for a list of things, especially things loaded from a database. If you then pass that model to a component, all the things in it will be serialized. I'm sorry that I said that I loaded the list from a database, since that has apparently created a distraction from my key point, which is that if you start with a ListC and pass it to Model.listOf, you get back something that is not a ListC, which is undesirable and perhaps unnecessary. I understood your key point, which is why I said as a side note but my point still remains. Loading a list and then sticking it into Model class is in almost all cases a *bad* idea. So use the Model constructors instead. The factory methods are just there to help remove some verbosity related to generics. Have you tried this yourself? Because it doesn't work. You can only instantiate Model with a Serializable instance, and java.util.List does not implement Serializable. The whole point of the ofList method is to generate serializable lists, and the documentation even says so: This factory method will automatically rebuild a nonserializable list into a serializable one. You're confusing Model.listOf with Model.of. Sorry, yes, it was early and I wasn't paying attention. Hadn't had my Wheaties yet :) Have you looked at the ListModel class? It may help with what you're looking for. Do you have a suggestion for a better method signature for that method? The problem you are describing, if I understand your description correctly, is a problem with Java generics, not with Wicket's use of them. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org* - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Unfriendly Model.ofList etc. methods; can anything be done?
On Feb 13, 2011, at 2:33 PM, jer...@wickettraining.com [via Apache Wicket] wrote: I understood your key point, which is why I said as a side note but my point still remains. Loading a list and then sticking it into Model class is in almost all cases a *bad* idea. I agree with you! But nevertheless there are some cases in which a ModelListC makes sense--even when a database is involved. If, for example, the List is small, and is expensive to generate from the database, then serializing it and keeping it in the session could be the best approach. Sorry, yes, it was early and I wasn't paying attention. Hadn't had my Wheaties yet :) Have you looked at the ListModel class? It may help with what you're looking for. Do you have a suggestion for a better method signature for that method? The problem you are describing, if I understand your description correctly, is a problem with Java generics, not with Wicket's use of them. I hadn't seen ListModel, but thanks--it looks like a good solution. Although it sort of makes Model.listOf even more mysterious, in that Model.listOf doesn't create a ListModel. My suggestion for Model.listOf is simply: public static C IModelListC ofList(final ListC list) In other words it takes a ListC and return an IModelListC, which is (I think) what you'd expect. Maybe the thinking is that Model.listOf may need to return a list of some serializable subclass of C, if C is not serializable itself. W -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Unfriendly-Model-ofList-etc-methods-can-anything-be-done-tp3302712p3304062.html Sent from the Users forum 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
ListView error when using JQuery
I'm creating a page with widgets similar to Yahoo and Google's home pages. The widgets can be dragged around to change their position. This is largely working (using ListView) but I'm getting an error when I drag the bottom widget of one ListView onto the list of another. The page no longer has a reference to the item. I'm calling listView.modelChanging(), changing the backing List, then calling listView.modelChanged(). I've been looking at this and the cause is eluding me...I'm sure I'm missing something dumb. I just put together a quickstart to demonstrate this...it seemed easier than posting a lot of code. The quickstart is available at silverlion.com/flavius/JQuery.zip For this quickstart I used JWicket. I tried the same thing with WiQuery, but Maven can't seem to find the dependency when I put that in the pom file. Thanks in advance for any help. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/ListView-error-when-using-JQuery-tp3304427p3304427.html Sent from the Users forum 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: usage of JavascriptFilteredIntoFooterHeaderResponse
Hi Jeremy,
Thanks for the implementation ( I've found that you're the author of most of
the files :) ) - it will be really useful in the future.
1st problem I ran into - no usage example in Javadocs :) However, mailing
list helped!
... after that
I've found that one of the core WiQuery classes renders javascript with
response.renderString method (
org.wicketstuff.jquery.JQueryBehavior.renderHead(IHeaderResponse) ):
@Override
public void renderHead(IHeaderResponse response) {
try {
super.renderHead(response);
if(getIncludeJQueryJS(response)) {
response.renderJavascriptReference(JQUERY_JS);
if
(Application.DEVELOPMENT.equals(Application.get().getConfigurationType())) {
response.renderJavascriptReference(JQUERY_DEBUG_JS);
}
}
CharSequence script = getOnReadyScript();
if ((script != null) (script.length() 0)) {
StringBuilder builder = new StringBuilder();
builder.append(script
type=\text/javascript\\n$(document).ready(function(){\n);
builder.append(script);
builder.append(\n});/script);
response.renderString(builder.toString());
}
} catch (RuntimeException exc) {
throw exc;
} catch (Exception exc) {
throw new RuntimeException(wrap: + exc.getMessage(), exc);
}
}
Which is not being filtered and gets into header - which causes the
$('document') string to be not valid before jquery.js was loaded.
Basic features looks good and definitely a good start!
Probably I'll need more examples how to use
AbstractResourceDependentResourceReference to create JS Reference
dependencies and make sure the order is all right.
Thank you once again!
-
nothing is impossible
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/usage-of-JavascriptFilteredIntoFooterHeaderResponse-tp3302046p3304493.html
Sent from the Users forum 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
