Re: Nicer URLs in Wicket
/mount/point!MK!3!MK! johan On 7/29/07, Matej Knopp [EMAIL PROTECTED] wrote: The example is also online: http://wicketstuff.org/wicket13/ajax/ So far I'm not sure what should the default look like /mount/point|3| or /mount/point(3) or maybe something else? Does anyone have an opinion about this? -Matej On 7/29/07, Matej Knopp [EMAIL PROTECTED] wrote: I'm not entirely sure. First, this only works with mounts, so you need to mount a page to get this (specify a mount point). Although I don't see this as a big problem, because if you really care about URLs, you're mointing your pages anyway. But to make it default - I don't know. It's could in theory break existing applications, e.g. when someone is passing |3| as page parameter. Not very likely, I know, but it's a bit too late before 1.3 to do such switch IMHO. -Matej On 7/29/07, ZedroS Schwart [EMAIL PROTECTED] wrote: That's great ! Could it become the basic behavior for wicket url ? Personally I find the current url behavior in wicket to be quite unfriendly. In fact, it's among the few aspects I dislike in wicket :$ ++ Joseph On 7/29/07, Matej Knopp [EMAIL PROTECTED] wrote: Hi folks, I've committed two classes that improve Wicket mounted URLs in a significant way. The URLs stay bookmarkable even after clicking a link or submitting form, and the AJAX changes are preserved on reload. Basically, what does is that when you hit a bookmarkable page such as /my/mount/point you are immediately redirected to * /my/mount/point|3| where |3| is the pageId. The URL is fully bookmarkable. The pageId in URL is ignored if page with given ID doesn't exist in session or doesn't match the mount point. Also this preserves the initial page parameters, so /my/mount/point/param1/value1 becomes /my/mount/point/param1/value1|3|. The | separators are configurable and can be changed to e.g. (3) or anything else you want. (Although [ ] get escaped so it doesn't look pretty). Good thing is that the URL remains stable and bookmarkable during the whole page existence, so you no longer see the ?wicket:interface=:3::: string in your URL. Usage is very simple, you just need to mount the page using HybridUrlCodingStrategy, e.g. mount(new HybridUrlCodingStrategy(ratings, RatingsPage.class)); mount(new IndexedHybridUrlCodingStrategy(todo-list, TodoList.class )); I've already change all Ajax examples to use this strategy, so to see it in action you just update wicket and wicket-examples from SVN, or wait until we redeploy the live examples. -Matej * The redirect is necessary for pages with AJAX stuff, so that the page instance is preserved on reload (otherwise with bookmarkable URL new instance of page would be created on every reload, which discards the AJAX changes) - 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: Can we do straight print in a java web application?
where is the print server installed?? on the client? then talking to it from the server is pretty hard (the client has to initiate everything) but als installing such a thing is not really user web friendly. Why cant you generate it on the server (html, pdf or just an image) then send that back? On 8/19/07, Eko S.W. [EMAIL PROTECTED] wrote: sorry, send button accidentally clicked :) 3. When printing instruction occur, printer server will do the printing job Is it applicable? Is there anybody who have the same problem? I found one link here : http://discuss.joelonsoftware.com/default.asp?joel.3.227710.4 I hope I have explained it well Thanks in advance Eko SW - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Servlet spec 2.3 vs. 2.4
they should run fine on 2.4 (tomcat 5) or 2.5. (tomcat 6) as long as the 2.4/2.5 methods are not called. I guess they are just new methods that aren't implemented yet? johan On 8/20/07, David Leangen [EMAIL PROTECTED] wrote: Just out of curiosity... Is there a reason why Wicket is using 2.3 of the servlet spec? Would it be possible to move to 2.4? Or is that non-trivial? There are currently 2 classes that do not compile with 2.4: BufferedHttpServletResponse MockHttpServletResponse Should I send in a patch? Cheers, Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to set wicket's locale?
then you browser tells wicket that it should use English . But you can set it yourself: Session.setLocale() johan On 8/22/07, smithfox [EMAIL PROTECTED] wrote: I used RequiredTextField, when the field is empty, the feedback show some meesage in English, How to change it to Chinese. -- View this message in context: http://www.nabble.com/How-to-set-wicket%27s-locale--tf4309547.html#a12268483 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: wicket vs tapestry ?
i think igor has some more info... On 8/22/07, Alex Shneyderman [EMAIL PROTECTED] wrote: I just started to look for a component based framework. I came across both tapestry and wicket (and it would be hard not to as you guys share the same host) but I kind of fail to see what the differences are? From my limited experiments with both, wicket and tapestry seem to be quite similar. So, I wonder if there is anything I am not seeing? Anyone has a comparisson map of wicket vs tapestry? Alex. PS: I like both frameworks for their lightness I just feel that I will need to stick with one to be pragmatic :-( - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PageStore listener...
Or make the fields itself not transient, but a proxy that has a transient field and the proxy can deserialize and inject itself again (see wicket-ioc project) johan On 8/23/07, Matej Knopp [EMAIL PROTECTED] wrote: Why can't you just implement read/writeObject on your page/component? -Matej On 8/23/07, Jan Kriesten [EMAIL PROTECTED] wrote: Hi, is there a way to add a listener to PageStore events (storePage/getPage)? I'm still looking for a clean way to re-inject Pages/Components when they are deserialized. This way I could just set some fields transient and have them injected again if necessary. I gave IComponentOnBeforeRenderListener a look as a hook to do this, but that is called _after_ Components onBeforeRender(), so it's not usable for that. Regards, --- Jan. - 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: Constructor of Component not DRY?
i think that is grown this way, previously the model constructor did some
more i believe
Also i don't like this(id,null) because thats just horrible, If you call the
constructor with the model then the model shouldn't be null.
a nicer way could be
public Component(final String id, IModel model)
{
this(id);
this.model = wrapModel(model);
}
johan
On 8/23/07, Martin Funk [EMAIL PROTECTED] wrote:
Hi,
doing a little code reading and trying to understand what I read, I came
across org.apache.wicket.Component 's constructors.
To my eyes the two constructors look very much alike and I wonder why
they were not chained like this:
public Component(final String id)
{
this(id, null);
}
Which chapter in the Java schoolbook should I reread?
Martin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Component Factory and code against interface
We can do that because all our components implement specific interfaces
which changes
the state of the component. For example
interface ILabelMethods
{
setBackground(Color color)
setForeground(Color color)
// and so on
}
and all those implementations do record the change
johan
On 8/24/07, Sam Hough [EMAIL PROTECTED] wrote:
Thanks Johan,
Glad it wasn't a totally silly idea. Any top tips or problems you can
share?
Nice that Igor's approach by its very nature avoids sending the same
component more than once. Trees are great ;)
Johan Compagner wrote:
this is how we also do it. Have a changes recorder per component, that
records changes and when the component renders it sets the dirty flag
to false
On 8/23/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
On 8/23/07, Sam Hough [EMAIL PROTECTED] wrote:
Two motivations for dirty components being sent automatically are:
1) What gets updated may be through quite convoluted logic. e.g. user
changes ownership of a record so delete button gets disabled. I don't
really
want to code that the delete button needs resending...
how is any UI framework supposed to know that this happened? the
component
knows how to render itself based on this record you provide via a
model,
but
it cannot tell it changed. this seems like such a corner case.
here is what i would suggest
interface IDirtyStateAware { boolean isDirty(); } let your components
that
know how to check if they are dirty or not implement this. i dont think
these should be as granular as a button, but probably bigger components
-
like a panel that contains the button.
then:
AjaxFallbackLink link=new AjaxFallbackLink(link) {
abstract onClick(); // this is where processing happens
onClick(AjaxRequestTarget target) {
onClick();
getPage().visit(new component.visitor() {
visitcomponent(component c) {
if (c instanceof idirtystateaware) {
if (((idirtystateaware)c).isDirty()) {
target.addcomponent(c);
}
return CONTINUE_BUT_DONOT_GO_DEEPER;
}
return CONTINUE;
}
}
}
-igor
2) I'm probably missing some Wicket magic but as we have the HTML
edition
and Ajax edition Id like the onsubmit etc handlers not to see any
Ajax
stuff.
At the moment I'm pondering having something like:
AppSpecificPanel extends OurPanelBase. We then have the normal Wicket
implementation with an adapter that does the work for OurPanelBase.
The
idea
being that:
* New developers are given a simple set of Components approved by our
tech
lead and tested.
* New developers can't fiddle with full power of Wicket.
* Bulk of application code is not tied to Wicket.
* At runtime can have different implementations of a particular
component
based on the client.
Obviously the huge downside is added complexity and trying to avoid
inventing our own API. I intend to have our own base class for Panel,
Button... etc so that we can be consistent about a variety of things.
Sorry I've rambled a bit.
igor.vaynberg wrote:
On 8/23/07, Sam Hough [EMAIL PROTECTED] wrote:
Say my onSubmit handler changes three components, as I understand
it, I
have
to hand code feeding those three components to the
AjaxRequestTarget.
This
seems cumbersome and slightly error prone. I think for our
application,
if
the components kept track of changes, I could automate which
components
are
sent back. Guess what I'm asking is if anything that already
exists
in
Wicket keeps track of component changes? Can't imagine it would be
easy
otherwise without really heavy duty AOP etc...
heh, there is nothing that automatically marks components as
dirty()
because
wicket doesnt know what you do inside your components. wicket is
unmanaged.
but i dont really understand the issue. you have
onclick(ajaxrequesttarget
t) { dosomething(); t.addcomponent() }
so in your case you mean inside dosomething() you do something to x
components, but you dont know which x components they are?
-igor
Thanks again Igor.
igor.vaynberg wrote:
not really sure what you mean when you say marking components as
dirty...
have you seen ajaxfallback* components? those will use ajax when
its
there,
and fallback on regular requests when its not. so you dont even
need
a
factory necessarily.
-igor
On 8/23/07, Sam Hough [EMAIL PROTECTED] wrote:
Thanks Igor,
Because we have to support Ajax and non-Ajax version I was
wondering
about
hiding details of making components Ajax friendly in the
factory.
so
setOutputMarkupId(true) etc and hiding Ajax
Re: Migration to Wicket 1.3
http://wicketstuff.org/wicket13/forminput/ and for example the string field reports the message just fine. So what are you doing different? johan On 8/28/07, dzenanr [EMAIL PROTECTED] wrote: I have done the following in my form and still no error messages displayed (key is a String parameter): ValidationError validationError = new ValidationError(); validationError.addMessageKey(key); error(validationError); Even in something simple as required text field, where all work is done by Wicket (no validations on my part), I cannot see the error message from Wicket when no value is entered for that required field. Matej Knopp-2 wrote: The validators work a bit differently in 1.3 you need to use the error(IValidationError error) on IValidatable inside your IValidator.validate(IValidatable validatable); as IValidationError you can use the convenience class ValidationError. e.g. ValidationError error = new ValidationError(); error.addMessageKey(validationKey); validatable.error(error); -Matej On 8/28/07, dzenanr [EMAIL PROTECTED] wrote: I have almost done the migration of my web applications to Wicket 1.3. I have read on the Wiki all about the migration and I have consulted the Javadoc. The only thing that I am not sure how to do is a display of form validation errors using FeedbackPanel. In Wicket 1.2, the validation errors are displayed properly by using the error(String) method in a form: String validationError = LocalizedText.getText(this, key); error(validationError); In Wicket 1.3, the same validations are successful, but the error messages are not visible in the Feedback panel used in a page where the form is added. I have tried different things but without success. Please give me a hint. Dzenan -- View this message in context: http://www.nabble.com/Migration-to-Wicket-1.3-tf4341987.html#a12368746 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Migration-to-Wicket-1.3-tf4341987.html#a12369480 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Panel/Localizer issue
i changed it on 2 places. On 8/29/07, Johan Compagner [EMAIL PROTECTED] wrote: yes that should also be lazy through a model can you create an jira issue ? (with a patch if possible) On 8/29/07, Edvin Syse [EMAIL PROTECTED] wrote: I have found that when I create a new Palette with the constructor: (String id, IModel model, IModel choicesModel, IChoiceRenderer choiceRenderer, int rows, boolean allowOrder) .. it calls add(newAvailableHeader(AVAILABLE_HEADER_ID)) in the constructor, which in turn does a: new Label(componentId, getString(palette.available, null, Available)); This gives the same error message, since the Palette is not added to the page yet. Should this be rewritten to new Label(componentId, new ResourceModel(palette.available)); or something instead or am I missing something? -- Edvin Edvin Syse wrote: Thank you! That both solved the problem and made my code cleaner :) -- Edvin Matej Knopp wrote: You should use ResourceModel for this, it does the localization/message lookup for you. -Matej On 8/28/07, Edvin Syse [EMAIL PROTECTED] wrote: Hi, When I instantiate a Panel that does getLocalizer().getString() in the constructor, I obviously get the errormessage: WARN [Localizer] Tried to retrieve a localized string for a component that has not yet been added to the page. This can sometimes lead to an invalid or no localized resource returned. Make sure you are not calling Component#getString() inside your Component's constructor. Offending component: [MarkupContainer [Component id = idHere, page = No Page, path = path-here]] This is understandable, since I haven't added the component to a page before the constructor is run. In the constructor, I do things like: add(new Label(articleTitle, new Model(getLocalizer().getString(articleTitle, this; and: deleteLink.add(new ConfirmBehaviour(getLocalizer().getString(confirmDelete, this))); Is there a way to create the panel and give it a page-instance directly, or how should I get around this the wicket way? I use 1.3-SNAPSHOT, btw. -- Edvin - 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: No localizer has been set
yes then you give the component for which it can get a localizer.
But i fixed it already in trunk anyway. toString() won't try to construct
the message
johan
On 8/30/07, Martin Bednář [EMAIL PROTECTED] wrote:
Johan Compagner napsal(a):
thats odd
on your production machine you have enabled debugging:
if (log.isDebugEnabled())
{
log.debug(detaching + this + for requestCycle +
RequestCycle.get());
}
and that code is not executed for development machine?
Thats a bit the reverse what it should be..
But the problem is that StringResourceModel.toString() calls getString()
thats wrong it shouldn't do that.
OK, what's the preferred way to localize data in ListView.populateItem
I found this on wicket wiki item.add(new Label(name, new
StringResourceModel(wrapper.getValue(), null, null)));
after changing to new StringResourceModel(wrapper.getValue(), this,
null) it's working on production server too.
Martin
johan
On 8/29/07, Martin Bednář [EMAIL PROTECTED] wrote:
I use code below, it works on my development machine (linux, jetty6)
but
don't work on production server (linux,tomcat-5, tomcat 5.5).
Any advice ?
public LanguageCheckBoxPanel(String id) {
super(id);
for (LanguageSelectOption languageOption :
LanguageModel.languages) {
languages.add(new CheckBoxLanguageWrapper(languageOption));
}
add(new ListView(languageList, languages) {
protected void populateItem(ListItem item) {
CheckBoxLanguageWrapper wrapper =
(CheckBoxLanguageWrapper) item
.getModelObject();
//On this line code fails
item.add(new Label(name, new
StringResourceModel(wrapper
.getValue(), null, null)));
item.add(new CheckBox(check, new
PropertyModel(wrapper,
selected)));
}
});
}
Stack trace
WicketMessage: Exception in rendering component: [Component id = name,
page = cz.triax.marathon.statistics.BatchPrintPage, path =
2:navomaticBorder:form:languagePanel:languageList:0:name.Label,
isVisible = true, isVersioned = false]
Root cause:
java.lang.IllegalStateException: No localizer has been set at
wicket.model.StringResourceModel.getString(StringResourceModel.java
:397)
at
wicket.model.StringResourceModel.toString(StringResourceModel.java:464)
at java.lang.String.valueOf(String.java:2827) at
java.lang.StringBuffer.append(StringBuffer.java:219) at
wicket.model.AbstractDetachableModel.attach(
AbstractDetachableModel.java
:60)
at
wicket.model.AbstractDetachableModel.getObject(
AbstractDetachableModel.java:101)
at wicket.Component.getModelObject(Component.java:983) at
wicket.Component.getModelObjectAsString(Component.java:998) at
wicket.markup.html.basic.Label.onComponentTagBody(Label.java:113) at
wicket.Component.renderComponent(Component.java:1712) at
wicket.markup.html.WebComponent.onRender(WebComponent.java:61) at
wicket.Component.render(Component.java:1526) at
wicket.MarkupContainer.renderNext(MarkupContainer.java:1334) at
wicket.MarkupContainer.renderComponentTagBody(MarkupContainer.java:982)
at wicket.MarkupContainer.onComponentTagBody(MarkupContainer.java:917)
at wicket.Component.renderComponent(Component.java:1712) at
wicket.MarkupContainer.onRender(MarkupContainer.java:927) at
wicket.Component.render(Component.java:1526) at
wicket.markup.html.list.ListView.renderItem(ListView.java:676) at
wicket.markup.html.list.ListView.onRender(ListView.java:637) at
wicket.Component.render(Component.java:1526) at
wicket.MarkupContainer.renderNext(MarkupContainer.java:1334) at
wicket.MarkupContainer.renderComponentTagBody(MarkupContainer.java:982)
at
wicket.MarkupContainer.renderAssociatedMarkup(MarkupContainer.java:571)
at wicket.markup.html.panel.Panel.onComponentTagBody(Panel.java:108) at
wicket.Component.renderComponent(Component.java:1712) at
wicket.MarkupContainer.onRender(MarkupContainer.java:927) at
wicket.Component.render(Component.java:1526) at
wicket.MarkupContainer.renderNext(MarkupContainer.java:1334) at
wicket.MarkupContainer.renderComponentTagBody(MarkupContainer.java:982)
at wicket.MarkupContainer.onComponentTagBody(MarkupContainer.java:917)
at wicket.markup.html.form.Form.onComponentTagBody(Form.java:779) at
wicket.Component.renderComponent(Component.java:1712) at
wicket.MarkupContainer.onRender(MarkupContainer.java:927) at
wicket.markup.html.form.Form.onRender(Form.java:850) at
wicket.Component.render(Component.java:1526) at
wicket.MarkupContainer.renderNext(MarkupContainer.java:1334) at
wicket.MarkupContainer.renderComponentTagBody(MarkupContainer.java:982)
at wicket.markup.html.border.Border.renderBodyComponent(Border.java
:300)
at wicket.markup.html.border.Border.resolve(Border.java
Re: Session.get() from non-Wicket-Filter/Servlet and the RequestCycle
look at the source :) On 8/31/07, Thomas Singer [EMAIL PROTECTED] wrote: Matej and Johan, thanks for your feed-back. I've tried to avoid the WicketSessionFilter and make everything work from our code. Just curious: is the WicketSessionFilter handled something special by Wicket? Or how does it get the WebSession reference? Tom Matej Knopp wrote: You don't interact with WicketSessionFilter directly. You just set it up, providing name of your WicketFilter ad argument. You need to map the WicketSessionFilter to same url as your non-wicket filter/servlet and make sure that you use a non-wicket filter WicketSessionFilter gets invoked first. Then in your custom filter/servlet you can obtain wicket session using just Session.get(). -Matej On 8/31/07, Thomas Singer [EMAIL PROTECTED] wrote: What is the preferred way of obtaining a WebSession from a non-Wicket-Filter/Servlet. I've taken a look at WicketSessionFilter, but this one requires a filterName init parameter and seems to expect the session as a HttpSession parameter. But how the WebSession should come into the HttpSession without setting it from the wicket code? Tom - 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: Session.get() from non-Wicket-Filter/Servlet and the RequestCycle
Reading your mails i think you are a bit confused. to make it clear to me what you think WicketSessionFilter does Do you think that the WicketSessionFilter CREATES a WicketSession object for you? If you think that then that is what the big confusion is all about in this thread. The only thing the filter does is getting an existing wicket session that is stored in the http session and setting it for you in the the thread local so that you can access it from a none wicket thing. Ofcourse you need to first hit something in wicket itself. So that the wicket filter/servlet request did make one. Else it will always be empty. johan On 8/31/07, Thomas Singer [EMAIL PROTECTED] wrote: OK, let's look at the sources of WicketSessionFilter. According to my understanding: init() method: - the filterName init parameter (which is stored as a member, but should in a local variable) defines the sessionKey doFilter() method: - first the httpSession will be fetched if available - out of the httpSession the (wicket-)session is fetched as attribute using the sessionKey - only if this one is found, it will be set to Session.set() This creates following question for me: - Where the httpSession attribute with the sessionKey is set? - Is there a working example available where WicketSessionFilter is used? Tom Johan Compagner wrote: again look at the source :) Session.get() will create a WicketSession object. (Session.findOrCreate ()) And if you then make a statefull page that has to be stored in the session, the session will also be stored. (Session.bind()) johan On 8/31/07, Thomas Singer [EMAIL PROTECTED] wrote: Did you read my first mail in this thread? How does the WebSession reference comes into the HttpSession? That's what I don't understand for now. Tom Johan Compagner wrote: look at the source :) On 8/31/07, Thomas Singer [EMAIL PROTECTED] wrote: Matej and Johan, thanks for your feed-back. I've tried to avoid the WicketSessionFilter and make everything work from our code. Just curious: is the WicketSessionFilter handled something special by Wicket? Or how does it get the WebSession reference? Tom Matej Knopp wrote: You don't interact with WicketSessionFilter directly. You just set it up, providing name of your WicketFilter ad argument. You need to map the WicketSessionFilter to same url as your non-wicket filter/servlet and make sure that you use a non-wicket filter WicketSessionFilter gets invoked first. Then in your custom filter/servlet you can obtain wicket session using just Session.get(). -Matej On 8/31/07, Thomas Singer [EMAIL PROTECTED] wrote: What is the preferred way of obtaining a WebSession from a non-Wicket-Filter/Servlet. I've taken a look at WicketSessionFilter, but this one requires a filterName init parameter and seems to expect the session as a HttpSession parameter. But how the WebSession should come into the HttpSession without setting it from the wicket code? Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session.get() from non-Wicket-Filter/Servlet and the RequestCycle
we already have that but it is not in the filter because the filter doesn't have anything to do with that kind of stuff its in WebApplication.getSessionAttributePrefix(final WebRequest request) (dont know why it needs the request param) and then appended with: Session.SESSION_ATTRIBUTE_NAME that makes the key. The problem is that in WicketSessionFilter we can't call that WebApplication method. maybe we can refactor it a bit to make it more clear so that WebApplication gets a static method that gets only the filtername johan On 9/1/07, Thomas Singer [EMAIL PROTECTED] wrote: Ah, that's the secret missing link. I then suggest to have a method getSessionKey(String wicketFilterName) which is used by the normal WicketFilter to read/write and the WicketSessionFilter to read the WebSession. Thanks, Eelco! -- Cheers, Tom Eelco Hillenius wrote: No, my confusion is about how it comes into the HttpSession accessible under the attribute name which is build only in WicketSessionFilter (aren't the HttpSession's attributes not a simple string-to-object map so you need the right key to get the value?). That's why you need to provide the filterName argument when setting up the filter. The filtername is used as the key by the actual Wicket application, so if you set the filterName to the name of the filter you want to get the session from, the two keys match. 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: AjaxFallbackButton really require Form in constructor?
It is needed i guess if we say that the method
protected abstract void onSubmit(AjaxRequestTarget ajaxrequesttarget, Form
form1);
needs a form parameter that can't be null
Also i see something strange in the AjaxButton because if you dont give the
form then the form parameter
can be null:
public AjaxButton(String id)
{
this(id, null);
}
public Form getForm()
{
if(form != null)
return form;
else
return super.getForm();
}
public AjaxButton(String id, final Form form)
{
super(id);
this.form = form;
add(new AjaxFormSubmitBehavior(onclick, form) {
protected void onSubmit(AjaxRequestTarget target)
{
AjaxButton.this.onSubmit(target, form);
}
protected void onError(AjaxRequestTarget target)
{
AjaxButton.this.onError(target, form);
}
i think this is wrong, but maybe it was on purpose?
i think it should be:
public AjaxButton(String id)
{
this(id, null);
}
public Form getForm()
{
if(form != null)
return form;
else
return super.getForm();
}
public AjaxButton(String id, final Form form)
{
super(id);
this.form = form;
add(new AjaxFormSubmitBehavior(onclick, form) {
protected void onSubmit(AjaxRequestTarget target)
{
AjaxButton.this.onSubmit(target, getForm());
}
protected void onError(AjaxRequestTarget target)
{
AjaxButton.this.onError(target, getForm());
}
So that we return the given form or try to find one.
johan
On 9/3/07, Sam Hough [EMAIL PROTECTED] wrote:
Since neither AjaxButton or Button require Form in the constructor why
does
AjaxFallbackButton? Seems a shame to make it required if not really
needed...
I'm not quite clear from the source or comments what the difference is in
AjaxButton between the behaviour from the two different constructors...
--
View this message in context:
http://www.nabble.com/AjaxFallbackButton-really-require-Form-in-constructor--tf4370843.html#a12457890
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Change of Button interface
The intent was that not all kind of components could be a button because of the single inheritance that java gives us But like Matej said, everywhere we do an instance check of button we should change that to do it on IFormSubmittingComponent johan On 9/3/07, David Leangen [EMAIL PROTECTED] wrote: Been trying to update to 1.3 and encountered some problems with SubmitLink. Before, SubmitLink extended Button, so there were no problems with forms. SubmitLinks could be used interchangeably with Buttons, and life was good. Now, SubmitLink implements IFormSubmittingComponent, so it's breaking some code. Implementing the interface seems reasonable to me, but the code hasn't kept up with this change of mentality and there are some inconsistencies. In the wicket code, I tried changing Form.setDefaultButton(Button button) to Form.setDefaultButton(IFormSubmittingComponent button) But this doesn't work, since some methods like onComponentTagBody are programmed to the Button implementation rather than the IFormSubmittingComponent interface. It seems like a few things still need to be sorted out, or maybe the SubmitLink should go back to extending button. What's the story with this? What's the intent with the ISubmittingComponent interface vs. Button vs. SubmitLink? I don't mind trying out some stuff, but please tell me the direction that you're going with this. Thanks! David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Component Factory and code against interface
a bit more info: in wicket 1.3 (default with SLC) the change objects aren't
really used anymore
(they are not stored). They only cause an increment of the page version
number..
johan
On 9/3/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
igor.vaynberg wrote:
On 8/23/07, Sam Hough [EMAIL PROTECTED] wrote:
heh, there is nothing that automatically marks components as dirty()
because
wicket doesnt know what you do inside your components. wicket is
unmanaged.
If I do Component.setVersioned(true) and hook in my own
IPageVersionManager
won't Wicket effectively track dirty components for me? In a lot of user
interactions very few components will change so presumably using Wicket
component level versioning would be more effecient for us? It won't
track
everything but since setEnabled, setVisible etc are final I've not that
many
choices...
Wicket's change tracking is only done for explicit changes though. For
instance:
private class CurrentPageChange extends Change {
private final int currentPage;
CurrentPageChange(int currentPage) {
this.currentPage = currentPage;
}
public void undo() {
setCurrentPage(currentPage);
}
}
...
addStateChange(new CurrentPageChange(this.currentPage));
You can definitively use this for your own purposes. However, I would
think that the typical thing *you* want to react on are model changes.
You can use this mechanism for it as well, but it might be heavier
than you'd like.
Eelco
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: compressing javascript resources
and in the mean time your code is obfuscated and hard to read/copy :) On 9/3/07, Ryan Sonnek [EMAIL PROTECTED] wrote: Most of the good minification libraries do more than just stripping comments. usual features include: * strip comments * rename local variables to save space (ex: myLocalVariable becomes a) * collapse string concatination. this is a nice performance enhancement that will change multiline/verbose strings into one line. (ex: my + newline + text becomes mynewlinetext) Also, for what it's worth, the current wicket JavascriptStripper breaks on my app. I'm using prototype and scriptaculous, and when I enable the current wicket compression, my app no longer works. I get javascript errors left and right. Just another reason to allow for this to be pluggable, IMO. On 9/3/07, Matej Knopp [EMAIL PROTECTED] wrote: Yeah, we strip commends, there are tools that can also reduce things like local variable names, etc. -Matej On 9/3/07, Igor Vaynberg [EMAIL PROTECTED] wrote: well yeah, but we _already_ strip comments, that is why i was wondering what the point of a plugin-minification would be. -igor On 9/3/07, Matej Knopp [EMAIL PROTECTED] wrote: Well, I don't find it surprising. Lot of javascript code are comments, and if you strip them out, you have less content to compress, thus the numbers are smaller. You can set as high compression as you want, but the comments still make difference. (Not so much for whitespaces imho) -Matej On 9/3/07, Igor Vaynberg [EMAIL PROTECTED] wrote: still seems a bit counterintuitive to me. maybe gzip doesnt use a very high compression setting to trade off time. but oh well, numbers dont lie. -igor On 9/2/07, Ryan Sonnek [EMAIL PROTECTED] wrote: Dean Edwards also had a recent blog posting on this topic. His recommendation is to compress and gzip content whenever possible. http://dean.edwards.name/weblog/2007/08/js-compression/ On 9/2/07, Ryan Sonnek [EMAIL PROTECTED] wrote: gzip and minifing *do* go together. Here's a really great site that compares the different approaches. http://compressorrater.thruhere.net/ minifing before gziping shows a considerable reduction in content size (usually between 5-10 percent). On 9/2/07, Igor Vaynberg [EMAIL PROTECTED] wrote: so we should do one or the other, i got the impression that his tool complained because js was not minified even though it was gzipped. -igor On 9/2/07, Matej Knopp [EMAIL PROTECTED] wrote: For certain browsers (even IE6) the GZIP compression doesn't work. And if you have a lot of javascripts (YUI, dojo, ...) it can make a difference. -Matej On 9/2/07, Igor Vaynberg [EMAIL PROTECTED] wrote: ermwhat exactly is the point of minifing AND gziping javascript or anything else? if you take a zip file and then zip it again do you get a smaller file? -igor On 9/1/07, Ryan Sonnek [EMAIL PROTECTED] wrote: excellent! Thanks Matej. Let me know if you have any other ideas on this. As soon as there's an abstraction in place, i'll be happy to create a wicketstuff project with the dojo (and maybe YUI) compressors! https://issues.apache.org/jira/browse/WICKET-918 On 9/1/07, Matej Knopp [EMAIL PROTECTED] wrote: I don't see reason why not, you can create a RFE in jira. -Matej On 9/2/07, Ryan Sonnek [EMAIL PROTECTED] wrote: Creating a pluggable interface for this would allow for non-ASL solutions to be hosted through wicket-stuff projects. The default implementation could stay as it is today. On 9/1/07, Matej Knopp [EMAIL PROTECTED] wrote: Well, I certainly didn't want to reinvent the wheel. But all existing solutions I was able to find either relied on a third part library (shrinksafe) or had license not compatible with ASL. So I just wrote a simple stripper. I think it still helps a lot, I didn't want to build a perfect stripper. If you know of a solution that doesn't mean
Re: compressing javascript resources
And if yui uses that one for there own then yes it works pretty good, code is hardly readable anymore ;( On 9/3/07, Eelco Hillenius [EMAIL PROTECTED] wrote: On 9/1/07, Matej Knopp [EMAIL PROTECTED] wrote: Well, I certainly didn't want to reinvent the wheel. But all existing solutions I was able to find either relied on a third part library (shrinksafe) or had license not compatible with ASL. So I just wrote a simple stripper. I think it still helps a lot, I didn't want to build a perfect stripper. YUI's license is compatible, so http://www.julienlecomte.net/blog/2007/08/13/introducing-the-yui-compressor/ might work, right? Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: compressing javascript resources
thats a pretty nice one, it also compresses CSS. It does depend on rhino and another jar so its a total of 3 jars so it should be outside the wicket core or extentions (a project by itself?) also all the examples that i see are with the command line and input filenames i hope it has a interface where you can talk with it in java and with input streams/readers johan On 9/3/07, Eelco Hillenius [EMAIL PROTECTED] wrote: On 9/1/07, Matej Knopp [EMAIL PROTECTED] wrote: Well, I certainly didn't want to reinvent the wheel. But all existing solutions I was able to find either relied on a third part library (shrinksafe) or had license not compatible with ASL. So I just wrote a simple stripper. I think it still helps a lot, I didn't want to build a perfect stripper. YUI's license is compatible, so http://www.julienlecomte.net/blog/2007/08/13/introducing-the-yui-compressor/ might work, right? Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: compressing javascript resources
don't know if that is really feasible to do. because then we have to scan through the complete classpath for resources like js and css and then compress them all and keep a reference to that compression all the time thats could be quite a waste. it all depends on how long it really takes johan On 9/4/07, David Bernard [EMAIL PROTECTED] wrote: Yes simpler and automatic if all run fine. I like to avoid late compilation/interpretation like JSP. Is it possible to do it at start-up time (force the compression and caching) of the webapp and to stop the start if something break ? Eelco Hillenius wrote: I use a other approach for the same goal (http optimization), to avoid minification and compression at run-time do it at compile-time. But if you do it at run-time once and cache the results (like we do) you can keep things a lot simpler and automatic. 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: NoClassDefFoundError: Tomcat problem?
thats very odd if that is the case, looks like a tomcat bug to me. On 9/4/07, Ghodmode [EMAIL PROTECTED] wrote: On 9/4/07, Igor Vaynberg [EMAIL PROTECTED] wrote: go to quickstart dir and run mvn package, that will create a war you can deploy on any servlet container. -igor I tried to take your advice, but I didn't have any success. I'll spare everyone the painful details. The end result is the same. If I try to deploy a new Web application under Tomcat which uses Wicket, I get NoClassDefFoundError. I don't know why, but Tomcat is not loading the JAR files in WEB-INF/lib. However, I've discovered that it works fine if I unjar wicket-1.3.0-beta3.jar into WEB-INF/classes. This isn't my preferred way to do this, but it will works for now and it will let me continue. Thank you, Vince
Re: compressing javascript resources
i don't think that will work very easily because the component will make ResourceReferences to its internal css and js files and will be outputted as shared resources. Then all those urls should also be redirected. johan On 9/4/07, David Bernard [EMAIL PROTECTED] wrote: An other solution (stupid ?) : * at build-time (of the war) * scan all the jars and source to find js and css * extract/minified/compress into a cache directory * include the cache directory into the webapp * at runtime * when a resource is requested, it search into the cache directory before into the jar and select the better (original, minified, gzipped,...) A possible advantage, is for user of frontal like Apache, lighttpd,... to serve those static resources Johan Compagner wrote: yeah but a one time hit shouldn't be to much of a problem..cache the result The problem with wicket is that you don't know exactly where everything is coming from.. They could be in all kinds of jars so if you want compression it should be runtime else you need to go over all the jars and code you use and repackage them. On 9/4/07, David Bernard [EMAIL PROTECTED] wrote: Right to use it, you provide readers, writers, an ErrorReporter and options (line-break or not, munge or not, js warning or not,...). But as Julien (authors of YUI-Compressor) wrote : the compressor is resource consumming and not made to run on-fly. /David Johan Compagner wrote: thats a pretty nice one, it also compresses CSS. It does depend on rhino and another jar so its a total of 3 jars so it should be outside the wicket core or extentions (a project by itself?) also all the examples that i see are with the command line and input filenames i hope it has a interface where you can talk with it in java and with input streams/readers johan On 9/3/07, Eelco Hillenius [EMAIL PROTECTED] wrote: On 9/1/07, Matej Knopp [EMAIL PROTECTED] wrote: Well, I certainly didn't want to reinvent the wheel. But all existing solutions I was able to find either relied on a third part library (shrinksafe) or had license not compatible with ASL. So I just wrote a simple stripper. I think it still helps a lot, I didn't want to build a perfect stripper. YUI's license is compatible, so http://www.julienlecomte.net/blog/2007/08/13/introducing-the-yui-compressor/ might work, right? 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: compressing javascript resources
you where talking about Apache and serving it as static resources So then the urls should he rewritten because /resources/ is mapped to wicket johan On 9/4/07, David Bernard [EMAIL PROTECTED] wrote: I didn't suggest to change the url of resources, in the code we always I want .js. And the url to request the resource is the same. I suggest to select the stream to return : * select form cache, cache dir, jar,... * select version (to allow management of version = -major.minor.bugfix.js) if several version are available * select format : normal, minified, gzipped, minified+gzipped * ... The rules that manage the selection of the stream are configured at the Application/ResoursesSettings level. /david Johan Compagner wrote: i don't think that will work very easily because the component will make ResourceReferences to its internal css and js files and will be outputted as shared resources. Then all those urls should also be redirected. johan On 9/4/07, David Bernard [EMAIL PROTECTED] wrote: An other solution (stupid ?) : * at build-time (of the war) * scan all the jars and source to find js and css * extract/minified/compress into a cache directory * include the cache directory into the webapp * at runtime * when a resource is requested, it search into the cache directory before into the jar and select the better (original, minified, gzipped,...) A possible advantage, is for user of frontal like Apache, lighttpd,... to serve those static resources Johan Compagner wrote: yeah but a one time hit shouldn't be to much of a problem..cache the result The problem with wicket is that you don't know exactly where everything is coming from.. They could be in all kinds of jars so if you want compression it should be runtime else you need to go over all the jars and code you use and repackage them. On 9/4/07, David Bernard [EMAIL PROTECTED] wrote: Right to use it, you provide readers, writers, an ErrorReporter and options (line-break or not, munge or not, js warning or not,...). But as Julien (authors of YUI-Compressor) wrote : the compressor is resource consumming and not made to run on-fly. /David Johan Compagner wrote: thats a pretty nice one, it also compresses CSS. It does depend on rhino and another jar so its a total of 3 jars so it should be outside the wicket core or extentions (a project by itself?) also all the examples that i see are with the command line and input filenames i hope it has a interface where you can talk with it in java and with input streams/readers johan On 9/3/07, Eelco Hillenius [EMAIL PROTECTED] wrote: On 9/1/07, Matej Knopp [EMAIL PROTECTED] wrote: Well, I certainly didn't want to reinvent the wheel. But all existing solutions I was able to find either relied on a third part library (shrinksafe) or had license not compatible with ASL. So I just wrote a simple stripper. I think it still helps a lot, I didn't want to build a perfect stripper. YUI's license is compatible, so http://www.julienlecomte.net/blog/2007/08/13/introducing-the-yui-compressor/ might work, right? 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] - 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: java.lang.VerfiyError with @SpringBean
Mr igor has this to say: tbh it looks like a problem in cglib bytecode generation. i think i have seen this once when i was writing salve, but i dont remember exactly what caused it :| if nothing he tries works you can always tell him to extract an interface out of commentservice and use that - that way he can bypass cglib i believe. or he can use salve, works great with wicket :) johan On 9/4/07, Sebastiaan van Erk [EMAIL PROTECTED] wrote: Hi, I'm using the entire Wicket/Spring/Hibernate stack to build an application, and I'm using AspectJ to do AOP stuff for me at load time (LTW). I deploy on Tomcat 5.5 with the -javaagent:aspectjweaver.jaroption. However, the combination with this and the wicket-spring-annot (@SpringBean) seems to cause the VerifyError below. When I take away the -javaagent option (so that the class is not woven), everything works fine. Does anybody have any clue what could cause this and how I can fix it? Regards, Sebastiaan java.lang.VerifyError: (class: com/denherdervarga/service/CommentService$$EnhancerByCGLIB$$e767d40d, method: getObjectLocator signature: ()Lorg/apache/wicket/proxy/IProxyTargetLocator;) Inconsistent stack height 1 != 0 java.lang.Class.getDeclaredMethods0(Native Method) java.lang.Class.privateGetDeclaredMethods(Class.java:2427) java.lang.Class.getDeclaredMethod(Class.java:1935) net.sf.cglib.proxy.Enhancer.getCallbacksSetter(Enhancer.java:627) net.sf.cglib.proxy.Enhancer.setCallbacksHelper(Enhancer.java:615) net.sf.cglib.proxy.Enhancer.setThreadCallbacks(Enhancer.java:609) net.sf.cglib.proxy.Enhancer.createUsingReflection(Enhancer.java :631) net.sf.cglib.proxy.Enhancer.firstInstance(Enhancer.java:538) net.sf.cglib.core.AbstractClassGenerator.create( AbstractClassGenerator.java:225) net.sf.cglib.proxy.Enhancer.createHelper(Enhancer.java:377) net.sf.cglib.proxy.Enhancer.create(Enhancer.java:285) org.apache.wicket.proxy.LazyInitProxyFactory.createProxy( LazyInitProxyFactory.java:160) org.apache.wicket.spring.injection.annot.AnnotProxyFieldValueFactory.getFieldValue (AnnotProxyFieldValueFactory.java:98) org.apache.wicket.injection.Injector.inject(Injector.java:108) org.apache.wicket.injection.ConfigurableInjector.inject( ConfigurableInjector.java:40) org.apache.wicket.injection.ComponentInjector.onInstantiation( ComponentInjector.java:53) org.apache.wicket.Application.notifyComponentInstantiationListeners( Application.java:998) org.apache.wicket.Component.init(Component.java:728) org.apache.wicket.MarkupContainer.init(MarkupContainer.java:111) org.apache.wicket.Page.init(Page.java:243) org.apache.wicket.markup.html.WebPage.init(WebPage.java:183) com.denherdervarga.web.pages.BasePage.init(BasePage.java:14) com.denherdervarga.web.pages.GuestBook.init(GuestBook.java:21) sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) sun.reflect.NativeConstructorAccessorImpl.newInstance( NativeConstructorAccessorImpl.java:39) sun.reflect.DelegatingConstructorAccessorImpl.newInstance( DelegatingConstructorAccessorImpl.java:27) java.lang.reflect.Constructor.newInstance(Constructor.java:513) java.lang.Class.newInstance0(Class.java:355) java.lang.Class.newInstance(Class.java:308) org.apache.wicket.session.DefaultPageFactory.newPage( DefaultPageFactory.java:58) org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.newPage (BookmarkablePageRequestTarget.java:256) org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.getPage (BookmarkablePageRequestTarget.java:277) org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.processEvents (BookmarkablePageRequestTarget.java:205) org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents( AbstractRequestCycleProcessor.java:90) org.apache.wicket.RequestCycle.processEventsAndRespond( RequestCycle.java:1032) org.apache.wicket.RequestCycle.step(RequestCycle.java:1108) org.apache.wicket.RequestCycle.steps(RequestCycle.java:1177) org.apache.wicket.RequestCycle.request(RequestCycle.java:500) org.apache.wicket.protocol.http.WicketFilter.doGet( WicketFilter.java:261) org.apache.wicket.protocol.http.WicketFilter.doFilter( WicketFilter.java:127)
Re: Thank you note
+1! On 9/4/07, Martijn Dashorst [EMAIL PROTECTED] wrote: Why thank you! (made me blush) On 9/4/07, Cristi Manole [EMAIL PROTECTED] wrote: I guess it's not that appropriate to write a thank you note on this address, but i just couldn't help myself. What you guys did with this framework is trully amaizing. I've been ... playing with it in the couple of weeks and it fits just like a glove. Not to mention the support the users get from you guys, which is something I for one had not encountered befored. I really hope you'll keep it up. REALLY! I have experience in some (well known ... bleah) frameworks so I can say with 100% certainty (only) THIS is web development. -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0-beta3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Change of Button interface
please attach your patch to the jira. On 9/5/07, David Leangen [EMAIL PROTECTED] wrote: Ok, you're right, when I cast defaultButton to Component, the code compiles. Personally, I don't feel comfortable with this kind of cast, but I've never been involved with creating the Wicket internals, so I'll go with whatever you decide. Should I send in the patch? Cheers, Dave On Tue, 2007-09-04 at 09:09 +0200, Johan Compagner wrote: we can look to add those to the interface but maybe it is better to cast to a Component (that has those methods) they should be components anyway.. (but we don't have an IComponent ;)) On 9/4/07, David Leangen [EMAIL PROTECTED] wrote: Jira issue filed: https://issues.apache.org/jira/browse/WICKET-922 Well, I'm just looking at the Form class. I can't say for sure if there are any other problem areas or not, at this point I'm just mentioning what's causing a compile error for me. If we change Button to IFormSubmittingComponent, then in onComponentTagBody, there is a problem with the following: defaultButton.isVisibleInHierarchy() defaultButton.isEnabled() Since defaultButton is no longer a button, but isVisibleInHierarchy() and isEnabled() are not defined in IFormSubmittingComponent, this won't compile. Also in appendDefaultButtonField, we have: defaultButton.getMarkupId() Same problem. If those get sorted out in the Form class, then maybe we can think about looking at using the interface elsewhere. From a low-level perspective, just to get this to compile, I would say we need to add those methods to IFormSubmittingComponent. But, from a design point of view, I'm not so sure. Cheers, Dave On Mon, 2007-09-03 at 15:37 +0200, Johan Compagner wrote: The intent was that not all kind of components could be a button because of the single inheritance that java gives us But like Matej said, everywhere we do an instance check of button we should change that to do it on IFormSubmittingComponent johan On 9/3/07, David Leangen [EMAIL PROTECTED] wrote: Been trying to update to 1.3 and encountered some problems with SubmitLink. Before, SubmitLink extended Button, so there were no problems with forms. SubmitLinks could be used interchangeably with Buttons, and life was good. Now, SubmitLink implements IFormSubmittingComponent, so it's breaking some code. Implementing the interface seems reasonable to me, but the code hasn't kept up with this change of mentality and there are some inconsistencies. In the wicket code, I tried changing Form.setDefaultButton(Button button) to Form.setDefaultButton(IFormSubmittingComponent button) But this doesn't work, since some methods like onComponentTagBody are programmed to the Button implementation rather than the IFormSubmittingComponent interface. It seems like a few things still need to be sorted out, or maybe the SubmitLink should go back to extending button. What's the story with this? What's the intent with the ISubmittingComponent interface vs. Button vs. SubmitLink? I don't mind trying out some stuff, but please tell me the direction that you're going with this. Thanks! David - 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: JavaScript Frameworks
stupid thing is that all those slides and fades and fancy ui things are not really ajax.. thats just JavaScript/DHTML johan On 9/5/07, bmarvell [EMAIL PROTECTED] wrote: Sorry if this has been asked several times but it I didn't easily find it from a search. Fair enough about the actual Ajax functionality if specific code is required fair enough. I was using the term Ajax in a very business sense ie: full stack functionality; slides, fades etc. So for those specific issues are we to say: http://martijndashorst.com/blog/2007/04/16/javascript-animation-libraries-compared/ Is the future?? Matej Knopp-2 wrote: Hi, this question has been asked here numerous times. The thing is, there is in fact no real alternative of wicket-ajax for us. Wicket is not built about Ajax widgets.Wicket is about server-side components that can be partially updated using Ajax. That's a fundamental difference. As for the features, wicket-ajax has numerous advanced features such as - asynchronous pipeline that allows loading dependencies in asynchronous way, yet respecting the order (unlike e.g. dojo where the depending javascript are loaded using synchronous http requests which block entire browser = usability disaster) - ajax channels that allow you to stack or drop pending requests - multipart ajax response for replacing multiple components in one response, ajax header contribution processing (so that component can render header response as it would normally do, wicket transparently processes it and loads all dependencies (javascript references, stylesheets, etc) in an asynchronous way while respecting the order) - wicket-ajax.js is about 7kb compressed (with stripped down comments). As this is a general purpose ajax framework, the size matters. For sites where you using ajax only on certain places, having a 200kb javascript dependency would be quite a burden - there's more to it, the code is quite well documented, if you are interested you can dig into it, also you should search achives, this has been discussed here already. -Matej On 9/5/07, bmarvell [EMAIL PROTECTED] wrote: Hello all, This is my first post so please be gentle ;) I'm a user interface developer (no Java) working on what will inevitably be a fairly heavy Ajax wicket project. After looking at a number of Ajax examples and pre built widgets I have to say I'm a little puzzled! Why does wickets core JS framework not use one of the main JS frameworks that are available such as jQuery, Dojo or Prototype? I believe you have a hand rolled version of mootools (although I may be wrong). Do the Wicket core team plan on supporting and enriching this hand rolled framework alone? Surely it would make more sense to choose one of the main JS frameworks that have dedicated teams of devs supporting it? Also I've found that Ajax widgets in wicket seem quite here and there in their implementation. Some demos use prototype, some use YUI (a datepicker for example). Doesnt this go against what JS frameworks are trying to provide? Choosing a decent framework such as jQuery or Prototype will give the developer a solid toolkit on which they can build, so extra components such as datepickers or custom widgets can be applied as Plugins. Sticking to one framework reduces hits to the server, bandwidth, load and processing times all of which imho are good things. My worry at the moment is that the demos in wicket are very lets get it working on the frontend and not lets think about a framework and its rich functionality. SO to summarize :) are there any thoughts about using a single, supported framework in wicket and moving forward from there? Cheers, Ben -- View this message in context: http://www.nabble.com/JavaScript-Frameworks-tf4383060.html#a12494810 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/JavaScript-Frameworks-tf4383060.html#a12495715 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JavaScript Frameworks
ahh so you want to do real programming in the javascript? So attaching purely in client side javascript events and those events call the server? Thats not how wicket works, in wicket you normally don't program javascript you get it pushed and the events get attached by the serverside. johan On 9/5/07, bmarvell [EMAIL PROTECTED] wrote: Sorry, Again mine is coming from a very front end perspective ie writing JS in a progressive enhancement style. Your pseudo code looks like the other end of the spectrum ie java code My main point over this thread was to also appreciate that while wicket is designed for java devs it needs to have JS framework code that can be used by UI developers. Hence why I believe having the ability to write things in a front end way is a GOOD thing. Nino Saturnino Martinez Vazquez Wael wrote: hmm I'll have to take a deeper look into this. The main idea about the input events are that you should be able to just add events of any sort (mouse, key, time?) to anycomponent that will either trigger that component or another, this means triggering from client to server. No real work has been done on the input events project other that the project are setup on the stuff svn, also some base infrastructure has been done. pseudo code example: form myform; label.add(new Event(Events.keypressed(a),Event.keydown, myform)); above should trigger myform when a are pressed and label has focus. disclaimer : this might be bad example:) regards Nino bmarvell wrote: I personally think a CSS DOM traversal/manipulation model that can tie to events elegantly is what's needed. i.e: http://jquery.com http://bennolan.com/behaviour/ Being able to say: $(#somthing li).click(. Is so much easier to code and read than: document.getElementById (something).getElementsByTagName(li).. Nino Saturnino Martinez Vazquez Wael wrote: on the Events part I might aswell go on with the input events contrib... As this now has been up a lot of times one the mailing list.. I might seem to find some time to do it.. But it would be really nice to see what people would like of features from it? regards Nino bmarvell wrote: Right then so for completeness: * Ajax Calls [In house] * Animation [animator.js] * Dom manipulation and traversal (CSS style for this is becoming highly favourable) [??] * Events [??] Has any of this been addressed or considered yet? I'm just coming in from the point of a front end developer and trying to identify whats either missing or I cant find :confused: Gerolf Seitz wrote: So for those specific issues are we to say: http://martijndashorst.com/blog/2007/04/16/javascript-animation-libraries-compared/ Is the future?? in this case, take a look at http://wicketstuff.org/confluence/display/STUFFWIKI/wicketstuff-animator ;) gerolf Matej Knopp-2 wrote: Hi, this question has been asked here numerous times. The thing is, there is in fact no real alternative of wicket-ajax for us. Wicket is not built about Ajax widgets.Wicket is about server-side components that can be partially updated using Ajax. That's a fundamental difference. As for the features, wicket-ajax has numerous advanced features such as - asynchronous pipeline that allows loading dependencies in asynchronous way, yet respecting the order (unlike e.g. dojo where the depending javascript are loaded using synchronous http requests which block entire browser = usability disaster) - ajax channels that allow you to stack or drop pending requests - multipart ajax response for replacing multiple components in one response, ajax header contribution processing (so that component can render header response as it would normally do, wicket transparently processes it and loads all dependencies (javascript references, stylesheets, etc) in an asynchronous way while respecting the order) - wicket-ajax.js is about 7kb compressed (with stripped down comments). As this is a general purpose ajax framework, the size matters. For sites where you using ajax only on certain places, having a 200kb javascript dependency would be quite a burden - there's more to it, the code is quite well documented, if you are interested you can dig into it, also you should search achives, this has been discussed here already. -Matej On 9/5/07, bmarvell [EMAIL PROTECTED] wrote: Hello all, This is my first post so please be gentle ;) I'm a user interface developer (no Java) working on what will inevitably be a fairly heavy Ajax wicket project. After looking at a number of Ajax examples and pre built widgets I have to say I'm a little puzzled! Why does wickets core JS framework not use one of the main JS frameworks that are available such as jQuery,
Re: write translated messages in renderhead
String js += var myMsg = ' + JavascriptUtils.escapeQuotes(new
ResourceModel(MY_MSG, null) + ) + ';;
that looks a bit wrong, try something like this
String js += var myMsg = ' + JavascriptUtils.escapeQuotes(new
ResourceModel(MY_MSG, null).getObject() + ) + ';;
On 9/5/07, Marieke Vandamme [EMAIL PROTECTED] wrote:
Hello,
With new 1.3beta3 release I changed all the entries from
StringResourceModel
to ResourceModel to avoid the warning 'Tried to retrieve a localized
string
for a component that has not yet been added to the page.' (I still get
this
warning when using wicket:message key=/ tag.. but I guess that's a
bug.)
But now my real problem :
I'm using the renderHead from IHeaderContributor to print some translated
text in javascript.
public void renderHead(IHeaderResponse hr) {
String js += var myMsg = ' + JavascriptUtils.escapeQuotes(new
ResourceModel(MY_MSG, null) + ) + ';;
hr.renderJavascript(js, null);
}
But now the result on my html-page is :
var myMsg = 'Model:classname=[org.apache.wicket.model.ResourceModel]';
instead I want my translated MY_MSG.
Thanks for your help !
--
View this message in context:
http://www.nabble.com/write-translated-messages-in-renderhead-tf4383719.html#a12496870
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tracking down an elusive error during migration to 1.3
thats odd ValueMap is just a hashmap so why it wants to get a username is strange testing.. johan On 9/5/07, Matej Knopp [EMAIL PROTECTED] wrote: Looks like a bug in property resolver that it doesn't handle maps properly. Johaaan? -Matej On 9/5/07, David Leangen [EMAIL PROTECTED] wrote: Thanks. I managed to find the class of the source of the problem, and it seems to be internal to Wicket. org.apache.wicket.authentication.panel.SignInPanel The form in this class (in wicket-auth-roles) uses this: /** El-cheapo model for form. */ private final ValueMap properties = new ValueMap(); And declares the property like this: add(username = new TextField(username, new PropertyModel(properties, username))); I'm guessing that the Exception is due to either some kind of change in ValueMap, or a change in the property resolver... On Tue, 2007-09-04 at 21:28 -0700, Igor Vaynberg wrote: looks like a propertymodel misbehaving somewhere. set a breakpoint on that exception. when it is thrown you can walk up the stack and see what model/component is causing this. -igor On 9/4/07, David Leangen [EMAIL PROTECTED] wrote: Migrating from 1.2 to 1.3. I've been trying to track down the cause of the following error. Since this is using reflection, I'm not getting any useful line numbers or direct information on the cause. If anybody can shed some light on this for me, I'd really appreciate it! All I know is that it happens at render time when visiting one of the components, but it's difficult to find the exact component. java.lang.NoSuchMethodException: org.apache.wicket.util.value.ValueMap.isUsername() at java.lang.Class.getMethod(Class.java:1581) at org.apache.wicket.util.lang.PropertyResolver.findGetter (PropertyResolver.java:501) at org.apache.wicket.util.lang.PropertyResolver.getGetAndSetter( PropertyResolver.java:317) ... - 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: Tracking down an elusive error during migration to 1.3
is also something really going wrong??
because 501 is this:
try
{
method = clz.getMethod(is + name, null);
}
catch (Exception e)
{
log.debug(Cannot find getter + clz + . + expression,
e);
}
we try to TEST if we can find it, and then do a debug log if we still can't
find it
after that we will see that it is a map and fallback on that.
johan
On 9/5/07, David Leangen [EMAIL PROTECTED] wrote:
Migrating from 1.2 to 1.3.
I've been trying to track down the cause of the following error.
Since this is using reflection, I'm not getting any useful line numbers
or direct information on the cause.
If anybody can shed some light on this for me, I'd really appreciate it!
All I know is that it happens at render time when visiting one of the
components, but it's difficult to find the exact component.
java.lang.NoSuchMethodException:
org.apache.wicket.util.value.ValueMap.isUsername()
at java.lang.Class.getMethod(Class.java:1581)
at
org.apache.wicket.util.lang.PropertyResolver.findGetter(
PropertyResolver.java:501)
at
org.apache.wicket.util.lang.PropertyResolver.getGetAndSetter(
PropertyResolver.java:317)
...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to set wicket's locale?
can you make an jira issue for this? On 9/4/07, Gabor Szokoli [EMAIL PROTECTED] wrote: Uh, oh, one more quick thing: I'm still on wicket 1.2, and my wicket:message labels retain their text in the locale they were first rendered in. Is there anything I can do on locale changes to make them change their text? Is this behavior the same under 1.3? Gabor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tracking down an elusive error during migration to 1.3
not the case that David has..
If i write a test case for the ValueMap and i get and put username in it
everything works.
Ofcourse if i set the debug logging level then i get a debug warning because
we do log there when
we couldn't find a get or a is property method..
johan
On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
you wrote it! :)
-igor
On 9/5/07, Johan Compagner [EMAIL PROTECTED] wrote:
is also something really going wrong??
because 501 is this:
try
{
method = clz.getMethod(is + name, null);
}
catch (Exception e)
{
log.debug(Cannot find getter + clz + . +
expression,
e);
}
we try to TEST if we can find it, and then do a debug log if we still
can't
find it
after that we will see that it is a map and fallback on that.
johan
On 9/5/07, David Leangen [EMAIL PROTECTED] wrote:
Migrating from 1.2 to 1.3.
I've been trying to track down the cause of the following error.
Since this is using reflection, I'm not getting any useful line
numbers
or direct information on the cause.
If anybody can shed some light on this for me, I'd really appreciate
it!
All I know is that it happens at render time when visiting one of the
components, but it's difficult to find the exact component.
java.lang.NoSuchMethodException:
org.apache.wicket.util.value.ValueMap.isUsername()
at java.lang.Class.getMethod(Class.java:1581)
at
org.apache.wicket.util.lang.PropertyResolver.findGetter(
PropertyResolver.java:501)
at
org.apache.wicket.util.lang.PropertyResolver.getGetAndSetter(
PropertyResolver.java:317)
...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?
I take the discussion is about removing onPopulate now?
why not keep onPopulate and remove the final?
On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
the reason for it being final is that the super.onbeforerender() call HAS
to
be done last, otherwise new items do not get onbeforerender called on
them.
so if we remove final will you remember to always call it last? i think
the
chances are that are pretty small, thus its final.
-igor
On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote:
I've grabbed the latest SNAPSHOT from the repository and have noticed
that
AbstractRepeater#onBeforeRender is final. I wonder what is the reason
for
this? (I need to do something in it's subclass)
/**
* @see org.apache.wicket.Component#onBeforeRender()
*/
protected final void onBeforeRender()
{
if (isVisibleInHierarchy())
{
onPopulate();
}
super.onBeforeRender();
}
Alex
--
View this message in context:
http://www.nabble.com/Why-the-AbstractRepeater-onBeforeRender-is-final-wicket-1.3.0-SNAPSHOT-%286-sept-2007%29--tf4391492.html#a12520558
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: DIV TAG HEADER DO NOT WORK IN WICKET
TSEE IS THAT AS LOUD AS YOU CAN GET? On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote: WHAT IS WRONG WITH IT? -IGOR On 9/6/07, bhupat parmar [EMAIL PROTECTED] wrote: THE HEADER IS NOT WORKING DIV id=header UL LIA href=# wicket:id=homeLinkHome/A/LI LI id=current wicket:id=trendArchiveA href=#Trend Archive/A/LI LIA href=# wicket:id=latestLookLink The Latest Looks/A/LI LI class=advanced wicket:id=pepsiStyleLinkA href=#Pepsi Style/A /LI LIA href=# wicket:id=myClosetLinkMy Closet/A /LI LIA href=# wicket:id=submitStyleLinkSubmit Style /A/LI /UL /DIV/td
Re: And The Fastest Growing Web Framework Is...
http://www.indeed.com/jobtrends?q=java%2C+jsfl= java is all you need to know for wicket so jsf seems pretty low to me in that picture.. On 9/6/07, cowwoc [EMAIL PROTECTED] wrote: This might be of interest to the Wicket community: http://www.javalobby.org/java/forums/t101110.html -- View this message in context: http://www.nabble.com/And-The-Fastest-Growing-Web-Framework-Is...-tf4392768.html#a12524620 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: And The Fastest Growing Web Framework Is...
In Germany, the best sold car is the VW Golf. But does this mean I should buy one? No, there are a lot of better alternatives (in the meaning of quality and design, for example). really? i thought it was German Build Quality! The best there is! Are there even better? (don't mention now ofcourse other german brands ;) )
Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?
please tell me, tell me!
johan
On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
because the final is there for a very important reason?
-igor
On 9/6/07, Johan Compagner [EMAIL PROTECTED] wrote:
I take the discussion is about removing onPopulate now?
why not keep onPopulate and remove the final?
On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
the reason for it being final is that the super.onbeforerender() call
HAS
to
be done last, otherwise new items do not get onbeforerender called on
them.
so if we remove final will you remember to always call it last? i
think
the
chances are that are pretty small, thus its final.
-igor
On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote:
I've grabbed the latest SNAPSHOT from the repository and have
noticed
that
AbstractRepeater#onBeforeRender is final. I wonder what is the
reason
for
this? (I need to do something in it's subclass)
/**
* @see org.apache.wicket.Component#onBeforeRender()
*/
protected final void onBeforeRender()
{
if (isVisibleInHierarchy())
{
onPopulate();
}
super.onBeforeRender();
}
Alex
--
View this message in context:
http://www.nabble.com/Why-the-AbstractRepeater-onBeforeRender-is-final-wicket-1.3.0-SNAPSHOT-%286-sept-2007%29--tf4391492.html#a12520558
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to set wicket's locale?
can you send some over? On 9/6/07, Evan Chooly [EMAIL PROTECTED] wrote: T-37 minutes until sushi time! On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote: sushi -igor On 9/6/07, Martijn Dashorst [EMAIL PROTECTED] wrote: new PropertyModel(Page.this, session.foo.sushi.bar); ? On 9/6/07, Gabor Szokoli [EMAIL PROTECTED] wrote: On 9/5/07, Johan Compagner [EMAIL PROTECTED] wrote: can you make an jira issue for this? https://issues.apache.org/jira/browse/WICKET-936 Any ideas on encapsulating the session as a propertymodel for components in 1.2? Gabor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0-beta3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?
and?
why can't AbstractRepeater.onBeforeRender() be not final?
If i overwrite to do what ever i want (but i do need to call onBeforeRender
at some point else we generate an error)
then it comes in AbstractRepeater.onBeforeRender()
that first does the onPopulate so the items are created and then calls the
super..
That i can never change even if onBeforeRender is not final..
johan
On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
since component.onbeforerender() is what cascades the onbeforerender()
call
to the children, when it comes to repeaters it is absolutely vital that
super.onbeforerender() be called last, that way it will cascade to any new
items added in repeater's onbeforerender().
-igor
On 9/6/07, Johan Compagner [EMAIL PROTECTED] wrote:
please tell me, tell me!
johan
On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
because the final is there for a very important reason?
-igor
On 9/6/07, Johan Compagner [EMAIL PROTECTED] wrote:
I take the discussion is about removing onPopulate now?
why not keep onPopulate and remove the final?
On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
the reason for it being final is that the super.onbeforerender()
call
HAS
to
be done last, otherwise new items do not get onbeforerender called
on
them.
so if we remove final will you remember to always call it last? i
think
the
chances are that are pretty small, thus its final.
-igor
On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote:
I've grabbed the latest SNAPSHOT from the repository and have
noticed
that
AbstractRepeater#onBeforeRender is final. I wonder what is the
reason
for
this? (I need to do something in it's subclass)
/**
* @see org.apache.wicket.Component#onBeforeRender()
*/
protected final void onBeforeRender()
{
if (isVisibleInHierarchy())
{
onPopulate();
}
super.onBeforeRender();
}
Alex
--
View this message in context:
http://www.nabble.com/Why-the-AbstractRepeater-onBeforeRender-is-final-wicket-1.3.0-SNAPSHOT-%286-sept-2007%29--tf4391492.html#a12520558
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: @SpringBean and serialization checker
the custom serialization is already off by default for quite some time the org.apache.wicket.util.io.SerializableChecker$WicketNotSerializableException: only kicks in (so also for the default) when an IOException happens with writeObject So that you get a nice trace which field it exactly is of what object. johan On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote: i dont think our custom serialization works right with proxies yet is the thing -igor On 9/6/07, leok [EMAIL PROTECTED] wrote: It's a little hard for me to tear out all the @SpringBean declarations in my webapp. I could try using the standard serialization method you speak of and monitor the behavior. It seemed a little strange that this Exception would pop up with such a basic config so I figured that I was missing something. igor.vaynberg wrote: so if you remove @SpringBean dao the errors go away? it def shouldnt be happening, maybe its a problem in wicket's custom serialization. there is a way to make wicket use standard serialization...cant remember off the top of my head right now... -igor On 9/6/07, leok [EMAIL PROTECTED] wrote: Hi, I'm using the @SpringBean + SpringComponentInjector to inject daos in my Wicket web pages. With Wicket 1.3b3, I'm noticing the following exception in my Tomcat (v6.0.13) logs: org.apache.wicket.util.io.SerializableChecker$WicketNotSerializableException: Unable to serialize class: org.apache.commons.dbcp.BasicDataSource This exception occurs randomly and emerges from different page objects while browsing my webapp (probably SecondLevelSessionCache behavior?) and, if session persistence is enabled, at app shutdown. Nowhere in my application am I using the BasicDataSource class explicitly except in my beans.xml datasource configuration. My understanding was that a LazyInitProxyFactory would be serialized in place of the dao if the @SpringBean annotation were used. The page in which this occurred has a single @SpringBean private MyDao myDao; member field in it. I have no daos -- injected or otherwise -- in my WebSession instances. Is there some other configuration issue I'm missing? Or is this expected behavior? I'm relatively new to Spring and Wicket so the former is likely possible. Thanks! leo -- View this message in context: http://www.nabble.com/%40SpringBean-and-serialization-checker-tf4392171.html#a12522589 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/%40SpringBean-and-serialization-checker-tf4392171.html#a12524903 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?
no not for the onces that make a Repeater.
Because then we aren't being able to tell that the populate should really be
done before the call to super.onBeforeRender
So having an onPopulate is fine. Repeaters should use that method to
populate them selfs and we then also take care of the order
but if somebody extends again that repeater he should be able to overwrite
onBeforeRender()
i think classes that implement the onPopulate should make that method
final... Because that shouldn't be overridable (we don't have the check
there that super is called)
So just removing final of onBeforeRender (for developers who extend the real
repeater again)
and having an onPopulate for concreet classes that extend AbstractRepeater
directly. (and those should make onPopulate final)
johan
On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
if it was not final then there would be little point for keeping
onpopulate,
it would just be confusing
-igor
On 9/6/07, Johan Compagner [EMAIL PROTECTED] wrote:
and?
why can't AbstractRepeater.onBeforeRender() be not final?
If i overwrite to do what ever i want (but i do need to call
onBeforeRender
at some point else we generate an error)
then it comes in AbstractRepeater.onBeforeRender()
that first does the onPopulate so the items are created and then calls
the
super..
That i can never change even if onBeforeRender is not final..
johan
On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
since component.onbeforerender() is what cascades the onbeforerender()
call
to the children, when it comes to repeaters it is absolutely vital
that
super.onbeforerender() be called last, that way it will cascade to any
new
items added in repeater's onbeforerender().
-igor
On 9/6/07, Johan Compagner [EMAIL PROTECTED] wrote:
please tell me, tell me!
johan
On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
because the final is there for a very important reason?
-igor
On 9/6/07, Johan Compagner [EMAIL PROTECTED] wrote:
I take the discussion is about removing onPopulate now?
why not keep onPopulate and remove the final?
On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
the reason for it being final is that the super.onbeforerender
()
call
HAS
to
be done last, otherwise new items do not get onbeforerender
called
on
them.
so if we remove final will you remember to always call it
last?
i
think
the
chances are that are pretty small, thus its final.
-igor
On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote:
I've grabbed the latest SNAPSHOT from the repository and
have
noticed
that
AbstractRepeater#onBeforeRender is final. I wonder what is
the
reason
for
this? (I need to do something in it's subclass)
/**
* @see org.apache.wicket.Component#onBeforeRender()
*/
protected final void onBeforeRender()
{
if (isVisibleInHierarchy())
{
onPopulate();
}
super.onBeforeRender();
}
Alex
--
View this message in context:
http://www.nabble.com/Why-the-AbstractRepeater-onBeforeRender-is-final-wicket-1.3.0-SNAPSHOT-%286-sept-2007%29--tf4391492.html#a12520558
Sent from the Wicket - User mailing list archive at
Nabble.com
.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?
thats why i said the concreet repeaters that implement onPopulate should make them final also what do you mean with funny errors, you only get funny errors when you override both or 1 and start calling the other. calling super on different times in your onBeforeRender doesn't create anything funny except one thing. Before the onBeforeRender you have the old items after it the new onces. johan On 9/6/07, Jan Kriesten [EMAIL PROTECTED] wrote: i think onPopulate() is there for just about 2 or 3 weeks and before the docs stated that calling super() would be vital. so, i really don't see a benefit in having a onpopulate() _and_ a non-final onbeforerender(). actually, if i override both, i could get funny errors changing a call to super.onbeforerender() at the end of an overridden onbeforerender() to the beginning - since code in onpopulate() would be called on different initialization stages. having no onpopulate() would move the responsability back into the onbeforerender() again. i would prefer to get lost of onpopulate() in favor of onbeforerender(). my 2c regards, --- jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?
ok, i don't like to have onBeforeRender final because we have the whole i called the super check for that. But i do like the onPopulate because that makes much more clear that the repeaters do there there work because why should that happen in onBeforeRender? The api does speak for them self then So i will remove the final of the onBeforeRender() but make all onPopulate implementations final because that just for the implementors The only exception being RepeatingView because thats just an empty implementation thats is supposed to be overwritten again.. by the way, these discussion do drain you, but your are happily contributing to threads like Wicket Libraries :) On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote: i will leave it up to you guys as to what you want to do and how. honestly discussions like this drain my attention span. the only reason i introduced onpopulate is so that i could make onbeforerender final. -igor On 9/6/07, Johan Compagner [EMAIL PROTECTED] wrote: thats why i said the concreet repeaters that implement onPopulate should make them final also what do you mean with funny errors, you only get funny errors when you override both or 1 and start calling the other. calling super on different times in your onBeforeRender doesn't create anything funny except one thing. Before the onBeforeRender you have the old items after it the new onces. johan On 9/6/07, Jan Kriesten [EMAIL PROTECTED] wrote: i think onPopulate() is there for just about 2 or 3 weeks and before the docs stated that calling super() would be vital. so, i really don't see a benefit in having a onpopulate() _and_ a non-final onbeforerender(). actually, if i override both, i could get funny errors changing a call to super.onbeforerender() at the end of an overridden onbeforerender() to the beginning - since code in onpopulate() would be called on different initialization stages. having no onpopulate() would move the responsability back into the onbeforerender() again. i would prefer to get lost of onpopulate() in favor of onbeforerender(). my 2c regards, --- jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?
who? that overrides onBeforeRender? why should those call super last? that depends on what they want. On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote: because we are going in circles here even with onpopulate you still have to make sure you call super last! -igor On 9/6/07, Johan Compagner [EMAIL PROTECTED] wrote: ok, i don't like to have onBeforeRender final because we have the whole i called the super check for that. But i do like the onPopulate because that makes much more clear that the repeaters do there there work because why should that happen in onBeforeRender? The api does speak for them self then So i will remove the final of the onBeforeRender() but make all onPopulate implementations final because that just for the implementors The only exception being RepeatingView because thats just an empty implementation thats is supposed to be overwritten again.. by the way, these discussion do drain you, but your are happily contributing to threads like Wicket Libraries :) On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote: i will leave it up to you guys as to what you want to do and how. honestly discussions like this drain my attention span. the only reason i introduced onpopulate is so that i could make onbeforerender final. -igor On 9/6/07, Johan Compagner [EMAIL PROTECTED] wrote: thats why i said the concreet repeaters that implement onPopulate should make them final also what do you mean with funny errors, you only get funny errors when you override both or 1 and start calling the other. calling super on different times in your onBeforeRender doesn't create anything funny except one thing. Before the onBeforeRender you have the old items after it the new onces. johan On 9/6/07, Jan Kriesten [EMAIL PROTECTED] wrote: i think onPopulate() is there for just about 2 or 3 weeks and before the docs stated that calling super() would be vital. so, i really don't see a benefit in having a onpopulate() _and_ a non-final onbeforerender(). actually, if i override both, i could get funny errors changing a call to super.onbeforerender() at the end of an overridden onbeforerender() to the beginning - since code in onpopulate() would be called on different initialization stages. having no onpopulate() would move the responsability back into the onbeforerender() again. i would prefer to get lost of onpopulate() in favor of onbeforerender(). my 2c regards, --- jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why the AbstractRepeater#onBeforeRender is final wicket-1.3.0-SNAPSHOT (6 sept 2007)?
sure no problem, just point them out :) On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote: well, whenever those emails comein...why doesnt onbeforerender is getting called...you can answer them :) -igor On 9/6/07, Johan Compagner [EMAIL PROTECTED] wrote: who? that overrides onBeforeRender? why should those call super last? that depends on what they want. On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote: because we are going in circles here even with onpopulate you still have to make sure you call super last! -igor On 9/6/07, Johan Compagner [EMAIL PROTECTED] wrote: ok, i don't like to have onBeforeRender final because we have the whole i called the super check for that. But i do like the onPopulate because that makes much more clear that the repeaters do there there work because why should that happen in onBeforeRender? The api does speak for them self then So i will remove the final of the onBeforeRender() but make all onPopulate implementations final because that just for the implementors The only exception being RepeatingView because thats just an empty implementation thats is supposed to be overwritten again.. by the way, these discussion do drain you, but your are happily contributing to threads like Wicket Libraries :) On 9/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote: i will leave it up to you guys as to what you want to do and how. honestly discussions like this drain my attention span. the only reason i introduced onpopulate is so that i could make onbeforerender final. -igor On 9/6/07, Johan Compagner [EMAIL PROTECTED] wrote: thats why i said the concreet repeaters that implement onPopulate should make them final also what do you mean with funny errors, you only get funny errors when you override both or 1 and start calling the other. calling super on different times in your onBeforeRender doesn't create anything funny except one thing. Before the onBeforeRender you have the old items after it the new onces. johan On 9/6/07, Jan Kriesten [EMAIL PROTECTED] wrote: i think onPopulate() is there for just about 2 or 3 weeks and before the docs stated that calling super() would be vital. so, i really don't see a benefit in having a onpopulate() _and_ a non-final onbeforerender(). actually, if i override both, i could get funny errors changing a call to super.onbeforerender() at the end of an overridden onbeforerender() to the beginning - since code in onpopulate() would be called on different initialization stages. having no onpopulate() would move the responsability back into the onbeforerender() again. i would prefer to get lost of onpopulate() in favor of onbeforerender(). my 2c regards, --- jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: {wicket 1.3 beta 3} Howto add keywords No cache etc?
2 tags generating the same milisecond for the same client/session?
that looks very very very odd to me.
johan
On 9/7/07, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED]
wrote:
Actually we discussed that.
I suggested it but as Matej wrote:
don't think so. you can have two tags generated in same millisecond.. As
for nano might be better, lesser chance for tags being generated in the
same nanosec. But whats wrong with autoindex?
Martijn Dashorst wrote:
Why not use System.currentTimeMillis()? Or if you are really concerned
use nanotime.
Martijn
On 9/7/07, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED]
wrote:
so no, talking to Matej on ##wicket, the fix was this:
Resolutions are these two :
protected void onComponentTag(ComponentTag tag) {
super.onComponentTag(tag);
tag.put(src, tag.getString(src) + rand= +
Math.random());
}
or event better since random could give duplicate results:
protected void onComponentTag(ComponentTag tag) {
super.onComponentTag(tag);
tag.put(src, tag.getString(src) + autoIndex= +
getPage().getAutoIndex());
}
Although im not sure if its safe to use autoIndex?I've put up a feature
request for it to be implemented.
https://issues.apache.org/jira/browse/WICKET-939
-Nino
Nino Saturnino Martinez Vazquez Wael wrote:
this is whats generated:
http://localhost:8080/thirdparty-webapp/thirdParty/?wicket:interface=:4:form:phoneA:phoneThumb:image::IResourceListener
::
regards Nino
Martijn Dashorst wrote:
The most failsafe solution to the update image using Ajax request to
my mind is to add a random number to the url for the image (I thought
we already did that?).
Martijn
On 9/7/07, Nino Saturnino Martinez Vazquez Wael
[EMAIL PROTECTED] wrote:
Hi
How do I add keywords no-cache and etc, for a panel? Reason are that
the
panel carries a image and that gets cached so when my ajax call
comes in
and updates the model then the old image are shown..
regards Nino
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Any interest in a Wicket User Group meeting in The Netherlands?
hi, I can organize one if there is enough interest Martijn and i will be there then. And for example if people are also interested in the wicket security i will also drag Maurice to the table. johan
Re: Any interest in a Wicket User Group meeting in The Netherlands?
depends on what is far :) Brussel - Amersfoort: http://maps.google.com/maps?f=dhl=engeocode=saddr=Amersfoort,+Netherlandsdaddr=Brussel,+Belgiumsll=52.512794,6.091538sspn=0.375674,1.082153ie=UTF8z=9om=1 less then 2 hours On 9/7/07, Francis De Brabandere [EMAIL PROTECTED] wrote: any chance you could do this a bit more near belgium? :-) On 9/7/07, C. Bergström [EMAIL PROTECTED] wrote: Johan Compagner wrote: hi, I can organize one if there is enough interest Martijn and i will be there then. And for example if people are also interested in the wicket security i will also drag Maurice to the table. I can attend while I'm in the Netherlands and will probably drag (willingly) another colleague of mine. Did anyone have any ideas where it would be? (We're near Haarlem and if needed *maybe* could host it as well.) +2 ./C - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.somatik.be Microsoft gives you windows, Linux gives you the whole house. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Disable the SecondLevelPageCache?
invocation count 1?? So you only do 1 request and you profile that? thats not a good test. You have to do plenty and multiply on the same time (10 for 100 request or something like that) to really see the difference. (and have a warm up phase) johan On 9/10/07, Alex Objelean [EMAIL PROTECTED] wrote: Matej, I must disagree with you regarding performance issues of the SecondLevelSessionStore. I've reverted the Application#newSessionStore to HttpSessionStore and this significantly improved the application overall performance. Maybe this is not so obvious for small applications, but when it is about a large one - things changes. Below, you will find attached two images. The first one is a profiling of an action when working with HttpSessionStore, the second one is a profiling for the same action when using SecondSessionLevelStore. The difference is huge: 593ms vs 174420ms. I cannot explain what exactly is going on, but I've noticed that by switching from default SecondLevelSessionStore to the HttpSessionStore improved a lot the responsiveness of the application. Alex. http://www.nabble.com/file/p12588790/HttpSessionStore.jpg http://www.nabble.com/file/p12588790/SecondSessionLevelStore.jpg Matej Knopp-2 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] -- View this message in context: http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12588790 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Disable the SecondLevelPageCache?
that looks very strange to me. We have also a very large app here and we dont notice a difference So i am very curious what is happening at your place then. Are you sure for example that the pages are serializable ? That we don't have constantly exceptions? johan On 9/10/07, Alex Objelean [EMAIL PROTECTED] wrote: Maybe the profiling was not a perfect one. But still, I have to give up using SecondSessionLevelStore just because the responsiveness of the application is very slow. Johan Compagner wrote: invocation count 1?? So you only do 1 request and you profile that? thats not a good test. You have to do plenty and multiply on the same time (10 for 100 request or something like that) to really see the difference. (and have a warm up phase) johan On 9/10/07, Alex Objelean [EMAIL PROTECTED] wrote: Matej, I must disagree with you regarding performance issues of the SecondLevelSessionStore. I've reverted the Application#newSessionStore to HttpSessionStore and this significantly improved the application overall performance. Maybe this is not so obvious for small applications, but when it is about a large one - things changes. Below, you will find attached two images. The first one is a profiling of an action when working with HttpSessionStore, the second one is a profiling for the same action when using SecondSessionLevelStore. The difference is huge: 593ms vs 174420ms. I cannot explain what exactly is going on, but I've noticed that by switching from default SecondLevelSessionStore to the HttpSessionStore improved a lot the responsiveness of the application. Alex. http://www.nabble.com/file/p12588790/HttpSessionStore.jpg http://www.nabble.com/file/p12588790/SecondSessionLevelStore.jpg Matej Knopp-2 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] -- View this message in context: http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12588790 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Disable-the-SecondLevelPageCache--tf4403977.html#a12589190 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to force a delete (from disk) of the session from the session store?
you should call invalidate() anyway instead of invalidateNow() there could maybe be usecases where you should call the invalidateNow() for example if you want to invalidate the current http session and make in the same request a new one (if that is possible??) But you should do invalidate() because that will clean up the session after the current request ends johan On 9/9/07, Chris Lintz [EMAIL PROTECTED] wrote: Interesting. I was using session.invalidateNow() which did not remove it from disk. But session.invalidate() worked like a charm. Should session.invalidateNow() also remove the session from disk immediately? thanks for your help Eelco Hillenius wrote: Chris Lintz wrote: Hi, When a user logouts of the site, i want to kill the session and have it be removed from disk immediately. I have extended WebSession properly, but no methods on the WebSession class seem to do the trick for me. Is there a way to to trigger the removal of the session cleanly from disk via the SessionStore or some other approach? I think this is done automatically when you call session.invalidate(). Yep, that should do the trick. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/How-to-force-a-delete-%28from-disk%29-of-the-session-from-the-session-store--tf4404925.html#a12580502 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Stuff Dojo Repository
yes please change this because else i can keep on deleting constantly stuff :( On 9/10/07, Maurice Marrink [EMAIL PROTECTED] wrote: @vincent Hmm, looks like you are generating unique id's for your snapshots. I don't think that is wise as the server will run out of disk space like that in no time. You should put uniqueVersionfalse/uniqueVersion inside the snapshotRepository tag. Maurice On 9/10/07, Vincent Demay [EMAIL PROTECTED] wrote: Hi, Wicketstuff dojo has just been modified in order to build its artifact on the same location as usually : http://www.wicketstuff.org/maven/repository/org/wicketstuff/wicketstuff-dojo Cheers -- Vincent Maurice Marrink wrote: Johan recently made some changes to the wicket-stuff repository (see dev mailing list). requiring all projects (automatically build via bamboo) to update there pom. So if they are not yet back on there old spot they probably did not make the change. You could try bugging them about that ;) As soon as they update there poms is should be right were it always was. Maurice On 9/8/07, Aaron Hiniker [EMAIL PROTECTED] wrote: Where did it move to? Aaron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Disable the SecondLevelPageCache?
you got to be kidding me...32MB really? Or is this a nice joke so in the middle of the day :) johan On 9/10/07, Alex Objelean [EMAIL PROTECTED] wrote: It is about 32MB. Kind a big page :) Matej Knopp-2 wrote: Turn on SecondLevelCacheSessionStore, and use FilePageStore as IPageStore (specified in session store constructor). Then go to your tmp dir and you should be able to find the serialized pages there. -Matej On 9/10/07, Alex Objelean [EMAIL PROTECTED] wrote: How can I figure it out? Johan Compagner wrote: if you save the page to disk how big is it? johan On 9/10/07, Alex Objelean [EMAIL PROTECTED] wrote: Indeed, it is a very big component hierarchy (It contains at least 3 levels of nested AjaxTabbedPanel components). The application is, in fact, a single page and it uses a lot of ajax to perform the updates. The model reflect the component hierarchy (Appliction has a single modelObject which nests another objects corresponding to each component). I do not have a lot of detaching logic, because it is important to have all the data in the model (caching), also because the services are very costly operations. If this description is not enough for replication, I will be glad to help by giving you another details. Alex. Martijn Dashorst wrote: How big is the page? Sounds like a really, really big component hierarchy. Then it sounds reasonable that the httpsession store is much faster: it keeps it in ram, and doesn't use serialization until the session is serialized (server shutting down, deciding to put session to disk or replication of session across cluster) iirc. I think we would appreciate some way of replicating your results. I assume you can't share the actual code, but could you share a spin-off of the page's component structure and a Model that replicates the data stuff's size (including the detach logic)? Martijn On 9/10/07, Alex Objelean [EMAIL PROTECTED] wrote: If the pages wouldn't be serializable, it wouldn't work in development mode. Is it right? I think that it is not necessarily about how large is application, in my case it is about how large is the model I'm working with for that specific request (ajax request). My action was: fetch a subview of a very large table 300x300, each cell has a heavy model object. Alex. Johan Compagner wrote: that looks very strange to me. We have also a very large app here and we dont notice a difference So i am very curious what is happening at your place then. Are you sure for example that the pages are serializable ? That we don't have constantly exceptions? johan On 9/10/07, Alex Objelean [EMAIL PROTECTED] wrote: Maybe the profiling was not a perfect one. But still, I have to give up using SecondSessionLevelStore just because the responsiveness of the application is very slow. Johan Compagner wrote: invocation count 1?? So you only do 1 request and you profile that? thats not a good test. You have to do plenty and multiply on the same time (10 for 100 request or something like that) to really see the difference. (and have a warm up phase) johan On 9/10/07, Alex Objelean [EMAIL PROTECTED] wrote: Matej, I must disagree with you regarding performance issues of the SecondLevelSessionStore. I've reverted the Application#newSessionStore to HttpSessionStore and this significantly improved the application overall performance. Maybe this is not so obvious for small applications, but when it is about a large one - things changes. Below, you will find attached two images. The first one is a profiling of an action when working with HttpSessionStore, the second one is a profiling for the same action when using SecondSessionLevelStore. The difference is huge: 593ms vs 174420ms. I cannot explain what exactly is going on, but I've noticed that by switching from default SecondLevelSessionStore to the HttpSessionStore improved a lot the responsiveness of the application. Alex. http://www.nabble.com/file/p12588790/HttpSessionStore.jpg http://www.nabble.com/file/p12588790/SecondSessionLevelStore.jpg Matej Knopp-2 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
Re: Disable the SecondLevelPageCache?
if you just have 1 page with no back button support/all ajax then httpsessionstore is fine johan On 9/10/07, Alex Objelean [EMAIL PROTECTED] wrote: It is a intranet application, so the number of users for this application is at most ~30-40 users/day. A back button support is not needed, because there is a single page and also it doesn't make sense (since it is all ajax). I'm still wondering, what is best in this case: * Using HttpSessionStore * Use 2nd level session store and make transient heavy object references. Alex. Martijn Dashorst wrote: The only caveat you'll have is whether or not the backbutton is supported long enough, and how many copies of that page you want to have in memory. If the non-2nd level cache way works for you, then there is absolutely nobody telling you to stop using it. The difference has mostly to do with providing backbutton support and optimizing memory usage. In your case it is probably best to limit the backbutton, as you claim to work a lot with ajax. So the back button functionality is probably already not working (users can press it, but they will leave your site, or go back to the login page). Profile the memory usage, multiply with the number of users you expect and ask if it still fits on the machine available for your budget. The second level cache will still keep the last rendered page in memory as I understand it, so that 32MB will still be claimed, whatever store you choose. Martijn On 9/10/07, Alex Objelean [EMAIL PROTECTED] wrote: :) Unfortunately it's not a joke, but I'm glad you're having fun :D. Actually, this is result of worst case scenario simulation (I told you that there are heavy objects in the model). After making transient some of the fields, the size of the page dropped dramatically. Alex. Johan Compagner wrote: you got to be kidding me...32MB really? Or is this a nice joke so in the middle of the day :) johan On 9/10/07, Alex Objelean [EMAIL PROTECTED] wrote: It is about 32MB. Kind a big page :) Matej Knopp-2 wrote: Turn on SecondLevelCacheSessionStore, and use FilePageStore as IPageStore (specified in session store constructor). Then go to your tmp dir and you should be able to find the serialized pages there. -Matej On 9/10/07, Alex Objelean [EMAIL PROTECTED] wrote: How can I figure it out? Johan Compagner wrote: if you save the page to disk how big is it? johan On 9/10/07, Alex Objelean [EMAIL PROTECTED] wrote: Indeed, it is a very big component hierarchy (It contains at least 3 levels of nested AjaxTabbedPanel components). The application is, in fact, a single page and it uses a lot of ajax to perform the updates. The model reflect the component hierarchy (Appliction has a single modelObject which nests another objects corresponding to each component). I do not have a lot of detaching logic, because it is important to have all the data in the model (caching), also because the services are very costly operations. If this description is not enough for replication, I will be glad to help by giving you another details. Alex. Martijn Dashorst wrote: How big is the page? Sounds like a really, really big component hierarchy. Then it sounds reasonable that the httpsession store is much faster: it keeps it in ram, and doesn't use serialization until the session is serialized (server shutting down, deciding to put session to disk or replication of session across cluster) iirc. I think we would appreciate some way of replicating your results. I assume you can't share the actual code, but could you share a spin-off of the page's component structure and a Model that replicates the data stuff's size (including the detach logic)? Martijn On 9/10/07, Alex Objelean [EMAIL PROTECTED] wrote: If the pages wouldn't be serializable, it wouldn't work in development mode. Is it right? I think that it is not necessarily about how large is application, in my case it is about how large is the model I'm working with for that specific request (ajax request). My action was: fetch a subview of a very large table 300x300, each cell has a heavy model object. Alex. Johan Compagner wrote: that looks very strange to me. We have also a very large app here and we dont notice a difference So i am very curious what is happening at your place then. Are you sure for example
Re: Form.updateFormComponentModels bug?
The extra memory for the ClickListener is negligible and does give you more flexibility because now you can have more than one interested party for the link click. My use case (fetch nested component, add listener) was already answered sufficiently by Martijn (bad OO, components should publish own events that make sense in the problem domain), but I still an eventlistener-based design could have merit (see the move towards Delegation Event Model in AWT: http://java.sun.com/j2se/1.3/docs/guide/awt/designspec/events.html). While wicket is not swing or awt, it's an interesting read. with the link abstract class you don't have any extra memory overhead but with the listener interface you have quite a lot because you need and extra reference in link itself, that holds an extra List (that again has its own stuff) and then you have an extra instance of the listener itself which by itself has its internal representation Don't underestimate this. especially because we also can use them in tableviews with a lot of cells. But as i said, if you want a listener interface then you can build it quite easily johan
Re: Disable the SecondLevelPageCache?
and also keep the ui state down to a minimum - which will make your app clusterable and thus scalable for the future. the app is clusterable it could serialize it just fine ;) 32MB and everything is serializeable thats an accomplishment! johan
Re: Wicket validation flaw?
convertvalue() isn't called for a datefield i think...
because i think the type is set (to Date) and then the converter is called:
convertedInput = converter.convertToObject(getInput(), getLocale());
so i don't think it will be trimmed...
johan
On 9/7/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
actually we do trim them.
convertinput() calls convertvalue() which does trim. so if you override
convertvalue() itself you need to trim yourself. however i do not see it
being overwritten anywhere. is this datetextfield from extensions or
wicket-datetime?
-igor
On 9/6/07, Matej Knopp [EMAIL PROTECTED] wrote:
I thought we were trimming textfield strings, but now i see it's no
longer the case. Is it a regression or a feature?
Also the missing message doesn't make much sense, can you please
report a JIRA issue and attach a quick start project?
-Matej
On 9/6/07, Alex Objelean [EMAIL PROTECTED] wrote:
I've discovered the following issue:
When using a DateTextField in a form (with the format: dd/MM/),
user
by
mistake add an extra space (for instance: 06/09/2007 ) and submit
the
form. The are two problems:
1) I would expect the convertor to convert this value correct, but the
AbstractConverter.parse method throws a ConversionException because:
(position.getIndex() != stringValue.length())
2) The above exception is not reported anywhere, because validate
method
does not check if the input is valid after converting its value:
public final void validate()
{
validateRequired();
if (isValid())
{
convertInput();
if (isValid() isRequired()
getConvertedInput() == null
isInputNullable())
{
reportRequiredError();
}
/*isn't something like this missing here?*/
if
(!isValid()) { /*report Conversion error*/ }
if (isValid())
{
validateValidators();
}
}
}
Any thoughts?
Thank you!
Alex.
--
View this message in context:
http://www.nabble.com/Wicket-validation-flaw--tf4390183.html#a12517215
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: Page state, undo and versioning?
and that shouldn't be done because then backbutton or what ever you do will
always
request the page again, that would fix our back button problem even more :)
but thats
a horrible user experience
johan
On 9/10/07, Matej Knopp [EMAIL PROTECTED] wrote:
It doesn't set the no-store flag.
protected void configureResponse()
{
super.configureResponse();
if (getWebRequestCycle().getResponse() instanceof
WebResponse)
{
final WebResponse response =
getWebRequestCycle().getWebResponse();
response.setHeader(Pragma, no-cache);
response.setHeader(Cache-Control, no-cache,
max-age=0,
must-revalidate); // no-store is not set here
}
}
-Matej
On 9/10/07, Doug Leeper [EMAIL PROTECTED] wrote:
Matej Knopp-2 wrote:
What Wicket version are you using? Because for reliable versioning you
will need 1.3. Also you problem can be browser caching the initial DOM
tree (not the modified one). So you should force browser to fire http
request on back button too - adding CacheControl: no-store to other
CacheControl flags in Page.configureResponse. Also this might not work
in Opera, as the browser is quite stubborn and tends to cache things
anyway.
-Matej
I thought the cache control flags that you have indicated should already
be
called/set if the page in question is a WebPage (see
WebPage.configureResponse() )
Do I need to do anything to ensure that this method is called?
- Doug
--
View this message in context:
http://www.nabble.com/Page-state%2C-undo-and-versioning--tf4390362.html#a12603266
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: First Day Disgust!
what are we to provide? a prebuilt project for eclipse? a prebuilt project for netbeans? a prebuilt project for idea? a prebuilt project for jedit? a prebuilt project for ant? a prebuilt project for make? a prebuilt project for buildr? a prebuilt project for foo? i want Igors Special Build johan
Re: Any interest in a Wicket User Group meeting in The Netherlands?
i will discuss tomorrow with Martijn when we could organize it. johan On 9/11/07, Matthijs Wensveen [EMAIL PROTECTED] wrote: Hi, I'm interested, and I think several of my co-workers are too. Matthijs Danny van Bruggen wrote: I'm interested. I've only just started, so every topic is helpful to me :) Amersfoort is fine for me. Danny On 9/7/07, Johan Compagner [EMAIL PROTECTED] wrote: hi, I can organize one if there is enough interest Martijn and i will be there then. And for example if people are also interested in the wicket security i will also drag Maurice to the table. johan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Matthijs Wensveen Func. Internet Integration W http://www.func.nl T +31 20 423 F +31 20 4223500 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Any interest in a Wicket User Group meeting in The Netherlands?
just like last week? On 9/11/07, Maurice Marrink [EMAIL PROTECTED] wrote: I don't think Martijn will be here tomorrow Johan. He has taken some time off to work on the book. Maurice On 9/11/07, Eelco Hillenius [EMAIL PROTECTED] wrote: On 9/11/07, Wouter Huijnink [EMAIL PROTECTED] wrote: Hi list, Great idea! At Func. we'd also planned to suggest a usergroup meeting in the netherlands. We're more than willing to host the event - our office is situated opposite the Amsterdam Central Station: http://local.google.com/?ie=UTF8t=hom=1q=52.378566,4.896233+(Func.+Internet+Integration)ll=52.378573,4.896233spn=0.004139,0.010042z=17iwloc=addr We'll take care of food and drinks. Would it be a good idea to add a Community Events section to the wiki, where we can discuss the preferred date and register? How about using our calendar on google? http://www.google.com/calendar/embed?src=kps9lev85benpg7ppaafpje5d8%40group.calendar.google.com 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: Default focus behavior for ajax request
see my comments in that issue. Its not that we have to do something on the serverside this is a clientside issue. johan On 9/11/07, Carlos Pita [EMAIL PROTECTED] wrote: behavior if the event is onblur. Can you submit RFE? Done. I filed it as minor improvement https://issues.apache.org/jira/browse/WICKET-957. Because currently there is no way during ajax processing to determine that the event was a focus related one. I think that it's good to Maybe setting focusComponent to null by default for any AjaxEventBehavior whose event happens to be onblur or onchange will be enough. Even if done at the AjaxFormComponentUpdatingBehavior imo this will be a great relief for people who are implementing their first wicket ajax-validated forms and haven't a clue about the cause of such a strange focus behavior that suddenly possesses their browsers. Regards, Carlos - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exception
i think we are closing the response now later then we did even after
Session.detach()
will look at it.
On 8/30/07, Jan Kriesten [EMAIL PROTECTED] wrote:
Hi,
with the latest snapshot I get the following exception when invalidating a
session:
---8---
[09:46:04.142] java.lang.IllegalStateException: Can't call getEntrySet()
when
session is no longer valid.
[09:46:04.142] at
com.caucho.server.session.SessionImpl.getEntrySet(SessionImpl.java:1205)
[09:46:04.142] at
com.caucho.server.session.SessionImpl.store(SessionImpl.java:1134)
[09:46:04.142] at
com.caucho.server.session.SessionManager.store(SessionManager.java:1583)
[09:46:04.142] at
com.caucho.server.cluster.ClusterObject.store(ClusterObject.java:402)
[09:46:04.142] at com.caucho.server.session.SessionImpl.save(
SessionImpl.java:914)
[09:46:04.142] at
com.caucho.server.connection.AbstractHttpRequest.saveSession(
AbstractHttpRequest.java:2375)
[09:46:04.142] at
com.caucho.server.connection.AbstractHttpResponse.sendRedirect(
AbstractHttpResponse.java:611)
[09:46:04.142] at
org.apache.wicket.protocol.http.WebResponse.redirect(WebResponse.java:214)
[09:46:04.142] at
org.apache.wicket.protocol.http.BufferedWebResponse.close(
BufferedWebResponse.java:67)
[09:46:04.142] at
org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:288)
[09:46:04.142] at
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java
:129)
[09:46:04.142] at
com.caucho.server.dispatch.FilterFilterChain.doFilter(
FilterFilterChain.java:73)
[09:46:04.142] at
com.caucho.server.cache.CacheFilterChain.doFilter(CacheFilterChain.java
:159)
[09:46:04.142] at
com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java
:175)
[09:46:04.142] at
com.caucho.server.dispatch.ServletInvocation.service(
ServletInvocation.java:240)
[09:46:04.142] at
com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:263)
[09:46:04.142] at com.caucho.server.port.TcpConnection.run(
TcpConnection.java:481)
[09:46:04.142] at com.caucho.util.ThreadPool$Item.runTasks(
ThreadPool.java:685)
[09:46:04.142] at com.caucho.util.ThreadPool$Item.run(ThreadPool.java
:607)
[09:46:04.142] at java.lang.Thread.run(Thread.java:619)
---8---
What I'm doing on logout is calling the logout-page and there:
public LogoutPage()
{
AuthServiceWebSession.get().logout(); // Invalidates the session
setResponsePage( LoginPage.class );
}
What change might have caused this and how can I circumvent this?
Cheers, --- Jan.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exception
hmm
we always closed the buffer at that place
it seems that resin suddenly wants to do a save of session objects when it
wants to redirect
that seems very odd, it should at least test if it can do that. I would
report a bug by caucho.
johan
On 8/30/07, Jan Kriesten [EMAIL PROTECTED] wrote:
Hi,
with the latest snapshot I get the following exception when invalidating a
session:
---8---
[09:46:04.142] java.lang.IllegalStateException: Can't call getEntrySet()
when
session is no longer valid.
[09:46:04.142] at
com.caucho.server.session.SessionImpl.getEntrySet(SessionImpl.java:1205)
[09:46:04.142] at
com.caucho.server.session.SessionImpl.store(SessionImpl.java:1134)
[09:46:04.142] at
com.caucho.server.session.SessionManager.store(SessionManager.java:1583)
[09:46:04.142] at
com.caucho.server.cluster.ClusterObject.store(ClusterObject.java:402)
[09:46:04.142] at com.caucho.server.session.SessionImpl.save(
SessionImpl.java:914)
[09:46:04.142] at
com.caucho.server.connection.AbstractHttpRequest.saveSession(
AbstractHttpRequest.java:2375)
[09:46:04.142] at
com.caucho.server.connection.AbstractHttpResponse.sendRedirect(
AbstractHttpResponse.java:611)
[09:46:04.142] at
org.apache.wicket.protocol.http.WebResponse.redirect(WebResponse.java:214)
[09:46:04.142] at
org.apache.wicket.protocol.http.BufferedWebResponse.close(
BufferedWebResponse.java:67)
[09:46:04.142] at
org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:288)
[09:46:04.142] at
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java
:129)
[09:46:04.142] at
com.caucho.server.dispatch.FilterFilterChain.doFilter(
FilterFilterChain.java:73)
[09:46:04.142] at
com.caucho.server.cache.CacheFilterChain.doFilter(CacheFilterChain.java
:159)
[09:46:04.142] at
com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java
:175)
[09:46:04.142] at
com.caucho.server.dispatch.ServletInvocation.service(
ServletInvocation.java:240)
[09:46:04.142] at
com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:263)
[09:46:04.142] at com.caucho.server.port.TcpConnection.run(
TcpConnection.java:481)
[09:46:04.142] at com.caucho.util.ThreadPool$Item.runTasks(
ThreadPool.java:685)
[09:46:04.142] at com.caucho.util.ThreadPool$Item.run(ThreadPool.java
:607)
[09:46:04.142] at java.lang.Thread.run(Thread.java:619)
---8---
What I'm doing on logout is calling the logout-page and there:
public LogoutPage()
{
AuthServiceWebSession.get().logout(); // Invalidates the session
setResponsePage( LoginPage.class );
}
What change might have caused this and how can I circumvent this?
Cheers, --- Jan.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Any interest in a Wicket User Group meeting in The Netherlands?
i think that will be a bit to much for a first time user group meeting that is more or less for dutch people (but ofcourse everybody is welcome) johan On 9/12/07, Arje Cahn [EMAIL PROTECTED] wrote: Hi there, Great to see that there's so much interest in a Wicket meeting in The Netherlands! I'll definitely be there! The Apache Cocoon community has been organizing its (very) succesful annual Cocoon GetTogether in Amsterdam for the last 2 years. I've been booking the rooms, wireless, lunch, etc, at the Felix Meritis building (Keizersgracht) for that. It's a really nice, scalable, inspiring, cheap and independent environment. See http://www.cocoongt.org/archive/2006/index.html for last year's edition. They have rooms from 10 to 200 people. With chairs, etc. Amsterdam has been a huge benefit since it's really cheap to fly to from all around the world. Any interest? Arjé Cahn Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 [EMAIL PROTECTED] / [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to remove a page from Wicket's back button memory?
yes thats a know bug, i think matej did fix that today or is fixing it right now. johan On 9/12/07, Justin Morgan (Logic Sector) [EMAIL PROTECTED] wrote: Thanks, I tried that but I get an exception in the Wicket 1.3 snapshot I'm using. Is there a known bug in the remove(Page) method? Or maybe I'm simply using it wrong? (after logging in, my secured page is attempting to invoke loginpage.getpagemap().remove (loginpage) in the secured page's constructor). [01:39:54,832 ERROR org.apache.wicket.RequestCycle]: Can't instantiate page using constructor public com.logicsector.web.page.SecuredExamplePage (org.apache.wicket.PageParameters) and argument exampleId = 100 org.apache.wicket.WicketRuntimeException: Can't instantiate page using constructor public com.logicsector.web.page.SecuredExamplePage (org.apache.wicket.PageParameters) and argument exampleId = 100 at org.apache.wicket.session.DefaultPageFactory.newPage (DefaultPageFactory.java:175) at org.apache.wicket.session.DefaultPageFactory.newPage (DefaultPageFactory.java:96) at org.apache.wicket.request.target.component.BookmarkablePageRequestTarget .newPage(BookmarkablePageRequestTarget.java:262) at org.apache.wicket.request.target.component.BookmarkablePageRequestTarget .getPage(BookmarkablePageRequestTarget.java:277) at org.apache.wicket.request.target.component.BookmarkablePageRequestTarget .processEvents(BookmarkablePageRequestTarget.java:205) at org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents (AbstractRequestCycleProcessor.java:90) at org.apache.wicket.RequestCycle.processEventsAndRespond (RequestCycle.java:1018) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1093) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1162) at org.apache.wicket.RequestCycle.request(RequestCycle.java: 485) at org.apache.wicket.protocol.http.WicketFilter.doGet (WicketFilter.java:261) at org.apache.wicket.protocol.http.WicketServlet.doGet (WicketServlet.java:126) at javax.servlet.http.HttpServlet.service(HttpServlet.java:690) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter (ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke (StandardWrapperValve.java:228) at org.apache.catalina.core.StandardContextValve.invoke (StandardContextValve.java:175) at org.apache.catalina.core.StandardHostValve.invoke (StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke (ErrorReportValve.java:104) at org.apache.catalina.core.StandardEngineValve.invoke (StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service (CoyoteAdapter.java:216) at org.apache.coyote.http11.Http11Processor.process (Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol $Http11ConnectionHandler.process(Http11Protocol.java:634) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run (JIoEndpoint.java:445) at java.lang.Thread.run(Thread.java:613) Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.NativeConstructorAccessorImpl.newInstance0 (Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance (NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance (DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance (Constructor.java:494) at org.apache.wicket.session.DefaultPageFactory.newPage (DefaultPageFactory.java:154) ... 25 more Caused by: java.lang.ClassCastException: java.lang.Integer at org.apache.wicket.protocol.http.pagestore.PageWindowManager.removePage (PageWindowManager.java:544) at org.apache.wicket.protocol.http.pagestore.DiskPageStore $SessionEntry.removePage(DiskPageStore.java:252) at org.apache.wicket.protocol.http.pagestore.DiskPageStore.removePage (DiskPageStore.java:616) at org.apache.wicket.protocol.http.pagestore.DiskPageStore.removePage (DiskPageStore.java:645) at org.apache.wicket.protocol.http.SecondLevelCacheSessionStore $SecondLevelCachePageMap.removeEntry (SecondLevelCacheSessionStore.java:368) at org.apache.wicket.PageMap.remove(PageMap.java:289) at com.logicsector.web.page.SecuredExamplePage.init (SecuredExamplePage.java:64) ... 30 more On Sep 12, 2007, at 12:59 AM, Johan Compagner wrote: page.getPageMap().remove(page) johan On 9/12/07, Justin Morgan (Logic Sector) [EMAIL PROTECTED] wrote: Hi, Okay, another
Re: Any interest in a Wicket User Group meeting in The Netherlands?
looks like a good idea On 9/13/07, Wouter Huijnink [EMAIL PROTECTED] wrote: Maybe it's an idea to setup a Wiki page where people can add their name so we really get some insight in how many people would actually be interested in joining such a meetup? Maybe it's just 10 and then I'll shut up anyway 8-) Couldn't we add a 'Community' section to the http://cwiki.apache.org/WICKET/ wiki? Then create sub-topics for all local initiatives, where we can subscribe and discuss suitable/possible locations and dates. regards, Wouter -- Wouter Huijnink Func. Internet Integration W http://www.func.nl T +31 20 423 F +31 20 4223500 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Any interest in a Wicket User Group meeting in The Netherlands?
because it seems there can be quite a lot of people i have to look around where to do it. and also what kind of day because this many people then 2,3 hours in the evening is maybe a bit to little time. we could do it in a weekend on saturday (afternoon) and then maybe later on getting something to eat with the people who want that. ofcourse we could also do it on a weekday (Friday) and start at 4. But then getting some room is even more difficult. johan On 9/14/07, Arje Cahn [EMAIL PROTECTED] wrote: Added a Bookmarkable link (http://cwiki.apache.org/WICKET/community-meetups.html), flagging the URL to the static page that should be used to reduce the load on the wiki itself! Thanks, Gwyn :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: compressing resources which are not in the classpath
shared resources and refenences to it are for basic use pretty simple,
SharedResourece.add() adds a resource under a specific name, and then
you make a ResourceReference with that same name in your component
that has a src or href that wants to show the resource
On 9/17/07, Andrew Klochkov [EMAIL PROTECTED] wrote:
Wow, Kent, thanks a lot for the code!!
I wonder shouldn't something like this be in the framework core?
Also I tried hard to find some docs about shared resources at all but
didn't find any. The interface of the SharedResoruces class is quite
confusing - almost all of its methods contain javadoc warning THIS
METHOD IS NOT PART OF THE WICKET PUBLIC API. DO NOT USE IT.. Am I
missing something?
Kent Tong wrote:
Andrew Klochkov wrote:
Hi!
How to compress resources (css, java scripts) which are lying not in
the classpath but in /css and /js in the webapp context folder? How can
I create a CompressedResourceReference to such a resource?
Try:
public class MyApp extends WebApplication {
protected void init() {
getSharedResources().add(
r1,
new CompressingWebResource(new
ContextRelativeResource(
/css/f1.css)));
mountSharedResource(foo, org.apache.wicket.Application/r1);
}
}
public class CompressingWebResource extends WebResource {
private abstract class CompressingResourceStream implements
IResourceStream
{
private static final long serialVersionUID = 1L;
/** Cache for compressed data */
private SoftReference cache = new SoftReference(null);
/** Timestamp of the cache */
private Time timeStamp = null;
/**
* @see org.apache.wicket.util.resource.IResourceStream#close()
*/
public void close() throws IOException {
}
/**
* @see
org.apache.wicket.util.resource.IResourceStream#getContentType()
*/
public String getContentType() {
return getOriginalResourceStream().getContentType();
}
/**
* @see
org.apache.wicket.util.resource.IResourceStream#getInputStream()
*/
public InputStream getInputStream()
throws ResourceStreamNotFoundException {
if (supportsCompression()) {
return new
ByteArrayInputStream(getCompressedContent());
} else {
return
getOriginalResourceStream().getInputStream();
}
}
/**
* @see
org.apache.wicket.util.resource.IResourceStream#getLocale()
*/
public Locale getLocale() {
return getOriginalResourceStream().getLocale();
}
/**
* @see
org.apache.wicket.util.watch.IModifiable#lastModifiedTime()
*/
public Time lastModifiedTime() {
return getOriginalResourceStream().lastModifiedTime();
}
/**
* @see org.apache.wicket.util.resource.IResourceStream#length()
*/
public long length() {
if (supportsCompression()) {
return getCompressedContent().length;
} else {
return getOriginalResourceStream().length();
}
}
/**
* @see
org.apache.wicket.util.resource.IResourceStream#setLocale(java.util.Locale)
*/
public void setLocale(Locale locale) {
getOriginalResourceStream().setLocale(locale);
}
/**
* @return compressed content
*/
private byte[] getCompressedContent() {
IResourceStream stream = getOriginalResourceStream();
try {
byte ret[] = (byte[]) cache.get();
if (ret != null timeStamp != null) {
if
(timeStamp.equals(stream.lastModifiedTime())) {
return ret;
}
}
ByteArrayOutputStream out = new
ByteArrayOutputStream();
GZIPOutputStream zout = new
GZIPOutputStream(out);
Streams.copy(stream.getInputStream(), zout);
zout.close();
stream.close();
ret = out.toByteArray();
Re: serving images from db - direct url access
look at WebApplication.mountSharedResources() and RequestCycle.urlFor(final ResourceReference resourceReference, ValueMap parameters) johan On 9/17/07, Leszek Gawron [EMAIL PROTECTED] wrote: Hello, I already know how to serve an image from database - dead easy. Thing is the image is a component. What i would like to achieve now is to have a very small image retrieving api: http://host/mywicketapp/images/id http://host/mywicketapp/images/id/next http://host/mywicketapp/images/id/previous http://host/mywicketapp/images/latest how do I mount a Resource at specified path? how do I pass parameters to it ? (/next /previous) -- Leszek Gawron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: serving images from db - direct url access
thats completely automatic. in your Resource that you have mounted under /images/ when you get a request to it you just do: Resource.getParameters() johan On 9/17/07, Leszek Gawron [EMAIL PROTECTED] wrote: Johan Compagner wrote: look at WebApplication.mountSharedResources() and RequestCycle.urlFor(final ResourceReference resourceReference, ValueMap parameters) I did the exact thing. Please see my others post about decoding request parameters. -- Leszek Gawron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Error in invalidateNow()
we really should make that invalidateNow() method very hard to find or
something like that.
don't use invalidateNow() so easily that is only valid is very very specific
circumstances.
just call invalidate()
But what you encounter is a bug that should be fixed if it isn't already by
matej
johan
On 9/18/07, Jeremy Thomerson [EMAIL PROTECTED] wrote:
Not sure why I suddenly started getting this error...
I'm using BETA3. In my development environment, everything runs fine. In
production, I just started getting this error. The differences between
the
two environments are - prod is linux / tomcat. dev is windows / jetty in
eclipse. Obviously the dev envir is in development mode, and prod is in
deployment mode.
I have a page, SignOut:
public SignOut() {
getWebSession().invalidateNow();
throw new
RestartResponseAtInterceptPageException(getApp().getHomePage());
}
I get this error (only in prod):
java.lang.RuntimeException: java.io.FileNotFoundException:
/usr/java/tomcat-
5.5/work/Catalina/localhost/foo/bar-servlet-name-filestore/6B26389AA5F92EE
3ED34D262304E7E2E/pm-null (No such file or directory)
at
org.apache.wicket.protocol.http.pagestore.FileChannelPool.newFileChannel(
FileChannelPool.java:107)
at
org.apache.wicket.protocol.http.pagestore.FileChannelPool.getFileChannel(
FileChannelPool.java:174)
at
org.apache.wicket.protocol.http.pagestore.DiskPageStore$SessionEntry.savePage
(DiskPageStore.java:226)
at
org.apache.wicket.protocol.http.pagestore.DiskPageStore.flushPagesToSaveList
(DiskPageStore.java:779)
at org.apache.wicket.protocol.http.pagestore.DiskPageStore.unbind(
DiskPageStore.java:726)
at
org.apache.wicket.protocol.http.SecondLevelCacheSessionStore.onUnbind(
SecondLevelCacheSessionStore.java:729)
at org.apache.wicket.protocol.http.AbstractHttpSessionStore.unbind
(
AbstractHttpSessionStore.java:269)
at
org.apache.wicket.protocol.http.AbstractHttpSessionStore.invalidate(
AbstractHttpSessionStore.java:210)
at org.apache.wicket.Session.invalidateNow(Session.java:912)
at com.mycompany.web.wicket.pages.SignOut.init(SignOut.java:12)
Thank you in advance!
Jeremy Thomerson
Re: threading issues - continued
the nullpointer comes from outside of wicket (criterion class) but you say if you click quickly you only get it? all pages are blocked by a barrier that is build around the pagemap. its in Session.get page method. only 1 request can pass that at the same time. but what is suddenly null that you dont expect to be null? On 9/18/07, Sam Hough [EMAIL PROTECTED] wrote: That is pretty much it. Except that: Caused by: java.lang.NullPointerException at com.namechangedtoprotectguilty.search.Criterion.getHelper(Criterion.java:200) at sun.reflect.GeneratedMethodAccessor41.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.wicket.util.lang.PropertyResolver$MethodGetAndSet.getValue(PropertyResolver.java:1030) Blows up in our code in a way that really looks like a multithreading issue to me. If I click slowly no problems, if I click quickly on a slow page it reliably blows up. Guess I could put in a sync filter to double check that it is a sync error. We don't create any threads so apart from threading issue I can't see what else it could be... igor.vaynberg wrote: show us the full stack trace -igor On 9/18/07, Sam Hough [EMAIL PROTECTED] wrote: Which bit of code does the blocking on the server? I'm getting what looks very much like a threading issue. I've looked at all the methods below and can't see any obvious sync code... I'm using 1.3-beta3 at org.apache.wicket.util.lang.PropertyResolver$MethodGetAndSet.getValue( PropertyResolver.java:1034) at org.apache.wicket.util.lang.PropertyResolver.getObjectAndGetSetter( PropertyResolver.java:247) at org.apache.wicket.util.lang.PropertyResolver.getValue( PropertyResolver.java:89) at org.apache.wicket.model.AbstractPropertyModel.getObject( AbstractPropertyModel.java:110) at org.apache.wicket.Component.getModelObject(Component.java:1293) at org.apache.wicket.Component$2.compare(Component.java:540) at org.apache.wicket.Component.setModelObject(Component.java:2522) at org.apache.wicket.markup.html.form.FormComponent.updateModel( FormComponent.java:1002) at org.apache.wicket.markup.html.form.Form$14.validate(Form.java :1642) at org.apache.wicket.markup.html.form.Form$ValidationVisitor.formComponent( Form.java:160) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrderHelper (FormComponent.java:403) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrderHelper (FormComponent.java:390) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrderHelper (FormComponent.java:390) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrderHelper (FormComponent.java:390) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrderHelper (FormComponent.java:390) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrder (FormComponent.java:368) at org.apache.wicket.markup.html.form.Form.visitFormComponentsPostOrder( Form.java:1004) at org.apache.wicket.markup.html.form.Form.updateFormComponentModels( Form.java:1637) at org.apache.wicket.markup.html.form.Form.process(Form.java:834) at org.apache.wicket.markup.html.form.Form.onFormSubmitted( Form.java:783) at org.apache.wicket.ajax.form.AjaxFormSubmitBehavior.onEvent( AjaxFormSubmitBehavior.java:126) at org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java :163) at org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest( AbstractDefaultAjaxBehavior.java:268) at org.apache.wicket.request.target.component.listener.BehaviorRequestTarget.processEvents (BehaviorRequestTarget.java:100) at org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents( AbstractRequestCycleProcessor.java:90) at org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java :1032) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1108) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1177) at org.apache.wicket.RequestCycle.request(RequestCycle.java:500) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:261) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java :127) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter( ApplicationFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter( ApplicationFilterChain.java:188) at
Re: wicket scalability
What do you mean with Scaling? Wicket scales pretty well. because we fully support clustering out of the box. So you can add just add new servers. Wicket it self is fast, the database would be much more of a bottleneck. johan On 9/19/07, Lowell Kirsh [EMAIL PROTECTED] wrote: For work I'm trying to use wicket, but my boss wants to be reassured that it will scale well. Can anyone point me to any sources (not anecdotes) about how well wicket scales? And yes, I know my question is vague, but right now, so are our requirements. Thanks, Lowell - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PropertyResolverConverter and non-String values
thats final you could try to do something with: protected Object convertChoiceIdToChoice(String id) But that is an id and how is that id converted to what? Is that the ClassDescriptionBean? And that Again must be converted to something else? johan On 9/19/07, Federico Fanton [EMAIL PROTECTED] wrote: On Wed, 19 Sep 2007 12:11:10 +0200 Federico Fanton [EMAIL PROTECTED] wrote: Obviously PropertyResolverConverter doesn't know how to map a ClassDescriptionBean to the corresponding Class, but how am I supposed to do it? I already have a custom ConverterLocator in place, but it looks like it gets called only when the source (or the destination) class of the conversion is a String.. Should I override AbstractSingleSelectChoice.convertValue() ? ^^; - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: threading issues - continued
but you get null pointers in the serverside. So what should that have to do with busy parsing on the client side That second submit is being done again (with the OLD dom) and that maybe doesn't map correctly any more? The problem is that the ajax request and waiting for the response and updating the dom should be done then completely synchronously Because it could be a problem yes when you click fast on things that will be replaced.. johan On 9/19/07, Sam Hough [EMAIL PROTECTED] wrote: Yes. Click A updates part of the form. Click B (very soon after A) also submits that form. So my suspicion is that the browser is still busy parsing the last update and click B sends a form in an intermediate state. Does that sound likely? I've seen it in the past that after innerHTML you have to wait a while to access the DOM. Johan Compagner wrote: do you click fast on a dom portion that is being replaced by the previous request? johan On 9/19/07, Sam Hough [EMAIL PROTECTED] wrote: Bit more information is that the bean property that is causing the problem is being set to null by my html form via a wicket ajax update... Could it be that although wicket is doing everything correctly the DOM in (firefox 2) has not settled after the elmt.innerHTML= ... from the previous ajax response so the next click sends an update that I wouldn't expect? Any options in wicket to block the UI till the DOM has settled? Or shall I point my html monkey at it? Sam Hough wrote: Must be me then. I'll try and pin it down more. Hmmm. Johan Compagner wrote: the nullpointer comes from outside of wicket (criterion class) but you say if you click quickly you only get it? all pages are blocked by a barrier that is build around the pagemap. its in Session.get page method. only 1 request can pass that at the same time. but what is suddenly null that you dont expect to be null? On 9/18/07, Sam Hough [EMAIL PROTECTED] wrote: That is pretty much it. Except that: Caused by: java.lang.NullPointerException at com.namechangedtoprotectguilty.search.Criterion.getHelper( Criterion.java:200) at sun.reflect.GeneratedMethodAccessor41.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.wicket.util.lang.PropertyResolver$MethodGetAndSet.getValue( PropertyResolver.java:1030) Blows up in our code in a way that really looks like a multithreading issue to me. If I click slowly no problems, if I click quickly on a slow page it reliably blows up. Guess I could put in a sync filter to double check that it is a sync error. We don't create any threads so apart from threading issue I can't see what else it could be... igor.vaynberg wrote: show us the full stack trace -igor On 9/18/07, Sam Hough [EMAIL PROTECTED] wrote: Which bit of code does the blocking on the server? I'm getting what looks very much like a threading issue. I've looked at all the methods below and can't see any obvious sync code... I'm using 1.3-beta3 at org.apache.wicket.util.lang.PropertyResolver$MethodGetAndSet.getValue( PropertyResolver.java:1034) at org.apache.wicket.util.lang.PropertyResolver.getObjectAndGetSetter( PropertyResolver.java:247) at org.apache.wicket.util.lang.PropertyResolver.getValue( PropertyResolver.java:89) at org.apache.wicket.model.AbstractPropertyModel.getObject( AbstractPropertyModel.java:110) at org.apache.wicket.Component.getModelObject(Component.java:1293) at org.apache.wicket.Component$2.compare(Component.java :540) at org.apache.wicket.Component.setModelObject(Component.java:2522) at org.apache.wicket.markup.html.form.FormComponent.updateModel( FormComponent.java:1002) at org.apache.wicket.markup.html.form.Form$14.validate(Form.java :1642) at org.apache.wicket.markup.html.form.Form$ValidationVisitor.formComponent ( Form.java:160) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrderHelper (FormComponent.java:403) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrderHelper (FormComponent.java:390) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrderHelper (FormComponent.java:390) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrderHelper (FormComponent.java:390
Re: StringResourceModel.toString()
toString is for debug (except for the default String/Number classes and so on) The problem is that StirngResourceModel uses internal stuff that doesnt have to be set at that time of the toString() call so debug statements don't work and generate nullpointers. johan On 9/21/07, Jan Kriesten [EMAIL PROTECTED] wrote: hi, there seems to be a change in the current trunk to StringResourceModel.toString() - which before returned the localized String. now it returns some 'useful' information like StringResourceModel[key:CONTENTTYPE:date.published.description ,default:null,params:] hmm. why was that changed? regards, --- jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Possible to validate file size prior to sending?
wow, uploading 200+mb files! and you still go over that? i don't think we get the size somehow in advance On 9/21/07, spencer.c [EMAIL PROTECTED] wrote: I have a form with a FileUploadField, where the maximum file size is fairly large (100-200MB). I set the maximum size using the form's: setMaxSize(Bytes.megabytes(200)); This works fine, as the form only gets processed when the file is under that size. However, if the file is over that size, the user is not notified until the upload completes, or at least gets beyond the limit. So if someone were to upload a 300 MB file, they won't find out that the file is too large until after they exceed 200 MB sent, which can be a long time. Can anything be done to validate the file size prior to exceeding the maximum file size? I think that if the file size is exceeded, the form never gets processed at all, so server side it seems like it would be out, but if I could add a client side validation in addition to the server side validation, that would be great. Has anyone else run into this? -- View this message in context: http://www.nabble.com/Possible-to-validate-file-size-prior-to-sending--tf4497198.html#a12825206 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NoSuchMethodException / PropertyResolver
thats just a debug log:
*
catch* (Exception e)
{
*log*.debug(Cannot find getter + clz + . + expression, e);
}
maybe i should just delete that log statement to kill the confusion.
johan
On 9/25/07, Phillip Rhodes [EMAIL PROTECTED] wrote:
Hi guys, I'm seeing a weird problem with Wicket. I *think* it's the
same problem discussed here
http://www.nabble.com/Tracking-down-an-elusive-error-during-migration-to-1.3-t4381647.html
,
but won't swear to it. Basically Wicket
is logging a NoSuchMethodException when rendering my page.
This is using Wicket 1.2.4, running on JDK 1.6, JBoss 4.0.5, on Windows
2000 Server.
The java code for the page in question looks like this:
*** BEGIN JAVA CODE ***
package org.openqabal.web.registration;
import org.openqabal.auth.encoder.QPasswordEncoder;
import org.openqabal.core.lib.domain.QGenericUserAccount;
import org.openqabal.core.lib.domain.impl.UserAccountImpl;
import org.openqabal.core.lib.service.QHybridUserService;
import wicket.PageParameters;
import wicket.examples.WicketExampleHeader;
import wicket.markup.html.WebPage;
import wicket.markup.html.form.Form;
import wicket.markup.html.form.PasswordTextField;
import wicket.markup.html.form.TextField;
import wicket.markup.html.panel.FeedbackPanel;
import wicket.model.PropertyModel;
import wicket.spring.injection.annot.SpringBean;
import wicket.util.string.Strings;
import wicket.util.value.ValueMap;
public final class UserRegistration1 extends WebPage
{
@SpringBean(name=hybridUserService)
private QHybridUserService userService;
@SpringBean(name=passwordEncoderBean)
private QPasswordEncoder passwordEncoder;
// note: TODO UserAccountFactory here...
public UserRegistration1()
{
this( null );
}
public UserRegistration1( final PageParameters parameters )
{
final String packageName =
getClass().getPackage().getName();
add(new WicketExampleHeader(mainNavigation,
Strings.afterLast(packageName, '.'), this));
// Create feedback panel and add to page
final FeedbackPanel feedback = new
FeedbackPanel(feedback);
add(feedback);
add(new UserRegistrationForm(userForm));
}
public final class UserRegistrationForm extends Form
{
// El-cheapo model for form
private final ValueMap properties = new ValueMap();
public UserRegistrationForm(final String componentName)
{
super(componentName);
// Attach textfield components that edit properties
map model
add(new TextField(firstName, new
PropertyModel(properties,
firstName)));
add(new TextField(lastName, new
PropertyModel(properties,
lastName)));
add( new TextField( loginName, new
PropertyModel(properties,
loginName)));
add(new TextField(emailAddress, new
PropertyModel(properties,
emailAddress)));
add(new PasswordTextField(password, new
PropertyModel(properties,
password)));
add(new PasswordTextField(confirmPassword, new
PropertyModel(properties, confirmPassword)));
}
public final void onSubmit()
{
System.out.println( onSubmit() );
String firstName = properties.getString
(firstName);
String lastName = properties.getString(lastName);
String loginName = properties.getString(
loginName );
String emailAddress = properties.getString
(emailAddress);
String password = properties.getString(password);
String confirmPassword = properties.getString
(confirmPassword);
// create and persist user object using the details
we
// received...
QGenericUserAccount userAccount = new
UserAccountImpl();
userAccount.setLoginName( loginName );
userAccount.setPassword( passwordEncoder.encode
(password));
userService.createAllAccounts(userAccount);
}
}
}
*** END JAVA CODE ***
and here is the relevant stuff from the log. FWIW, I get this
for every one of the above properties, but am only posting this
log snippet since the others are all the same.
*** BEGIN LOG / STACKTRACE ***
2007-09-24 21:55:13,890 DEBUG [wicket.Page] Rendered [MarkupContainer
[Component id = lastName, page =
org.openqabal.web.registration.UserRegistration1, path =
0:userForm:lastName.TextField,
Re: auto dirty and widget factory
we already have a change recorder on a page for its components, all the methods you mention should also call that. Then it can also be made much more fail prove because a component should just 'fire' call the change method. because state is not just those what you mention but could be anything On 9/26/07, Sam Hough [EMAIL PROTECTED] wrote: Eelco, Meant to say we have our first case where we want a component to update because the model has changed. It is a field that only gets updated on the server not directly through an HTML form... Since it is only one so far a hand coded Dirty.mark(this) is not too evil. Sorry, talking to myself again. -- View this message in context: http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12899100 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: auto dirty and widget factory
but this discussion is not just about getter/setters (i don't care about those) but also for add and remove.. then we are getting into some other stuff johan On 9/26/07, Eelco Hillenius [EMAIL PROTECTED] wrote: On 9/26/07, Martijn Dashorst [EMAIL PROTECTED] wrote: I disagree. We need to keep an eye out for those that begin to use the framework. We have seen enough people that randomly start to override methods just to work around some perceived wall that typically isn't there if they actually thought about their problem in the first place. Well yeah, in general that is true. For setters... I've grown tired of the many discussions here I guess. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: auto dirty and widget factory
the problem is that that still not really does auto dirty.. Because where does it end? just add/remove/visitble/enable? The nice thing is we have already something like that: thats page versioning with the undo/change map. If we extend that a little bit then we could have something like componentChanged(component) on a page (or somekind of listener) and that component did trigger it self what ever did happen on it (getting a child, settting the visibility, or setting an internal none wicket core property) johan On 9/26/07, Eelco Hillenius [EMAIL PROTECTED] wrote: On 9/26/07, Johan Compagner [EMAIL PROTECTED] wrote: but this discussion is not just about getter/setters (i don't care about those) but also for add and remove.. then we are getting into some other stuff Yes. Getters/ setters are less tricky. Though I'm still not breaking in sweat when I imagine removing final on add and remove. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: auto dirty and widget factory
that doesn't matter, We don't store them (the changes for rollback) anymore but the page still gets the events. Because we still have to know it so that we can increment the page counter... johan On 9/27/07, Sam Hough [EMAIL PROTECTED] wrote: This posting put me off using the change recorder: http://www.nabble.com/forum/ViewPost.jtp?post=12473029framed=y Did I get the wrong end of the stick? Johan Compagner wrote: we already have a change recorder on a page for its components, all the methods you mention should also call that. Then it can also be made much more fail prove because a component should just 'fire' call the change method. because state is not just those what you mention but could be anything On 9/26/07, Sam Hough [EMAIL PROTECTED] wrote: Eelco, Meant to say we have our first case where we want a component to update because the model has changed. It is a field that only gets updated on the server not directly through an HTML form... Since it is only one so far a hand coded Dirty.mark(this) is not too evil. Sorry, talking to myself again. -- View this message in context: http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12899100 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12917688 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Clustering Question - Can the 2nd Level Page Cache be shared in a clustered filesystem configuration?
Why don't you want session sticky load balancing? How does none sticky sessions work then? If there are 2 request comming in then wicket makes sure that the page is access in one thread. So that the page is not changed by 2 threads at the same time Does your application server lock over the nodes when there are 2 or more request comming in from the same client? If not how does it then sync up again? How does it merge the pages? johan On 9/28/07, mchack [EMAIL PROTECTED] wrote: I am deploying my application in a clustered environment. Eliminating session sticky load balancing would be an advantage for me. Session data is already replicated in a clustered environment. Are the mechanics in place to share the Page Cache with other machines if I use a clustered file system that allows concurrent access in this way providing non sticky LB across the cluster? -Mike -- View this message in context: http://www.nabble.com/Clustering-Question---Can-the-2nd-Level-Page-Cache-be-shared-in-a-clustered-filesystem-configuration--tf4531607.html#a12932067 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Clustering Question - Can the 2nd Level Page Cache be shared in a clustered filesystem configuration?
Serialize to the session is a completely wrong statement Nothing is serialized into the session, it is put in the session. and then the application server can serialize the session to other nodes or to disk or what ever. If you have an standard app server and you don't have multiply nodes and you don't restart the server then normally the pages are never serialized that are kept in the session We do serialize the pages besides the session. And matej made some optimizations that when the server does cluster (serialize) that the page is only serialized once and it tries to reuse that byte instance. johan On 9/28/07, mchack [EMAIL PROTECTED] wrote: I am not sure I understand correctly. :) I thought the current page was serialized to the session and that the other pages or views were stored to the filesystem. So my question was really, if the filesystem where temporary pages are stored is shared, would Wicket be immune to requests coming in to random servers in the cluster. I was hoping that it might be possible to do a dumb load balancing arrangement. I am not totally clear on the whole page lifecycle, so hopefully my question is not completely out in left field. -Mike Matej Knopp-2 wrote: Hi, if I understand correctly, you want to disable page serialization on session replication, as the filesystem where the page store stores temporary pages is accessible from each node in cluster? There is a way to achieve it, just create your own page store extending from DiskPageStore and make it implement the SecondLevelCacheSessionStore.IClusteredPageStore interface. Just implementing this interface will cause that the last accessed page will not be replicated across cluster. -Matej -- View this message in context: http://www.nabble.com/Clustering-Question---Can-the-2nd-Level-Page-Cache-be-shared-in-a-clustered-filesystem-configuration--tf4531607.html#a12933068 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: auto dirty and widget factory
as i said before removing those files will not really help you the current change tracker/listener we have is the way to go. We just need to refactor it a little bit and create an extra method where people can hook up in. johan On 9/28/07, Sam Hough [EMAIL PROTECTED] wrote: The nicest way I can think of to solve: http://www.nabble.com/Reach-into-a-component-to-change-XML-attribute-tf4527906.html Would be to override add, removeAll, remove etc to manage AttributeModifier when the children change rather than every time the components render etc... So I'm not being won over by the final thing since I'd like them gone for my auto-dirty, first/last class attribute and so I can keep using onClick and onSubmit... If I'm hitting an imaginery brick wall then I'd be delighted to be shown the light. Cheers Sam Eelco Hillenius wrote: On 9/26/07, Johan Compagner [EMAIL PROTECTED] wrote: but this discussion is not just about getter/setters (i don't care about those) but also for add and remove.. then we are getting into some other stuff Yes. Getters/ setters are less tricky. Though I'm still not breaking in sweat when I imagine removing final on add and remove. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12940572 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: auto dirty and widget factory
yes we do we use it still extensively we dont cache the changes anymore those are gone, but we still uses it to bump up the versions else how can we do that? johan On 9/29/07, Matej Knopp [EMAIL PROTECTED] wrote: On 9/27/07, Johan Compagner [EMAIL PROTECTED] wrote: the problem is that that still not really does auto dirty.. Because where does it end? just add/remove/visitble/enable? The nice thing is we have already something like that: thats page versioning with the undo/change map. Don't get too attached to it :) We should remove it in the next version, doesn't make much sense for 2nd level cache session store :) -Matej If we extend that a little bit then we could have something like componentChanged(component) on a page (or somekind of listener) and that component did trigger it self what ever did happen on it (getting a child, settting the visibility, or setting an internal none wicket core property) johan On 9/26/07, Eelco Hillenius [EMAIL PROTECTED] wrote: On 9/26/07, Johan Compagner [EMAIL PROTECTED] wrote: but this discussion is not just about getter/setters (i don't care about those) but also for add and remove.. then we are getting into some other stuff Yes. Getters/ setters are less tricky. Though I'm still not breaking in sweat when I imagine removing final on add and remove. 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: auto dirty and widget factory
but then still we have the event..
johan
On 9/29/07, Matej Knopp [EMAIL PROTECTED] wrote:
newVersion();
looks much better to me than addStateChange(new
ChangeThatIsNotUsedAnyway() { public void undo() });
-Matej
On 9/29/07, Johan Compagner [EMAIL PROTECTED] wrote:
yes we do
we use it still extensively
we dont cache the changes anymore those are gone, but we still uses it
to
bump up the versions
else how can we do that?
johan
On 9/29/07, Matej Knopp [EMAIL PROTECTED] wrote:
On 9/27/07, Johan Compagner [EMAIL PROTECTED] wrote:
the problem is that that still not really does auto dirty..
Because where does it end? just add/remove/visitble/enable?
The nice thing is we have already something like that: thats page
versioning
with the undo/change map.
Don't get too attached to it :) We should remove it in the next
version, doesn't make much sense for 2nd level cache session store :)
-Matej
If we extend that a little bit then we could have something like
componentChanged(component) on a page (or somekind of listener)
and that component did trigger it self what ever did happen on it
(getting a
child, settting the visibility, or setting an internal none wicket
core
property)
johan
On 9/26/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
On 9/26/07, Johan Compagner [EMAIL PROTECTED] wrote:
but this discussion is not just about getter/setters (i don't
care
about
those)
but also for add and remove.. then we are getting into some
other
stuff
Yes. Getters/ setters are less tricky. Though I'm still not
breaking
in sweat when I imagine removing final on add and remove.
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: auto dirty and widget factory
i have told you now i think at least 3 times only be able to override those methods WONT i repeat again WONT help you completely those are not the only events that could get a component to be dirty. there are lots more especially when you also take into account the none core stuff. Something like the change tracker is the way to go. johan On 9/29/07, Sam Hough [EMAIL PROTECTED] wrote: Errr. Should I take from all this not to use the page versioning and that I shouldn't hold my breath for final being removed from anywhere? I know you are all sick of this topic, poor old Eelco, but seems like a simple, efficient and flexible way for me to add hooks is to extend objects. If you mark methods as extend at own risk and I go down a stupid route that is my own stupidity. At least I can get something reasonable working in the short term even if it can be done better later. I'm a good boy so I have lots of unit and functional tests to catch mistakes later. Sorry that I'm struggling with the wicket way. To add to my confusion I'd rather onClick, onSubmit etc were interfaces so I could choose if I wanted them in the component (to reduce numbers of objects) or anywhere I like. Matej Knopp-2 wrote: On 9/27/07, Johan Compagner [EMAIL PROTECTED] wrote: the problem is that that still not really does auto dirty.. Because where does it end? just add/remove/visitble/enable? The nice thing is we have already something like that: thats page versioning with the undo/change map. Don't get too attached to it :) We should remove it in the next version, doesn't make much sense for 2nd level cache session store :) -Matej If we extend that a little bit then we could have something like componentChanged(component) on a page (or somekind of listener) and that component did trigger it self what ever did happen on it (getting a child, settting the visibility, or setting an internal none wicket core property) johan On 9/26/07, Eelco Hillenius [EMAIL PROTECTED] wrote: On 9/26/07, Johan Compagner [EMAIL PROTECTED] wrote: but this discussion is not just about getter/setters (i don't care about those) but also for add and remove.. then we are getting into some other stuff Yes. Getters/ setters are less tricky. Though I'm still not breaking in sweat when I imagine removing final on add and remove. 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] -- View this message in context: http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12954673 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: auto dirty and widget factory
And then dirty bumps up the version number?
again VersionManager is still used extensively even with the slc
It takes care of the version numbers (normal and ajax)
so if you have page.dirty() which contracts is now update in the session
then we also suddenly bump up the version number??
of course component.setVersioned() can't be ditched because developers
should be able to disable versioning (backbutton support) for a page
johan
On 9/29/07, Matej Knopp [EMAIL PROTECTED] wrote:
On 9/29/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
yeah, so we keep the actual core events we support in the interface,
like
oncomponentadded(component) but remove all the Change objects.
when a user changes the property they then have to call dirty();
personally
i think we can just serialize every time and not require the user to
call
dirty() just assume it is after every request. not sure how wasteful
that
is...maybe if the user sets a different response page we assume the
previous
page is not dirty unless dirty() was called explicitly...
Yeah, that's a good point. Current state is as if dirty() was called
every request. I think if anyone needs to tune this, we should provide
way of marking page not dirty, which people who really have lot of
small request that don't do anything (e.g. polling) could use. I
remember doing such thing for thoof to suppress page serialization for
ajax polling, but that was rather trivial to do.
-Matej
-igor
On 9/28/07, Johan Compagner [EMAIL PROTECTED] wrote:
but then still we have the event..
johan
On 9/29/07, Matej Knopp [EMAIL PROTECTED] wrote:
newVersion();
looks much better to me than addStateChange(new
ChangeThatIsNotUsedAnyway() { public void undo() });
-Matej
On 9/29/07, Johan Compagner [EMAIL PROTECTED] wrote:
yes we do
we use it still extensively
we dont cache the changes anymore those are gone, but we still
uses it
to
bump up the versions
else how can we do that?
johan
On 9/29/07, Matej Knopp [EMAIL PROTECTED] wrote:
On 9/27/07, Johan Compagner [EMAIL PROTECTED] wrote:
the problem is that that still not really does auto dirty..
Because where does it end? just add/remove/visitble/enable?
The nice thing is we have already something like that: thats
page
versioning
with the undo/change map.
Don't get too attached to it :) We should remove it in the next
version, doesn't make much sense for 2nd level cache session
store
:)
-Matej
If we extend that a little bit then we could have something
like
componentChanged(component) on a page (or somekind of
listener)
and that component did trigger it self what ever did happen on
it
(getting a
child, settting the visibility, or setting an internal none
wicket
core
property)
johan
On 9/26/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
On 9/26/07, Johan Compagner [EMAIL PROTECTED] wrote:
but this discussion is not just about getter/setters (i
don't
care
about
those)
but also for add and remove.. then we are getting into
some
other
stuff
Yes. Getters/ setters are less tricky. Though I'm still not
breaking
in sweat when I imagine removing final on add and remove.
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]
-
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: auto dirty and widget factory
i think thatwe will change the interface of the change tracker but we will keep it at some level for page versions (and abusing dirty() for that doesn't have my vote) But something like: Page.componentChanged(Component) looks nice to me and then auto dirty of components is also possible On 9/29/07, Martijn Dashorst [EMAIL PROTECTED] wrote: The jury is still out on the change tracker. It will at least be part of Wicket 1.3 and our JDK 1.5 release, as that one should only be about generics (at least that is still the plan). So it will be there for at least 1.3 and the next one. If your application is still dependent on that functionality, then raise the concern when we are going to remove it. If we have usecases for a particular functionality, then we are not going to remove it on a whim. According to this thread, at least Johan is quite keen to keep it in place :) Please note also that maybe in the version after the generics version, we may come up with a way to do what you want, and provide that functionality out-of-the-box. But currently we are trying to finalize a release and ship it. Martijn On 9/29/07, Sam Hough [EMAIL PROTECTED] wrote: I would be happy with a 90% solution that was very simple and that was what I was after. Something like the change tracker would be lovely but it seems in doubt if that will even exist for long. I won't raise this issue again. Thanks for your time. Johan Compagner wrote: i have told you now i think at least 3 times only be able to override those methods WONT i repeat again WONT help you completely those are not the only events that could get a component to be dirty. there are lots more especially when you also take into account the none core stuff. Something like the change tracker is the way to go. johan On 9/29/07, Sam Hough [EMAIL PROTECTED] wrote: Errr. Should I take from all this not to use the page versioning and that I shouldn't hold my breath for final being removed from anywhere? I know you are all sick of this topic, poor old Eelco, but seems like a simple, efficient and flexible way for me to add hooks is to extend objects. If you mark methods as extend at own risk and I go down a stupid route that is my own stupidity. At least I can get something reasonable working in the short term even if it can be done better later. I'm a good boy so I have lots of unit and functional tests to catch mistakes later. Sorry that I'm struggling with the wicket way. To add to my confusion I'd rather onClick, onSubmit etc were interfaces so I could choose if I wanted them in the component (to reduce numbers of objects) or anywhere I like. Matej Knopp-2 wrote: On 9/27/07, Johan Compagner [EMAIL PROTECTED] wrote: the problem is that that still not really does auto dirty.. Because where does it end? just add/remove/visitble/enable? The nice thing is we have already something like that: thats page versioning with the undo/change map. Don't get too attached to it :) We should remove it in the next version, doesn't make much sense for 2nd level cache session store :) -Matej If we extend that a little bit then we could have something like componentChanged(component) on a page (or somekind of listener) and that component did trigger it self what ever did happen on it (getting a child, settting the visibility, or setting an internal none wicket core property) johan On 9/26/07, Eelco Hillenius [EMAIL PROTECTED] wrote: On 9/26/07, Johan Compagner [EMAIL PROTECTED] wrote: but this discussion is not just about getter/setters (i don't care about those) but also for add and remove.. then we are getting into some other stuff Yes. Getters/ setters are less tricky. Though I'm still not breaking in sweat when I imagine removing final on add and remove. 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] -- View this message in context: http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12954673 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12955648 Sent from the Wicket - User mailing list
Re: substitute same value in several places
look at BoundedCompoundPropertyModel (i could type the name a bit
wrong, cant check at this time) With that you can do something like:
label1.setmodel(bcpm.bind('key') and do the samething for label2
On 9/27/07, Peter Dotchev [EMAIL PROTECTED] wrote:
Hi,
I'd like to use the same value in several places of a page, e.g. two labels
with same content.
Let's say I want to substitute the same property using
CompoundPropertyModel.
How can I do that in Wicket 1.3?
Thanks for your help.
Peter
--
View this message in context:
http://www.nabble.com/substitute-same-value-in-several-places-tf4530268.html#a12927782
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: Presented Wicket to my Company...
nicely said! could be adde to our webpage/wiki! On 9/29/07, Ryan Holmes [EMAIL PROTECTED] wrote: 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
Re: Wicket Meetup Amsterdam: a proposal
i also have been asking around for a big room. And Servoy is willing to sponser a big room if needed (if there are really comming 30+ people) The problem is that the coming 2 weeks i can't do much about it because first we (servoy) has its own conference next week (servoy world) johan On 10/1/07, Arje Cahn [EMAIL PROTECTED] wrote: Hi all, Since it's been a bit quiet about the Amsterdam Meetup lately, I was thinking of simply proposing a date and a venue myself. Maybe I missed out on the conversation, in which case I apologize upfront! By no means I'm trying to push this into a 'real conference' - these things grow over years! But I do like to see this Meetup happen, because: - I think it would be good to get 'The People Behind Wicket' on stage, while allowing 'New People' to have their say as well, in an informal setting - It's a good way of attracting non-incrowd people - The ApacheCons and similar conferences have a too high barrier for people that are interested in Wicket but do not know how to start. Of course, the ApacheCon conference is an excellent way of broadening ones vision, but for non-Apache people it's hard to dive into - People who have not yet decided whether they want to use Wicket, could be held back by a 'private' meetup. These people do not know the community, and don't know what to expect. A more 'anonymous' (ie. bigger) meetup could help lower the barrier and bring in new developers - We need to close the gap between users and developers, and having them all in one room helps - Too many little meetups shatter the community instead of building it up - It's an excellent environment to grow a network and a community - There's already 28 people on the Wiki page, and this might grow even further - Organizing the meetup in a 'neutral' environment ensures the community stays neutral too - And finally: it should be initiated, supported and organized by the community itself Covering the costs of such a meetup doesn't have to be hard. For the Cocoon GetTogether meetups, there's a 125 euro fee for three (3!) whole days. We do have some sponsors over there to cover for lunches and coffee and connectivity. If we allow sponsors for a Wicket meetup, I guess a one day event could easily be free for all attendees. On the other hand, if sponsors are a concern, then we could have all costs covered by a 50 euro fee or something. The Apache Cocoon community has had a really good experience with Amsterdam as a venue location. It's very well-reachable from all around the world, and pretty affordable too. Just to have something realistic to talk about - I apologize if I'm moving too fast here - I've called the Felix Meritis building to ask which rooms are available (and affordable!). The room can hold up to 50 people sitting at tables (with laptop and all), but we can scale up to 200 if we want :) These dates would fit their schedule: Friday November 23rd Monday November 26th Friday November 30th Please note that these are weekdays. We could also try weekends if that's better. We could also try combining this with a course from the London guys.. Let me know what others think! Kind regards, Arjé Cahn Hippo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session size is constantly increasing on setResponsePage(getPage())
are you talking about 1.2 or 1.3?
in 1.2 a session could grow a little bit because we have there max 7 pages
that all also can contain some version info.
But as you said when you do setResponsePage(Page.class) everything drops to
normal
that means that you have to use 1.3 because then the newly created page
replaces the old one in the session memory.
But if you set in the link click the same page that the link is on
(setResponsePage(getPage()). You see a grow?
That seems a bit strange. need to check that out then.
johan
On 10/2/07, Martin2 [EMAIL PROTECTED] wrote:
Hi there,
we're developing a rather straight forward application with wicket and I
am
wondering if it is ok to call setResponsePage(getPage()) inside the
onClick() method of a Link? Because the session size is constantly
increasing, here's my example:
Application class:
public class TestApplication extends WebApplication {
public TestApplication() {
super();
}
@Override
public Class getHomePage() {
return TestPage.class;
}
@Override
protected void init() {
super.init();
mountBookmarkablePage(/home, getHomePage());
}
}
Page class:
public class TestPage extends WebPage {
public TestPage() {
super();
setVersioned(false);
add(new TestLink(testLink));
}
@Override
protected void onBeforeRender() {
super.onBeforeRender();
System.err.println(getSession().getSizeInBytes());
}
}
Link class:
public class TestLink extends Link {
public TestLink(String id) {
super(id);
}
@Override
public void onClick() {
setResponsePage(getPage());
}
}
Everytime the Link is clicked the session size increases a bit (it may be
tiny in this test application, it's nevertheless increasing constantly).
Whenever (this clue comes from testing our real application) a new page is
constructed (be it via setResponsePage(Page.class) or via url) the session
size falls back to normal. When an older instance (via back button or
link)
is used, the session is as big as before.
I also noticed that when using TabbedPanel (from wicket-extensions) each
tab
change (out of the box) increases the session size much more.
All our models are LoadableDetachableModels, so our model objects are all
transient and should never be stored in the session. Of course we use here
and there a new PropertyModel() and other wrapper models, but only in
constructors.
Any suggestion what we could do about it? In the real application the
increment is about 2-3Kb per click, which will become a problem since the
application is click-intensive and collaborative (many session at the same
time).
Thanks in advance,
Martin
--
View this message in context:
http://www.nabble.com/Session-size-is-constantly-increasing-on-setResponsePage%28getPage%28%29%29-tf4556781.html#a13004735
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session size is constantly increasing on setResponsePage(getPage())
ok found it, We are leaking auto add html header containers.
Looking to fix it.
On 10/3/07, Johan Compagner [EMAIL PROTECTED] wrote:
are you talking about 1.2 or 1.3?
in 1.2 a session could grow a little bit because we have there max 7 pages
that all also can contain some version info.
But as you said when you do setResponsePage(Page.class) everything drops
to normal
that means that you have to use 1.3 because then the newly created page
replaces the old one in the session memory.
But if you set in the link click the same page that the link is on
(setResponsePage(getPage()). You see a grow?
That seems a bit strange. need to check that out then.
johan
On 10/2/07, Martin2 [EMAIL PROTECTED] wrote:
Hi there,
we're developing a rather straight forward application with wicket and I
am
wondering if it is ok to call setResponsePage(getPage()) inside the
onClick() method of a Link? Because the session size is constantly
increasing, here's my example:
Application class:
public class TestApplication extends WebApplication {
public TestApplication() {
super();
}
@Override
public Class getHomePage() {
return TestPage.class;
}
@Override
protected void init() {
super.init();
mountBookmarkablePage(/home, getHomePage());
}
}
Page class:
public class TestPage extends WebPage {
public TestPage() {
super();
setVersioned(false);
add(new TestLink(testLink));
}
@Override
protected void onBeforeRender() {
super.onBeforeRender();
System.err.println(getSession().getSizeInBytes());
}
}
Link class:
public class TestLink extends Link {
public TestLink(String id) {
super(id);
}
@Override
public void onClick() {
setResponsePage(getPage());
}
}
Everytime the Link is clicked the session size increases a bit (it may
be
tiny in this test application, it's nevertheless increasing constantly).
Whenever (this clue comes from testing our real application) a new page
is
constructed (be it via setResponsePage(Page.class) or via url) the
session
size falls back to normal. When an older instance (via back button or
link)
is used, the session is as big as before.
I also noticed that when using TabbedPanel (from wicket-extensions) each
tab
change (out of the box) increases the session size much more.
All our models are LoadableDetachableModels, so our model objects are
all
transient and should never be stored in the session. Of course we use
here
and there a new PropertyModel() and other wrapper models, but only in
constructors.
Any suggestion what we could do about it? In the real application the
increment is about 2-3Kb per click, which will become a problem since
the
application is click-intensive and collaborative (many session at the
same
time).
Thanks in advance,
Martin
--
View this message in context:
http://www.nabble.com/Session-size-is-constantly-increasing-on-setResponsePage%28getPage%28%29%29-tf4556781.html#a13004735
Sent from the Wicket - User mailing list archive at
Nabble.comhttp://nabble.com/
.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session size is constantly increasing on setResponsePage(getPage())
jip, but open and close a jira if you want to have this in the change list..
On 10/3/07, Gerolf Seitz [EMAIL PROTECTED] wrote:
i think johan already fixed it in trunk.
gerolf
On 10/3/07, Martin2 [EMAIL PROTECTED] wrote:
Hi,
thanks for the quick response. Should I open a JIRA issue for this or is
it
to minor to justify the overhead?
bw,
Martin
Johan Compagner wrote:
ok found it, We are leaking auto add html header containers.
Looking to fix it.
On 10/3/07, Johan Compagner [EMAIL PROTECTED] wrote:
are you talking about 1.2 or 1.3?
in 1.2 a session could grow a little bit because we have there max 7
pages
that all also can contain some version info.
But as you said when you do setResponsePage(Page.class) everything
drops
to normal
that means that you have to use 1.3 because then the newly created
page
replaces the old one in the session memory.
But if you set in the link click the same page that the link is on
(setResponsePage(getPage()). You see a grow?
That seems a bit strange. need to check that out then.
johan
On 10/2/07, Martin2 [EMAIL PROTECTED] wrote:
Hi there,
we're developing a rather straight forward application with wicket
and
I
am
wondering if it is ok to call setResponsePage(getPage()) inside the
onClick() method of a Link? Because the session size is constantly
increasing, here's my example:
Application class:
public class TestApplication extends WebApplication {
public TestApplication() {
super();
}
@Override
public Class getHomePage() {
return TestPage.class;
}
@Override
protected void init() {
super.init();
mountBookmarkablePage(/home, getHomePage());
}
}
Page class:
public class TestPage extends WebPage {
public TestPage() {
super();
setVersioned(false);
add(new TestLink(testLink));
}
@Override
protected void onBeforeRender() {
super.onBeforeRender();
System.err.println(getSession().getSizeInBytes());
}
}
Link class:
public class TestLink extends Link {
public TestLink(String id) {
super(id);
}
@Override
public void onClick() {
setResponsePage(getPage());
}
}
Everytime the Link is clicked the session size increases a bit (it
may
be
tiny in this test application, it's nevertheless increasing
constantly).
Whenever (this clue comes from testing our real application) a new
page
is
constructed (be it via setResponsePage(Page.class) or via url) the
session
size falls back to normal. When an older instance (via back button
or
link)
is used, the session is as big as before.
I also noticed that when using TabbedPanel (from wicket-extensions)
each
tab
change (out of the box) increases the session size much more.
All our models are LoadableDetachableModels, so our model objects
are
all
transient and should never be stored in the session. Of course we
use
here
and there a new PropertyModel() and other wrapper models, but only
in
constructors.
Any suggestion what we could do about it? In the real application
the
increment is about 2-3Kb per click, which will become a problem
since
the
application is click-intensive and collaborative (many session at
the
same
time).
Thanks in advance,
Martin
--
View this message in context:
http://www.nabble.com/Session-size-is-constantly-increasing-on-setResponsePage%28getPage%28%29%29-tf4556781.html#a13004735
Sent from the Wicket - User mailing list archive at
Nabble.comhttp://nabble.com/
.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/Session-size-is-constantly-increasing-on-setResponsePage%28getPage%28%29%29-tf4556781.html#a13018499
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: webpage instance scope?
pages are stored in the session (if they are statefull, that means they have callbacks) A stateless page could maybe been seen as a request scope object. there is no such thing as a combination of those 2. johan On 10/3/07, dukehoops [EMAIL PROTECTED] wrote: Hi, I'm evaluating Wicket as a potential replacement for JSF and have a question (tried searching, read wiki): What is the lifespan of a WebPage / Panel subclass instance? In JSF, page-backing beans can be request/session/app scoped. I read that Wicket is an unmanaged framework. Does that mean the objects are request-scoped? If so, how how does one implement a session-persistent header (as Panel) + request-scoped body scenario? If this is documented in reference, please kindly point me to the specific section - I could not find anything relevant thanks -nikita -- View this message in context: http://www.nabble.com/webpage-instance-scope--tf4564224.html#a13027317 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
