Re: CheckGroupSelector problem
Looks like CheckGroupSelector does not have a model. You could create a behavior (e.g. by subclassing AbstractBehavior) that would initialize the CheckGroupSelector based on its Check components. In your behavior's renderHead(IHeaderResponse) method, you could render onLoad or onDomReady JavaScript that would iterate over the Check elements and set a flag if any of them are not checked. You would then set the CheckGroupSelector's 'checked' value based on that flag. See CheckGroupSelector.onComponentTag(ComponentTag) for an example of the main JavaScript involved (i.e. finding and iterating through the Check elements). -Ryan On Thu, Apr 10, 2008 at 10:22 AM, atul singh <[EMAIL PROTECTED]> wrote: > I am facing an issue with CheckGroupSelector. > CheckGroupSelector is not showing itself selected, though all of the > Check's > in the CheckGroup come pre-selected based on the underlying model i am > setting up. (That means I have the CheckGroup's list model already > populated > with all individual Check's models). > Is this because CheckGroupSelector does not have a model for itself? > OR am I missing something??? >
Re: Invoulentary session sharing/leakage in Wicket 1.3.x
Did you try HttpSessionStore? -Ryan On Mon, Apr 7, 2008 at 2:00 PM, Edvin Syse <[EMAIL PROTECTED]> wrote: > is it really the wicket session or a page? > > > > I believe it's the session, but I'm not sure. The "hijacker" is able to > navigate through all pages as the hijacked user.. And on the top of every > page there is a logout button and text saying "Logout ". > > I'm not running in a clustered environment, just plain Jetty 6.1.7 in > setuid mode. > > I'm using the SecondLevelCacheSessionStore, but I'm thinking about trying > with the HttpSessionStore now to see if it makes any difference. > > I refer to the session object with a static getter everywhere (I think) > using MySession.get().etc.. > > -- Edvin > > > > On Mon, Apr 7, 2008 at 10:40 PM, Edvin Syse <[EMAIL PROTECTED]> wrote: > > > > Today I deployed an application based on Wicket 1.3.3 that has close to > > > 10.000 users. After a couple of hours we started getting reports from > > > users > > > saying that even upon requesting the login-page, they were already > > > logged in > > > as an arbitrary user. > > > > > > The users they were logged in as had previously performed a succesful > > > login. > > > > > > It seems like the wicket-sessions bleed over between different > > > http-sessions. I tried changing from HybridUrlCodingStrategy to > > > mounting the > > > pages with the normal mountBookmarkablePage() method, but the results > > > are > > > the same. I also tried downgrading to 1.3.2 with the same results. > > > > > > Can anyone think of a logical mistake I might have made? > > > > > > Sincerely, > > > Edvin Syse > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Tomcat dying with Wicket 1.3.2 (Windows / JDK 1.5.0_10)
If you hit a wall in terms of decreasing session timeout or deferring/avoiding session creation, you might want to look at Tomcat's PersistentManager. It passivates idle (but non-expired) sessions out of RAM to either disk or a database. The JDBC version should give you better performance and more room to scale. http://tomcat.apache.org/tomcat-5.5-doc/config/manager.html -Ryan On Fri, Apr 11, 2008 at 9:26 PM, Jeremy Thomerson < [EMAIL PROTECTED]> wrote: > Thanks for the insight - didn't know that the webapp had to make a call to > force the cookie-less support. Someone asked for how often Google is > crawling us. It seems like at any given point of almost any day, we have > one crawler or another going through the site. I included some numbers > below to give an idea. > > Igor - thanks - it could easily be the search form, which is the only > thing > that would be stateful on about 95% of the pages that will be crawled. I > made myself a note yestereday that I need to look at making that a > stateless > form to see if that fixes the unnecessary session creation. I'll post the > results. > > The one thing I have determined from all this (which answers a question > from > the other thread) is that Google (and the other crawlers) is definitely > going to pages with a jsessionid in the URL, and the jsessionid is not > appearing in the search results (with 2 exceptions out of 30,000+ pages > indexed). But I know that maybe only a month ago, there were hundreds of > pages from our site that had jsessionids in the URLs that Google had > indexed. Could it be possible that they are stripping the jsessionid from > URLs they visit now? I haven't found anywhere that they volunteer much > information on this matter. > > Bottom line - thanks for everyone's help - I have a bandaid on this now > which will buy me the time to see what's creating the early unnecessary > sessions. Is there a particular place in the code I should put a > breakpoint > to see where the session is being created / where it says "oh, you have a > stateful page - here's the component that makes it stateful"? That's > where > I'm headed next, so if anyone knows where that piece of code is, the tip > would be greatly appreciated. > > Thanks again, > Jeremy > > Here's a few numbers for the curious. I took a four minute segment of our > logs from a very slow traffic period - middle of the night. In that time, > 67 sessions were created. Then did reverse DNS lookups on the IPs. The > traffic was from: > > cuill.com crawler4 (interesting - new search engine - didn't know > about it before) > googlebot4 > live.com bot1 > unknown13 > user28 > yahoo crawler26 > > > > > On Fri, Apr 11, 2008 at 9:20 PM, Igor Vaynberg <[EMAIL PROTECTED]> > wrote: > > > On Fri, Apr 11, 2008 at 6:37 PM, Jeremy Thomerson > > <[EMAIL PROTECTED]> wrote: > > > If you go to http://www.texashuntfish.com/thf/app/home, you will > notice > > that > > > the first time you hit the page, there are jsessionids in every link > - > > same > > > if you go there with cookies disabled. > > > > as far as i know jsessionid is only appended once an http session is > > created and needs to be tracked. so the fact you see it right after > > you go to /app/home should tell you that right away the session is > > created and bound. not good. something in your page is stateful. > > > > > I think this problem is caused by something making the session bind > at > > an > > > earlier time than it did when I was using 1.2.6 - it's probably still > > > something that I'm doing weird, but I need to find it. > > > > i think this is unlikely. if i remember correctly delayed session > > creation was introduced in 1.3.0. 1.2.6 _always created a session on > > first request_ regardless of whether or not the page you requested was > > stateless or stateful. > > > > -igor > > > > > > > > > > On Fri, Apr 11, 2008 at 3:33 AM, Johan Compagner < > [EMAIL PROTECTED]> > > > wrote: > > > > > > > > > > > > > by the way it is all your own fault that you get so many session. > > > > I just searched for your other mails and i did came across: > "Removing > > the > > > > jsessionid for SEO" > > > > > > > > where you where explaining that you remove the jsessionids from the > > urls.. > > > > > > > > johan > > > > > > > > > > > > On Thu, Apr 3, 2008 at 7:23 AM, Jeremy Thomerson < > > > > [EMAIL PROTECTED]> > > > > wrote: > > > > > > > > > I upgraded my biggest production app from 1.2.6 to 1.3 last week. > > I > > > > have > > > > > had several apps running on 1.3 since it was in beta with no > > problems - > > > > > running for months without restarting. > > > > > > > > > > This app receives more traffic than any of the rest. We have a > > decent > > > > > server, and I had always allowed Tomcat 1.5GB of RAM to operate > > with. > > > > It > > > > > never had a problem doing so, and I didn't have OutOfMemory > errors. > > > > Now, > > > > > after the up
Re: Presented Wicket to my Company...
Arguments that should get some traction with managers: - Wicket is more productive than JSF. The simple creation of custom components, lack of XML configuration and tight Ajax integration mean there's less code to write. This gives you either a faster time to market or more/better features within a given time frame. - Wicket code is easier to maintain than JSF. No XML config means a smaller number of UI artifacts to keep in sync. Since all behavior is expressed in Java code (except whatever JS you choose to add), you can use most of the same techniques to maintain and refactor the UI that you use with the rest of your code base. Wicket's Ajax integration means that you'll rarely, if ever, have duplicate presentation logic to maintain in both server and client side code. - It's easy to hire Wicket developers because all you need are good Java programmers. As long as you have one or more "web experts" on your team to set the UI coding standards, write reusable components, etc., other programmers really don't need to know much about the web. A couple of programmers on my team had never written a web app in their lives and could never really "get" Tapestry 4 (much less JSF). As soon as I wrote a base page, a few custom components and some initial parts of our app in Wicket, these same programmers were happily cranking out UI code, adding Ajax behavior, talking about how cool it was, etc. - Allowing developers to use tools they enjoy directly affects productivity. A programmer who feels forced to use something they hate is generally not going to bust his/her ass to get stuff done. This is a basic worker morale issue. Any manager should understand that higher morale == higher productivity and less turnover. Obviously, the tools need to meet overall business requirements, but that's a separate issue. And I think most companies would be hard- pressed to explain why Wicket doesn't meet their fundamental web development needs. This might be obvious, but my general advice is to talk to managers about the things they care about rather than what you care about. Don't try to convince them of anything but instead explain why their goals are better met by Wicket. The fact that your team wants to use it definitely counts, but probably not for the same reasons. Good luck! -Ryan On Sep 28, 2007, at 6:34 PM, robert.mcguinness wrote: Thanks you and everybody for all the responses. I will be referencing these emails when I argue my point. I'm pushing Wicket as the framework of choice and have already convinced the developers and two of the architects. I just got to get the managers on my side. I will keep everyone posted. Thanks again, much obliged. - rm3 gumnaam wrote: Well here's our story, if it helps you. Traditionally we had a JSP+Struts+EJB2 model for all our projects. For our current project we decided to jump on the JEE5 bandwagon, and started out with JSF+EJB3 (SLSB)+ JPA, Now JSF and JSPs don't mix well, so we choose Facelets, and instead of struts we decided to use Seam, as that was the only available glue between the Web and EJB tier. So we had to learn JSF, Seam, Facelets, EJB3 and JPA. Now seam is no good without Stateful Session Beans so we had to change our SLSBs to Stateful Session Beans, and we had all sort of problems with Extended Persistence Context, not to mention, most developers hated Seam as it was very buggy in those days (late 2006, early 2007). We also had a remote EJB3 API layer, and JPA managed entities (especially the ones with lazy loading relationships) don't mix too well with remoting. And even after learning all these new technologies, our web pages, were still lacking all the fancy AJAX stuff. Now we had to learn Icefaces or ajax4jsf . Every body hated every aspect of this development model. Now we have a much saner development environment. Wicket + EJB3 (bcoz we still need remoting) + Spring + iBatis. If we didn't need that EJB remoting layer I would drop EJB3 like a hot potato. My advice, don't worry about the industry standard thing, if you have good developers , then go with Wicket. The first time I hooked up AjaxFallBackDefaultDataTable with my Spring DAO + iBatis, It nearly brought tears to my eyes. Using iBaits I am able to do sorting,filtering,paginating all in the Database, (as it should be done, instead of storing huge datasets in memory and doing it in code), and the DataTable Component gives me all the hooks to plug this in so smoothly. Can't think how I would have managed this with JSF and JPA. So use Wicket for Web and iBatis for ORM. :) robert.mcguinness wrote: ...to tell you the truth, it impressed the developers but I didn't get that feeling from the top brass. I am pretty sure we will move towards Seam/JSF/Facelets (we have a presentation on that tech next week given by another developer) since it is "standard". Has anyo
Re: [RFE] getMarkupId()
It's potentially confusing because, right now, a markup id is based on the untranslated component id and the underscore is used as a hierarchy separator. To use the underscore for this secondary purpose makes it more difficult to predict the markup id. Whether or not someone *should* be trying to predict markup id's is a different issue but, in general, I think a simple and predictable markup id generation scheme is preferable. At Igor's request, I'll ask for a vote on this on the dev list. -Ryan On Sep 25, 2007, at 12:47 AM, Alex Objelean wrote: Why would a developer be confused by something that is generated automatically? Do you really care if the generated markup id is "quantity1" or "quantity_1" or "quantity-1"? Whats the difference? Ryan Holmes wrote: The automatic transformation of certain characters by a framework is exactly the kind of magic behavior that confuses users and therefore I think the recommended "fix" is a bad idea. -- View this message in context: http://www.nabble.com/-RFE-- getMarkupId%28%29-tf4493344.html#a12874680 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RFE] getMarkupId()
I think you misunderstood me. As a CSS selector,
'#quantity.noOfUnits1232' means "the element with ID 'quantity' and
class 'noOfUnits1232'", while the selector '#quantity\.noOfUnits1232'
refers to an element with a period in its HTML ID. If JQuery cannot
handle a reference to an HTML ID with a period in it, then that's a
JQuery bug since it is a valid ID.
On Sep 25, 2007, at 12:40 AM, Alex Objelean wrote:
It's not a jquery bug at all. The '.' character is interpreted as a
css
class. So, the $("#quantity.noOfUnits1232") translates in element
with ID
"quantity" and css class "noOfUnits1232".
Also, I do not see any problem which can be caused by magical
handling of
markup id. (at least one core developer was agree with this point
of view).
Alex.
Ryan Holmes wrote:
Did you try escaping the '.'? Something like $("#quantity
\.noOfUnits1232").
I refer to Wicket id's with periods in several CSS rules with no
problem. The period is a valid character in HTML id's and I strongly
disagree with the magical id mangling behavior you suggest. If JQuery
can't handle valid HTML id's, that's a JQuery bug and not a Wicket
bug.
-Ryan
On Sep 21, 2007, at 4:44 AM, Alex Objelean wrote:
This is about how wicket generates dynamically markupID.
I have, for instance, the following markup component:
The generated markupId for this component looks like the following:
quantity.noOfUnits1232 .
I suggest to escape any css valid specifiers from the generated
markupId, by
replacing them with something else (for instance '_' character).
The problem appear when I am trying to identify the component by
it's id
using some js library (like jQuery) and as a consequence the result
of this
query: $("#quantity.noOfUnits1232") is invalid.
Thank you!
Alex.
--
View this message in context: http://www.nabble.com/-RFE--
getMarkupId%28%29-tf4493344.html#a12815038
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context: http://www.nabble.com/-RFE--
getMarkupId%28%29-tf4493344.html#a12874553
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RFE] getMarkupId()
Did you try escaping the '.'? Something like $("#quantity
\.noOfUnits1232").
I refer to Wicket id's with periods in several CSS rules with no
problem. The period is a valid character in HTML id's and I strongly
disagree with the magical id mangling behavior you suggest. If JQuery
can't handle valid HTML id's, that's a JQuery bug and not a Wicket bug.
-Ryan
On Sep 21, 2007, at 4:44 AM, Alex Objelean wrote:
This is about how wicket generates dynamically markupID.
I have, for instance, the following markup component:
The generated markupId for this component looks like the following:
quantity.noOfUnits1232 .
I suggest to escape any css valid specifiers from the generated
markupId, by
replacing them with something else (for instance '_' character).
The problem appear when I am trying to identify the component by
it's id
using some js library (like jQuery) and as a consequence the result
of this
query: $("#quantity.noOfUnits1232") is invalid.
Thank you!
Alex.
--
View this message in context: http://www.nabble.com/-RFE--
getMarkupId%28%29-tf4493344.html#a12815038
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: modal window question - opening a modal window on page load
Good idea, Ed. I added the code and explanation to the issue. Glad it
worked for you.
-Ryan
On Sep 10, 2007, at 10:46 AM, Ed _ wrote:
Thanks Ryan,
First pass this has worked well for me. Appreciate your detailed
instructions. Maybe these can be added to the open issue history
itself for other folks till the issue gets closed.
I assume you have to be developer to make changes to the change
history.
-ed
From: [EMAIL PROTECTED]
Subject: Re: modal window question - opening a modal window on
page load
Date: Sun, 9 Sep 2007 22:24:03 -0700
To: users@wicket.apache.org
There is an open issue about this: http://issues.apache.org/jira/
browse/WICKET-12
Read the discussion for some background and possible solutions.
I needed to do the same thing on a couple of pages. First, I tried
using getWindowOpenJavascript() on the modal window (called via
reflection as it's a private method) to get the needed JS, but I
think I ran into a few issues which I've now forgotten (private
'shown' variable wasn't set?).
What I ended up doing was to use JavaScript to call the onclick()
method of a link that opens the modal window from my page's onload
function. Since the modal window is a JavaScript construct anyway I
don't think using JS for the "auto-open" behavior is weird.
The following model ensures that a component is "clicked" only one
time, when the page is initially loaded (probably a common use case).
If you want to open the modal window on every page load, just check
out the JavaScript and the basic concept. This is written for Wicket
1.2 but a similar approach should work for 1.3.
public class ClickOnceOnLoadModel extends AbstractReadOnlyModel {
private final Component component;
private boolean clicked = false;
public ClickOnceOnLoadModel(Component component) {
this.component = component;
}
@Override
public Object getObject(Component cmp) {
if ( !this.clicked ) {
this.clicked = true;
return getClickJs();
}
return null;
}
private String getClickJs() {
StringBuilder sb = new StringBuilder( 64 );
sb.append( "var e=document.getElementById('" );
sb.append( this.component.getMarkupId() );
sb.append( "');e.onclick();" );
return sb.toString();
}
}
You would use it like this:
// Page constructor
public MyPage() {
getBodyContainer().addOnLoadModifier(
new ClickOnceOnLoadModel( modalWindowOpeningLink ),
null );
}
This of course requires a link on your page that opens the same modal
window you want to open automatically. If you really don't want such
a link, you could always hide it with CSS.
If there are more elegant solutions (and I'm sure there are), you'll
probably hear about them soon...
-Ryan
On Sep 9, 2007, at 8:04 PM, Ed _ wrote:
I want to bring up a modal window when I load a page, ie without
clicking a link. I want to use it to prompt the user to enter some
data on the home page before he can proceed. So somehow I have to
enable the show function, how do I do that.
I tried to do something as follows -
FormPanel form = new FormPanel(modal.getContentId(),
StoreBasePath, strId, title);
form.setOutputMarkupId(true);
modal.setContent(form);
modal.setTitle("This is modal window with panel
content.");
modal.setCookieName("modalform");
AjaxRequestTarget target = new AjaxRequestTarget();
modal.show(target);
java.lang.IllegalStateException: No Page found for component
[MarkupContainer [Component id = ModalWindow, page = ,
path = FormPanel:ModalWindow.ModalWindow]]
at wicket.Component.getPage(Component.java:1037)
at wicket.RequestCycle.urlFor(RequestCycle.java:655)
at wicket.Component.urlFor(Component.java:2307)
at wicket.behavior.AbstractAjaxBehavior.getCallbackUrl
(AbstractAjaxBehavior.java:143)
at wicket.ajax.AbstractDefaultAjaxBehavior.getCallbackScript
(AbstractDefaultAjaxBehavior.java:131)
is there a way to do this.
thanks
_
Gear up for Halo® 3 with free downloads and an exclusive offer.
It’s our way of saying thanks for using Windows Live™.
http://gethalo3gear.com?ocid=SeptemberWLHalo3_WLHMTxt_2
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_
Gear up for Halo® 3 with free downloads and an exclusive offer.
It’s our way of saying thanks for using Windows Live™.
http://gethalo3gear.com?ocid=SeptemberWLHalo3_WLHMTxt_2
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket-based website gone on-line
On Sep 10, 2007, at 1:31 AM, Jan Kriesten wrote: looks nice. :-) only thing you should consider is to open external links in a new browser window (so your site stays available). regards, --- jan. Gah! I thought opening new windows for external links went out with the blink tag ;) Seriously, isn't that universally agreed to be almost as annoying as popup ads and sort of tantamount to a big neon sign saying "hi, we haven't used the internet in about 5 years"? I say do as Wikipedia does and leave the navigation up to users. If they want to come back after visiting an external link they'll hit the back button. -Ryan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to handle these nested tags
No, LABEL is a valid HTML element for a Label component (it would be pretty twisted if it wasn't ;)). Besides, if a tag check was failing, the error message would say so. But keep the guesses coming. That's all I've been able to for Kevin so far... -Ryan On Sep 10, 2007, at 12:00 AM, Roland Huss wrote: Hi, ¡¡ Welcome Could it be, that is not supported as markup for a Label component and that you should use something like instead ? ... roland -- View this message in context: http://www.nabble.com/How-to-handle- these-nested-%3Ctable%3E-tags-tf4412208.html#a12587601 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to handle these nested tags
The label doesn't need to be at the same level as the form, just
inside the form. Wicket doesn't care about non-wicket HTML elements
between the form and the label. From Wicket's point of view, your
label component is a direct child of the form.
Maybe I'm missing something obvious here, but your code and HTML
hierarchies look to be in sync. Review basic things like: are you
sure the code you posted is what's actually running in your web server?
-Ryan
On Sep 10, 2007, at 12:09 AM, Kevin Liu wrote:
Thank you for your help! But the major problem is The Label Is Not
at the same level as the form , the Label is deep inside those
table tags. Is there any solution to this kind of problem.
Thanks again~
Kevin Liu <[EMAIL PROTECTED]> wrote: I have a html page that
displays "welcome ,XXX" ,or something like that, the "XXX" is the
current user name, and I use Label to display it. But there is an
exception when it runs.
Unable to find component with id 'userName' in [MarkupContainer
[Component id = _relative_path_prefix_14, page =
com.cmip.web.pages.TopFrame, path =
3:topForm:_relative_path_prefix_13:_relative_path_prefix_14.WebMarkupC
ontainer, isVisible = true, isVersioned = true]]. This means that
you declared wicket:id=userName in your markup, but that you either
did not add the component to your page at all, or that the
hierarchy does not match.
The code:
public TopFrame(){
super();
String name = ((CMIPSession)this.getSession()).getUser().getUserName
();
Label userName = new Label("userName",new Model(name));
Form topForm = new Form("topForm");
topForm.add(userName);
this.add(topForm);
html:
°æ±¾ºÅ£ºV1.0
¡¡ Welcome
updateTime();
-Kevin Liu
-
Pinpoint customers who are looking for what you sell.
-Kevin Liu
-
Pinpoint customers who are looking for what you sell.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to handle these nested tags
hmmm... the hierarchies seem to match. The only weird things I see
are that your img tags are unclosed (Wicket may require valid xml
templates -- I'm not sure because I always use xhtml) and your call
to add the topForm component uses an explicit "this" reference. I
can't remember if "this" with a method call does nothing or if it can
actually interfere with dynamic binding. Either way, you don't want
to do it. Just call "add(topForm)".
If neither of those suggestions work (and I kind of doubt they will),
think about whether your page's superclass might be causing the
problem. For instance, a weird markup inheritance scenario could
conceivably cause this.
-Ryan
On Sep 9, 2007, at 9:58 PM, Kevin Liu wrote:
I have a html page that displays "welcome ,XXX" ,or something like
that, the "XXX" is the current user name, and I use Label to
display it. But there is an exception when it runs.
Unable to find component with id 'userName' in [MarkupContainer
[Component id = _relative_path_prefix_14, page =
com.cmip.web.pages.TopFrame, path =
3:topForm:_relative_path_prefix_13:_relative_path_prefix_14.WebMarkupC
ontainer, isVisible = true, isVersioned = true]]. This means that
you declared wicket:id=userName in your markup, but that you either
did not add the component to your page at all, or that the
hierarchy does not match.
The code:
public TopFrame(){
super();
String name = ((CMIPSession)this.getSession()).getUser
().getUserName();
Label userName = new Label("userName",new Model(name));
Form topForm = new Form("topForm");
topForm.add(userName);
this.add(topForm);
html:
height="85">
cellspacing="0">
°æ±¾ºÅ£ºV1.0
target="mainframe">height="27" border="0" alt="·µ»ØÖ÷Ò³"
onClick="javascript:self.location='Top.html'">
target="mainframe">height="27" border="0">
width="1" height="1">
height="4">
height="1">
width="100%" border="0" cellspacing="0" cellpadding="0">
id="serverTime">
height="23">
cellpadding="1">
¡¡ Welcome
updateTime();
-Kevin Liu
-
Pinpoint customers who are looking for what you sell.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: modal window question - opening a modal window on page load
There is an open issue about this: http://issues.apache.org/jira/
browse/WICKET-12
Read the discussion for some background and possible solutions.
I needed to do the same thing on a couple of pages. First, I tried
using getWindowOpenJavascript() on the modal window (called via
reflection as it's a private method) to get the needed JS, but I
think I ran into a few issues which I've now forgotten (private
'shown' variable wasn't set?).
What I ended up doing was to use JavaScript to call the onclick()
method of a link that opens the modal window from my page's onload
function. Since the modal window is a JavaScript construct anyway I
don't think using JS for the "auto-open" behavior is weird.
The following model ensures that a component is "clicked" only one
time, when the page is initially loaded (probably a common use case).
If you want to open the modal window on every page load, just check
out the JavaScript and the basic concept. This is written for Wicket
1.2 but a similar approach should work for 1.3.
public class ClickOnceOnLoadModel extends AbstractReadOnlyModel {
private final Component component;
private boolean clicked = false;
public ClickOnceOnLoadModel(Component component) {
this.component = component;
}
@Override
public Object getObject(Component cmp) {
if ( !this.clicked ) {
this.clicked = true;
return getClickJs();
}
return null;
}
private String getClickJs() {
StringBuilder sb = new StringBuilder( 64 );
sb.append( "var e=document.getElementById('" );
sb.append( this.component.getMarkupId() );
sb.append( "');e.onclick();" );
return sb.toString();
}
}
You would use it like this:
// Page constructor
public MyPage() {
getBodyContainer().addOnLoadModifier(
new ClickOnceOnLoadModel( modalWindowOpeningLink ), null );
}
This of course requires a link on your page that opens the same modal
window you want to open automatically. If you really don't want such
a link, you could always hide it with CSS.
If there are more elegant solutions (and I'm sure there are), you'll
probably hear about them soon...
-Ryan
On Sep 9, 2007, at 8:04 PM, Ed _ wrote:
I want to bring up a modal window when I load a page, ie without
clicking a link. I want to use it to prompt the user to enter some
data on the home page before he can proceed. So somehow I have to
enable the show function, how do I do that.
I tried to do something as follows -
FormPanel form = new FormPanel(modal.getContentId(),
StoreBasePath, strId, title);
form.setOutputMarkupId(true);
modal.setContent(form);
modal.setTitle("This is modal window with panel
content.");
modal.setCookieName("modalform");
AjaxRequestTarget target = new AjaxRequestTarget();
modal.show(target);
java.lang.IllegalStateException: No Page found for component
[MarkupContainer [Component id = ModalWindow, page = ,
path = FormPanel:ModalWindow.ModalWindow]]
at wicket.Component.getPage(Component.java:1037)
at wicket.RequestCycle.urlFor(RequestCycle.java:655)
at wicket.Component.urlFor(Component.java:2307)
at wicket.behavior.AbstractAjaxBehavior.getCallbackUrl
(AbstractAjaxBehavior.java:143)
at wicket.ajax.AbstractDefaultAjaxBehavior.getCallbackScript
(AbstractDefaultAjaxBehavior.java:131)
is there a way to do this.
thanks
_
Gear up for Halo® 3 with free downloads and an exclusive offer.
It’s our way of saying thanks for using Windows Live™.
http://gethalo3gear.com?ocid=SeptemberWLHalo3_WLHMTxt_2
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: First Day Disgust!
Funny, one of the things I remember being really impressed with when I set up my first Wicket (1.2) app was how incredibly easy it was: 1.) Add wicket jars 2.) Write "hello world" home page 3.) Write WebApplication subclass and specify home page 4.) Map servlet in web.xml 5.) Hit "run" button in Eclipse w/WTP (or whatever your tools of choice are) I figured all that out from this obscure page on the wiki: http:// cwiki.apache.org/WICKET/newuserguide.html#Newuserguide- MyFirstApplication Of course, most people would never guess that a page entitled "My First Application" in the New User Guide might hold the information a new user would need when writing their first Wicket application, so perhaps Wicket is only intended for really, really smart people. -Ryan On Sep 8, 2007, at 6:06 AM, chickabee wrote: Thanks for providing me the primer on web applications and Ant and for not trying to understand what point I am trying to make here. Yes, we are not dealing with nuclear science here and Yes again wicket is just another web application, Did someone disagree with that. I hope not. Once you are out in the market to try the new webapps then it always makes sense to have people be able to get up and running on the basics w/ o efforts and not to have to deal with tricks necessary to get basic app to work. A common expectation is a simple standalone app without Maven/Spring/Hibernate etc unnecessary stuff. Run 'ant' on the command line and here u have the war file, now, make a few changes to experiment and then run 'ant' again to have modified war. Simple. Obviously the current example is for the comfort of wicket creators and not for the comfort of prospective users and that is the problem here. Any one with basic common sense will get this up and running after a day's tinkering around, but that can be avoided by adding simple things here in the examples, that is the point I am trying to sell here only if there are buyers out there with open mind. Al Maw wrote: chickabee wrote: Thanks for the great idea. Note that this is displayed fairly prominently on the web site at http://wicket.apache.org under "QuickStart". It believe it will be good to put a few of the examples application in their own folders and war files so that they can be studied independently without the clutter of 20 projects. We used to have this, however, grouping all the examples into one project has several big advantages: - Getting all the examples running in your IDE is much easier. - We don't have ten extra projects to manage the build files for. - We can easily link to all the examples from a single page. Another thing I notice is that maven is the default build tool used for wicket, I guess it will be good to provide the ant build.xml, just in case someone does not want full maven features. I think we need to write a page on this on the web site that we can send people to. ;-) An Ant build for Wicket isn't special. If you don't know how to use Ant, it's not our job to show you. There are no magic custom Ant tasks we provide, or JSP pre-compilation steps, or anything like that. All you need is to compile your app with the necessary dependencies, just like any other Java app. You'll also need your web.xml, etc. just like any other Java web app. Nothing special here. Regards, Al - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/First-Day- Disgust%21-tf4405663.html#a12569457 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Disable the SecondLevelPageCache?
Hi Eelco, Thanks for the thorough response (as usual). We're almost done converting from Tap 4 to Wicket 1.2 and we'll look into migrating to 1.3 pretty soon. I was planning on reverting to the HttpSessionStore immediately because I assumed the new disk-based store(s) traded performance for memory efficiency (and we have the luxury of not really caring about RAM usage due to a limited number of users in a LAN-only environment). An old benchmark that Jonathan posted (http://www.jroller.com/ JonathanLocke/entry/how_fast_is_wicket) suggested the HttpSessionStore was noticeably faster, but I know there have been a lot of performance improvements since then. I've been pretty cynical about the whole idea of a disk-based store, actually. It always seemed like "jumping a fence" into a servlet container/app server's area of responsibility (had a slightly nasty argument with Johan about that). While it always sounded like a cool and very powerful/useful *option* to build into the framework, I never thought it would be a clear winner over HttpSessionStore. My main fear was that it would lead to a kind of split between some people using one store and some the other, and that it might cascade further into the framework (e.g. design x is a better fit with SLCSS but design y is better for HttpSessionStore) ultimately becoming a big drag for you guys. So that's a long way of saying: damn, I'm impressed. Not only is 1-2ms negligible, it sounds like the SLCSS is a conceptually simpler approach. Oh, and sorry to Johan for being a skeptic. ;) -Ryan On Sep 8, 2007, at 2:27 PM, Eelco Hillenius wrote: On 9/8/07, Ryan Holmes <[EMAIL PROTECTED]> wrote: Is it not recommended because the new disk-based session store is just a better all-around solution or because using the httpsessionstore is dangerous or broken in some way in 1.3? It is a better all-round solution: it is more efficient memory wise, and the cost of serializing and saving is neglect-able in our experience (like 1 or 2 miliseconds per request even without Matej's recent optimizations). HttpSessionStore (in 1.3, but also in 1.2) suffers from some limitations that the SLCSS doesn't have. Particularly, back button history is limited, and while we don't experience many real problems with it, we feel that recording change objects isn't as robust as just serializing the page exactly as it is. It sounds way more efficient to do just the change objects, but compared to just serializing the page, it hardly seems to be in practice. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Disable the SecondLevelPageCache?
Is it not recommended because the new disk-based session store is just a better all-around solution or because using the httpsessionstore is dangerous or broken in some way in 1.3? Thanks, -Ryan On Sep 7, 2007, at 3:10 PM, Matej Knopp wrote: You can revert to httpsessionstore by changing Application.newSessionStore method. But that's not recommended. What are your performance problems? I doubt it is caused by the session store. -Matej On 9/7/07, jamieballing <[EMAIL PROTECTED]> wrote: We are trying to do some performance troubleshooting and want to disable the second level page cache. Is there any way to do this? Thanks, Jamie -- View this message in context: http://www.nabble.com/Disable-the- SecondLevelPageCache--tf4403977.html#a12563895 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WebMarkupContainer without template markup
On Sep 7, 2007, at 8:52 PM, Carlos Pita wrote:
You can also make the components to hide implement some listener (or
just marker) interface X and then do a visitChildren traversal from
page.onBeforeRender as follows:
visitChildren(X.class, new IVisitor() {
public Object component(Component component) {
comp.setVisible(your visibility logic here);
}
});
This is less centralized that keeping a list at the top level, if you
care about this.
Regards,
Carlos
Damn. I just now recommended the same thing. Sorry, didn't notice
your post.
This approach definitely seems cleaner than managing a list of
component references -- I wonder if it works for Scott...
-Ryan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: WebMarkupContainer without template markup
How about using an IVisitor to call setVisible() on the image
components? That way, you wouldn't need to keep an explicit reference
to those image components. You could trigger the visitor in
onBeforeRender() and you could use a marker interface to identify the
image components whose visibility should be changed (called
'IOptionalImage' in the example below). Something like:
public class OptionalImageVisitor implements IVisitor {
private boolean visible;
public OptionalImageVisitor(boolean visible) {
this.visible = visible;
}
public Object component(Component component) {
component.setVisible(this.visible);
}
}
public class MyPage {
public onBeforeRender() {
boolean imagesVisible = ...logic to determine whether images are
visible
visitChildren(IOptionalImage.class, new OptionalImageVisitor
(imagesVisible);
}
}
-Ryan
On Sep 7, 2007, at 1:41 PM, Scott Swank wrote:
Matej,
My issue isn't that the div is rendered, but rather that I have to add
it to the html file in the first place. I think that I could
implement this as a Behavior, but for this problem I just went ahead
and added div tags around the relevant components.
Thanks again,
Scott
On 9/7/07, Matej Knopp <[EMAIL PROTECTED]> wrote:
Can't you just call webmarkupcontainer.setRenderBodyOnly(true) ?
-Matej
On 9/7/07, Scott Swank <[EMAIL PROTECTED]> wrote:
I get what you're saying, but the images in question are scattered
across the page rather than in one place that could simply be
enclosed. Thank you none the less, I do appreciate the insight.
Cheers,
Scott
On 9/7/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
well, thats kinda the point of the enclosure...
it lets you group components together inside it, and let one of
those
components drive the visibility of the entire enclosure
-igor
On 9/7/07, Scott Swank <[EMAIL PROTECTED]> wrote:
I could, but it's kind of the opposite of what I want. I want to
_not_ have to add an enclosing tag to the relevant portions of the
html template. So I don't mind coding a WebMarkupContainer --
I just
want to avoid having to change:
to
div>
The basic problem is that sometimes we have a set of images for a
product (scattered across a few components) and sometimes we
don't.
My thought is to wrap all of the relevant images in such a
container
that knows how to determine isVisible().
Scott
On 9/7/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
you can prob port enclosure to 1.2.6 yourself if you wanted it
badly
-igor
On 9/7/07, Scott Swank <[EMAIL PROTECTED]> wrote:
Pity we're not on 1.3 yet. Thank you though.
Scott
On 9/7/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
no, but you can try wicket:enclosure tag. see javadoc on
Enclosure.java
-igor
On 9/7/07, Scott Swank <[EMAIL PROTECTED]> wrote:
I want to make a few parts of my page visible or not in a
consistent
manner -- i.e. based on the same true/false result, which I
derive
from my model. Can I wrap the relevant components in
WebMarkupContainer without adding a matching tag to my
markup?
Thank you,
Scott
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Scott Swank
reformed mathematician
--
---
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Scott Swank
reformed mathematician
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Scott Swank
reformed mathematician
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: convertToString in custom Converter is not called
They use choice renderers as well as converters.
IChoiceRenderer.getDisplayValue returns an Object that gets converted
to a string. This is from AbstractChoice in Wicket 1.2:
protected void appendOptionHtml(AppendingStringBuffer buffer, Object
choice, int index,
String selected)
{
final String displayValue = (String)getConverter().convert(
renderer.getDisplayValue(choice), String.class);
...
Has this changed in 1.3?
-Ryan
On Aug 13, 2007, at 8:14 AM, Igor Vaynberg wrote:
afik ddcs dont use converters because they use a choice renderer.
see ddc.setchoicerenderer();
-igor
On 8/13/07, Benjamin Ernst <[EMAIL PROTECTED]> wrote:
Hi,
I implemented a custom Converter. It looks like this:
public class AnredeConverter implements IConverter {
public Object convertToObject(String arg0, Locale arg1) {
if(arg0 == null) return null;
return Anrede.fromString(arg0);
}
public String convertToString(Object obj, Locale locale) {
Anrede an = (Anrede) obj;
return an.getValue();
}
}
The I added it to the apllication:
@Override
protected IConverterLocator newConverterLocator() {
ConverterLocator converterLocator = new ConverterLocator();
converterLocator.set(Anrede.class, new AnredeConverter());
return converterLocator;
}
I use it for a DropDownChoice
DropDownChoice anrede = new DropDownChoice("anrede", new
PropertyModel(ma,
"anrede"), Anrede.literals());
add(anrede);
My problem is that the convertToString-Method is never called, so
that the
DropDownChoice is not set to the right value.The convertToObject-
Method
works fine.
How can I tell the DropDownChoice to use the Converter to get the
right
value.
Thanks in advance,
Benjamin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ajax submit form with empty file input
Did you try changing the visibility of your FileUploadField? If it's
not visible, it won't be in the markup and won't be submitted. Not
sure if Wicket will mark the form as multipart anyway, but it's worth
a try.
-Ryan
On Aug 13, 2007, at 9:56 AM, Carlos Pita wrote:
Igor, is there a more or less provided mechanism to avoid wicket js
serialization of certain fields (file inputs in this case) upon form
submission? I mean something as a workaround that won't be a
complete hack
and will be relatively easy to implement. updating behaviors
serialize just
single fields and submit behaviors do its job for the entire form,
so afaik
it's a matter of all or nothing (well, all or one) just right now.
On 8/13/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
no, ajax submits do not support multipart forms.
-igor
On 8/13/07, Carlos Pita <[EMAIL PROTECTED]> wrote:
Hi all,
is it possible to ajax submit a form that has a file input
between its
fields, even if this input is always empty at the time of
submission?
For example, the following example throws a 'ServletRequest does not
contain
multipart content' exception when clicking the ajaxSubmit button,
even
if
form.setMultiPart(false).
Form form = new Form("form");
form.add (new TextField("text", new PropertyModel(this,
"text")));
form.add(new FileUploadField("file"));
form.add(new AjaxButton("ajaxSubmit", form) {
protected void onSubmit(AjaxRequestTarget target,
Form form)
{
}
});
The fact is that I will upload images using another, hidden and not
nested,
form with an iframe as its target, so the above form will never be
submitted
with a non-empty file input.
How can I do this?
Thank you in advance
Carlos
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Real example on Wicket
Our application uses Spring, Hibernate and Wicket with a traditional
service facade architecture and I think it's a good choice for medium
to large code bases (although possibly overkill for smaller
projects). The service facades provide a convenient place to define
transactionality and they keep most of the business logic out of the
UI. Having said that, there's nothing wrong with injecting DAO's into
your Wicket components and skipping the service facade, but the lack
of that tier may be a problem as your code base grows. Here are a few
implementation details that might help you get things up and running:
1) We use Wicket's Spring annotation support (http://www.wicket-
wiki.org.uk/wiki/index.php/Spring#Annotation-based_Approach) to
inject facade beans into pages and components, like so:
@SpringBean
private MyServiceBean myServiceBean;
The initial configuration is slightly tricky, but only because wicket-
spring offers several completely different approaches to injecting
beans.
2) About the only specific support for Hibernate (although it's
easily adaptable to any ORM) in our Wicket classes is the fairly
heavy use of this model (comments and equals/hashcode removed for
clarity):
public class EntityModel extends LoadableDetachableModel {
private final Class clazz;
private final Serializable id;
public EntityModel(Persistable object) {
this( Hibernate.getClass( object ), object.getId(), object );
}
public EntityModel(Class clazz, Serializable id) {
this.clazz = clazz;
this.id = id;
}
public EntityModel(Class clazz, Serializable id, Object object) {
super( object );
this.clazz = clazz;
this.id = id;
}
@Override
protected Object load() {
return HibernateSessionLocator.getSession().get( this.clazz,
this.id );
}
@Override
public int hashCode() {
// Hash code based on clazz and id.
...
}
@Override
public boolean equals(Object obj) {
// Equals based on clazz and id.
...
}
}
That first, very convenient constructor is made possible because all
of our persistable domain objects implement a Persistable interface
that defines the getId() method -- you might want to consider
something similar. Note the use of Hibernate.getClass() in that
constructor, which makes it safe to pass in a Hibernate proxy.
3) The only other Hibernate-specific code we have in our Wicket
classes is something along the lines of
'HibernateSessionLocator.getSession().get(...)' to retrieve domain
objects. We use backing beans in our forms and so we often need to
fetch domain objects based on a primary key stored in a bean. You
could of course use a DAO or service facade method to keep this kind
of thing nicely abstracted away from your Wicket code.
btw, we're using Wicket 1.2, but I think everything mentioned here
applies equally to 1.3.
hth,
-Ryan
On Aug 12, 2007, at 12:15 PM, Mathias P.W Nilsson wrote:
Hi all!
I'm in a aqward situation and thinking of swithing from Struts2,
JSTL, Tiles
to Wicket. I've bought the book Pro Wicket and read 4 chapters. The
book is
very good but I need a real life application tutorial.
My application today integrates with Hibernate. I shouldn't call
the DAO it
the WebPage classes should I?
How about Session Facade pattern and Wicket. How is this done in a
real
world application?
Very thankful for replies!
// Mathias
--
View this message in context: http://www.nabble.com/Real-example-on-
Wicket-tf4257796.html#a12116996
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: general question on dynamic pages
I think one of the keys to getting comfortable with Wicket is to think in terms of plain objects rather than requests, pages, etc. For example, if you were working with a Person object rather than a Login page and you wanted to provide some way of modifying that Person object, you would just add a mutator method to the Person class, right? Well, it's the same thing in Wicket. Just add a method to the Login page class that performs whatever modifications you want. This method might update the models for components on that page, change the visibility of components, replace components with other components, just to name a few possibilities. In the example you gave, this method (the Login page's mutator method) would be called from the onClick() method in the Welcome page's Link, just before calling setResponsePage(). hth, -Ryan On Jul 27, 2007, at 11:20 AM, Will Jaynes wrote: I'm new to Wicket and struggling a bit. I feel I may be stuck in old thinking of action frameworks like Struts or Spring MVC. All of the examples I have looked at so far do all the work of creating and adding components for a page (or panel) in the constructor of the page. Are there other places where this work can be done? In a dynamic page, I can imagine that between the time a page class is constructed and when the page is displayed, there might be changes that have to be made. Where could this code be placed? For example, the Pro Wicket book (around page 32) has an example of a Login and a Welcome page. The Welcome page constructor takes a reference to Login.this, so that a link back to the Login page takes you back to the same instance of the Login page. In this scenario, when the link is clicked and the response page is set to the existing Login page, where is the opportunity to change the Login page, if required? In Struts I would have the Struts action. Here, I'm not so sure. Thanks for any info. Will - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
