Re: Passing the component that is checked to IRoleCheckingStrategy.hasAnyRole()
Hi Bart, You can study the wicket-auth-roles project to see how you can use authorization based on roles. Wicket-auth-roles does this at the component level. Better yet, this (still incomplete but useable) wiki page shows you how to integrate Acegi with Wicket: http://cwiki.apache.org/WICKET/acegi-and-wicket-auth-roles.html. Regards, Erik. Bart Molenkamp wrote: Hi, In IRoleCheckingStrategy, the method hasAnyRole() only gets a collection of roles to check against. Would it be possible to pass the component that is checked as well? I'm trying to integrate Wicket with Acegi security, and I want to let Acegi's AccessDecisionManager check if the instantiation or action is authorized or not. But I need to pass the 'secured object', which is the component in my case. I can provide a patch, if anyone wants it. Thanks, Bart. -- Erik van Oosten http://2008.rubyenrails.nl/ http://day-to-day-stuff.blogspot.com/ -- View this message in context: http://www.nabble.com/Passing-the-component-that-is-checked-to-IRoleCheckingStrategy.hasAnyRole%28%29-tf4108563.html#a11696777 Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: 1.3 release/graduation schema
Bruno, You can get snapshots from the maven snapshot repository at http://wicketstuff.org/maven/repository. Erik. Bruno Borges schreef: Martijn, isn't possible to release as an Early Access ? :) []'s! -- Erik van Oosten http://2007.rubyenrails.nl/ http://www.day-to-day-stuff.blogspot.com/
Bamboo Trunk build
Hi, The wiki page http://cwiki.apache.org/confluence/display/WICKET/Wicket+from+source says that you can find the latest snapshots on http://wicketstuff.org/maven/repository/wicket/wicket/. There is no such build for the trunk. Will this be added? Regards, Erik. -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/
Re: Bamboo Trunk build
Oosp, I found it at http://wicketstuff.org/maven/repository/org/apache/wicket/wicket/! Of course, the groupid changed. Have fun, Erik. Hi, The wiki page http://cwiki.apache.org/confluence/display/WICKET/Wicket+from+source says that you can find the latest snapshots on http://wicketstuff.org/maven/repository/wicket/wicket/. There is no such build for the trunk. Will this be added? Regards, Erik. -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/
Re: Bamboo Trunk build
No no, the wiki is fine, it is just located in another sub-directory! fix wiki! :) On 5/4/07, Erik van Oosten [EMAIL PROTECTED] wrote: Oosp, I found it at http://wicketstuff.org/maven/repository/org/apache/wicket/wicket/! Of course, the groupid changed. Hi, The wiki page http://cwiki.apache.org/confluence/display/WICKET/Wicket+from+sourcesays that you can find the latest snapshots on http://wicketstuff.org/maven/repository/wicket/wicket/. There is no such build for the trunk. Will this be added? -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/
Re: Bean properties
Petr, In what way do you think it might be useful? Personally, I think that interoperability between bean-properties and existing code would be more cumbersome then staying with getters/setters. Regards, Erik. Petr Sakar wrote: Can be of some use for wicket ? http://www.theserverside.com/news/thread.tss?thread_id=44804 https://bean-properties.dev.java.net/ saki -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/
Re: [VOTE] All examples in one project, Java 5 required
(non-binding) [ ] No, I object! Java 1.4 examples are the thing I live and die for [x] Yes, make one examples project to rule them all, and by all means, make it Java 1.5 dependent -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/
Re: wicket modules
Forgive me if I am wrong, but I thought that unknown annotations must be ignored by the Java compiler. If not, I stand corrected. About logging: there is usually too much logging already. Logging is mostly useful for negative messages. Extracting more information from a log takes the hours I was talking about. :( Debugging is more effective most of the time. Regards, Erik. Igor Vaynberg wrote: all these cons are invalid you would also get class not found on the annotations like @SpringBean and a log message tells you what modules have been initialized :) -igor -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/
Re: wicket modules
Hi Igor, Jonathan, Good idea, I have never liked the way I had to inherit from the application base classes. From a users point of view, I agree with Jonathan on the config thing, I'd rather have one line of code somewhere (on a predictable place, e.g. application#init). This also makes it immediately clear when it does not work: you get a classnotfoundexception. When it is implicit you can search for hours before you realize that a jar is missing. Especially when you are talking about annotations. Regards, Erik. Jonathan Locke wrote: I like the idea of snap-in modules of some sort, but I don't completely understand what you're talking about here and I'm not sure I agree with what all of what I do get. -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/
Re: Commits on 1.2.x?
Hi, Is there a JIRA issue already? I released a Wicket app based on a pre-1.2.5 release 2 weeks ago. I would like to know whether we need to create an update after 1.2.6 is out. Regards, Erik. Johan Compagner wrote: Yesterday i just fixed the AccessStackPageMap in 1.3 (that is the one used in 1.2) there is a bug in it that it leaks pages into the session under specific circumstances so maybe a 1.2.6? johan -- Erik van Oosten http://day-to-day-stuff.blogspot.com/
Re: VOTE: add Joda time as a dependency
It is so big because it contains a snapshot of the tz database. Regards, Erik. Johan Compagner wrote: why is it so big? complete wicket is 1.5 so only some date manipulations are 1/3th? johan -- Erik van Oosten http://day-to-day-stuff.blogspot.com/
Re: Packaging our releases
Hi Igor, Actually, I do use maven. I just have lots of bad experiences with it. Including it screwing up my eclipse config files. I don't like it when I have to read a whole book for something simple as building (well, perhaps it is not so simple anymore :( ). - do we need to supply all dependencies in the source and/or binary distribution You could make it optional. Spring does this and at times I have found this very convenient. Just an option. If is too much effort, the wicket core will suffer. So in that case, I could not care less :) Building the src jars is another matter. Not everybody can/will do so. Regards, Erik. Igor Vaynberg wrote: fine. you dont use maven, but we do. why should we spend extra time packaging things in a zip, blah, blah when they are easily available to you from the maven repo? http://wicketstuff.org/maven/repository/org/apache/wicket/wicket/1.3-incubating-SNAPSHOT/ http://mirrors.ibiblio.org/pub/mirrors/maven2/wicket/wicket/1.2.4/ rather then downloading a zip that has everything, just download the parts that you need -igor -- Erik van Oosten http://day-to-day-stuff.blogspot.com/
Comments in markup sometimes throw weird exceptions
(Ljava.lang.String;Ljava.lang.String;Lorg.mortbay.http.HttpRequest;Lorg.mortbay.http.HttpResponse;)Z(HttpContext.java:1807) at org.mortbay.jetty.servlet.WebApplicationContext.handle(Ljava.lang.String;Ljava.lang.String;Lorg.mortbay.http.HttpRequest;Lorg.mortbay.http.HttpResponse;)Z(WebApplicationContext.java:525) at org.mortbay.http.HttpContext.handle(Lorg.mortbay.http.HttpRequest;Lorg.mortbay.http.HttpResponse;)Z(HttpContext.java:1757) at org.mortbay.http.HttpServer.service(Lorg.mortbay.http.HttpRequest;Lorg.mortbay.http.HttpResponse;)Lorg.mortbay.http.HttpContext;(HttpServer.java:879) at org.mortbay.http.HttpConnection.service(Lorg.mortbay.http.HttpRequest;Lorg.mortbay.http.HttpResponse;)Lorg.mortbay.http.HttpContext;(HttpConnection.java:789) Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: -1 at java.lang.String.substring(II)Ljava.lang.String;(Unknown Source) at java.lang.String.substring(I)Ljava.lang.String;(Unknown Source) at wicket.markup.MarkupParser.removeComment(Ljava.lang.String;)Ljava.lang.String;(MarkupParser.java:391) at wicket.markup.MarkupParser.parseMarkup()V(MarkupParser.java:278) at wicket.markup.MarkupParser.readAndParse(Lwicket.markup.MarkupResourceStream;)Lwicket.markup.Markup;(MarkupParser.java:200) at wicket.markup.MarkupCache.loadMarkup(Lwicket.MarkupContainer;Ljava.lang.CharSequence;Lwicket.markup.MarkupResourceStream;)Lwicket.markup.Markup;(MarkupCache.java:279) at wicket.markup.MarkupCache.loadMarkupAndWatchForChanges(Lwicket.MarkupContainer;Ljava.lang.CharSequence;Lwicket.markup.MarkupResourceStream;)Lwicket.markup.Markup;(MarkupCache.java:354) at wicket.markup.MarkupCache.getMarkup(Lwicket.MarkupContainer;Ljava.lang.Class;)Lwicket.markup.Markup;(MarkupCache.java:198) at wicket.markup.MarkupCache.getMarkupStream(Lwicket.MarkupContainer;Z)Lwicket.markup.MarkupStream;(MarkupCache.java:106) at wicket.MarkupContainer.getAssociatedMarkupStream(Z)Lwicket.markup.MarkupStream;(MarkupContainer.java:827) at wicket.MarkupContainer.renderAssociatedMarkup(Ljava.lang.String;Ljava.lang.String;)V(MarkupContainer.java:550) at wicket.markup.html.panel.Panel.onComponentTagBody(Lwicket.markup.MarkupStream;Lwicket.markup.ComponentTag;)V(Panel.java:108) at wicket.Component.renderComponent(Lwicket.markup.MarkupStream;)V(Component.java:1712) at wicket.MarkupContainer.onRender(Lwicket.markup.MarkupStream;)V(MarkupContainer.java:927) at wicket.Component.render(Lwicket.markup.MarkupStream;)V(Component.java:1526) at wicket.Component.renderComponent()V(Component.java:1650) at wicket.ajax.AjaxRequestTarget.respondComponent(Lwicket.Response;Ljava.lang.String;Lwicket.Component;)V(AjaxRequestTarget.java:474) at wicket.ajax.AjaxRequestTarget.respond(Lwicket.RequestCycle;)V(AjaxRequestTarget.java:361) at wicket.request.compound.DefaultResponseStrategy.respond(Lwicket.RequestCycle;)V(DefaultResponseStrategy.java:49) at wicket.request.compound.AbstractCompoundRequestCycleProcessor.respond(Lwicket.RequestCycle;)V(AbstractCompoundRequestCycleProcessor.java:66) at wicket.RequestCycle.doProcessEventsAndRespond(Lwicket.request.IRequestCycleProcessor;)V(RequestCycle.java:902) at wicket.RequestCycle.processEventsAndRespond()V(RequestCycle.java:934) at wicket.RequestCycle.step()V(RequestCycle.java:1010) at wicket.RequestCycle.steps()V(RequestCycle.java:1084) at wicket.RequestCycle.request()V(RequestCycle.java:454) at wicket.protocol.http.WicketServlet.doGet(Ljavax.servlet.http.HttpServletRequest;Ljavax.servlet.http.HttpServletResponse;)V(WicketServlet.java:219) at wicket.protocol.http.WicketServlet.doPost(Ljavax.servlet.http.HttpServletRequest;Ljavax.servlet.http.HttpServletResponse;)V(WicketServlet.java:262) at javax.servlet.http.HttpServlet.service(Ljavax.servlet.http.HttpServletRequest;Ljavax.servlet.http.HttpServletResponse;)V(HttpServlet.java:760) at javax.servlet.http.HttpServlet.service(Ljavax.servlet.ServletRequest;Ljavax.servlet.ServletResponse;)V(HttpServlet.java:853) at org.mortbay.jetty.servlet.ServletHolder.handle(Ljavax.servlet.ServletRequest;Ljavax.servlet.ServletResponse;)V(ServletHolder.java:358) at org.mortbay.jetty.servlet.WebApplicationHandler$Chain.doFilter(Ljavax.servlet.ServletRequest;Ljavax.servlet.ServletResponse;)V(WebApplicationHandler.java:342) at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(Ljavax.servlet.ServletRequest;Ljavax.servlet.ServletResponse;)V(FilterChainProxy.java:264) 8- -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/
Re: Comments in markup sometimes throw weird exceptions
Hi,
I found the problem already. I'll create a Jira issue with the solution.
Regards,
Erik.
Erik van Oosten wrote:
Hi,
Whenever I try to comment out parts of the markup I get weird
exceptions (attached below). I have tried to make a quick-start
application to reproduce this. But after trying very hard for at least
half an hour I could not create a case. Apparently, the exception only
occurs in complex situations.
Are there developers aware of this problem?
Regards,
Erik.
8-
ERROR - AjaxRequestTarget - Error while responding to an AJAX
request: [EMAIL PROTECTED] markupIdToComponent
[{maincontent_searchresult=[MarkupContainer [Component id =
searchresult, page = nl.amsterdam.rbrb.web.search.SearchPage, path =
2:maincontent:searchresult.WozSearchResult, isVisible = true,
isVersioned = false]], maincontent_searchform=[MarkupContainer
[Component id = searchform, page =
nl.amsterdam.rbrb.web.search.SearchPage, path =
2:maincontent:searchform.SearchPanel$1, isVisible = true, isVersioned
= false]]}], prependJavascript [[]], appendJavascript [[]]
wicket.WicketRuntimeException: Exception in rendering component:
[MarkupContainer [Component id = searchresult, page =
nl.amsterdam.rbrb.web.search.SearchPage, path =
2:maincontent:searchresult.WozSearchResult, isVisible = true,
isVersioned = false]]
at
wicket.Component.renderComponent(Lwicket.markup.MarkupStream;)V(Component.java:1739)
at
wicket.MarkupContainer.onRender(Lwicket.markup.MarkupStream;)V(MarkupContainer.java:927)
at
wicket.Component.render(Lwicket.markup.MarkupStream;)V(Component.java:1526)
at wicket.Component.renderComponent()V(Component.java:1650)
at
wicket.ajax.AjaxRequestTarget.respondComponent(Lwicket.Response;Ljava.lang.String;Lwicket.Component;)V(AjaxRequestTarget.java:474)
at
wicket.ajax.AjaxRequestTarget.respond(Lwicket.RequestCycle;)V(AjaxRequestTarget.java:361)
at
wicket.request.compound.DefaultResponseStrategy.respond(Lwicket.RequestCycle;)V(DefaultResponseStrategy.java:49)
at
wicket.request.compound.AbstractCompoundRequestCycleProcessor.respond(Lwicket.RequestCycle;)V(AbstractCompoundRequestCycleProcessor.java:66)
at
wicket.RequestCycle.doProcessEventsAndRespond(Lwicket.request.IRequestCycleProcessor;)V(RequestCycle.java:902)
at
wicket.RequestCycle.processEventsAndRespond()V(RequestCycle.java:934)
at wicket.RequestCycle.step()V(RequestCycle.java:1010)
at wicket.RequestCycle.steps()V(RequestCycle.java:1084)
at wicket.RequestCycle.request()V(RequestCycle.java:454)
at
wicket.protocol.http.WicketServlet.doGet(Ljavax.servlet.http.HttpServletRequest;Ljavax.servlet.http.HttpServletResponse;)V(WicketServlet.java:219)
at
wicket.protocol.http.WicketServlet.doPost(Ljavax.servlet.http.HttpServletRequest;Ljavax.servlet.http.HttpServletResponse;)V(WicketServlet.java:262)
at
javax.servlet.http.HttpServlet.service(Ljavax.servlet.http.HttpServletRequest;Ljavax.servlet.http.HttpServletResponse;)V(HttpServlet.java:760)
at
javax.servlet.http.HttpServlet.service(Ljavax.servlet.ServletRequest;Ljavax.servlet.ServletResponse;)V(HttpServlet.java:853)
at
org.mortbay.jetty.servlet.ServletHolder.handle(Ljavax.servlet.ServletRequest;Ljavax.servlet.ServletResponse;)V(ServletHolder.java:358)
at
org.mortbay.jetty.servlet.WebApplicationHandler$Chain.doFilter(Ljavax.servlet.ServletRequest;Ljavax.servlet.ServletResponse;)V(WebApplicationHandler.java:342)
at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(Ljavax.servlet.ServletRequest;Ljavax.servlet.ServletResponse;)V(FilterChainProxy.java:264)
at
org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(Ljavax.servlet.ServletRequest;Ljavax.servlet.ServletResponse;Ljavax.servlet.FilterChain;)V(HttpSessionContextIntegrationFilter.java:193)
at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(Ljavax.servlet.ServletRequest;Ljavax.servlet.ServletResponse;)V(FilterChainProxy.java:274)
at
org.acegisecurity.util.FilterChainProxy.doFilter(Ljavax.servlet.ServletRequest;Ljavax.servlet.ServletResponse;Ljavax.servlet.FilterChain;)V(FilterChainProxy.java:148)
at
org.acegisecurity.util.FilterToBeanProxy.doFilter(Ljavax.servlet.ServletRequest;Ljavax.servlet.ServletResponse;Ljavax.servlet.FilterChain;)V(FilterToBeanProxy.java:98)
at
org.mortbay.jetty.servlet.WebApplicationHandler$Chain.doFilter(Ljavax.servlet.ServletRequest;Ljavax.servlet.ServletResponse;)V(WebApplicationHandler.java:334)
at
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(Ljava.lang.String;Ljavax.servlet.http.HttpServletRequest;Ljavax.servlet.http.HttpServletResponse;Lorg.mortbay.jetty.servlet.ServletHolder;)V(WebApplicationHandler.java:286
Re: VOTE: include WICKET-218 in 1.2.5
+1 (non binding) Igor Vaynberg wrote: include https://issues.apache.org/jira/browse/WICKET-218 in 1.2.5 -igor
Re: hangman exception: attach
Hmm, that's weird. They do show up here. My Eclipse version is fairly new. Maybe you're using something oldish? Erik. Igor Vaynberg schreef: yes, and thats what ive been using - quick hierarchy (ctrl+t), but that doesnt show anon classes and doesnt work across projects reliably. -igor On 1/8/07, Erik van Oosten [EMAIL PROTECTED] wrote: Press Ctrl-T while the cursor is on a method definition, or press Ctrl-T twice when the cursor is on a method implementation. Another helpfull shortcut is Ctrl-Alt-H (Open Call Hierarchy). Have fun, Erik. Igor Vaynberg wrote: fixed, damn looks like eclipse' quick hierarchy doesnt support anonymous classes. is there a way to see all overrides of a method? -igor -- Erik van Oosten http://day-to-day-stuff.blogspot.com/
Re: Wicket and Backbase
Oskar, The BackBase language is XML right? So what you can do is give the BackBase elements a wicket:it attribute and attach components to it, just as would do with html tags. Regards, Erik. On 1/7/07, Toscano [EMAIL PROTECTED] wrote: Hello, I have been doing some testing for a very big project, and I have been seduced by Wicket. In the web interface side, we are considering Backbase, but although I could integrate easily simple controls like buttons, I don't know how to output the special html that backbase needs... Do I have to create specific wicket.markup.html components? Can anybody help me with how to face this? Thank you very much!, Oskar -- Erik van Oosten http://day-to-day-stuff.blogspot.com/
Re: hangman exception: attach
I am home now so I can't check it. Erik. Igor Vaynberg schreef: 3.2.1, you? -igor
Re: Wicket and Backbase
Perhaps it is time to read up on the examples. You can find these on http://wicketframework.org/ and http://cwiki.apache.org/WICKET/. Please ask further on the user list. This is the developers list. Eelco, BackBase uses a XUL syntax with things like windowstuff/window, these are read and converted by a javascript library on the client side. Another implementation that does this is ZK (http://www.zkoss.org/). Both BackBase and ZK have a live demo where you can enter the tags in your browser. Regards, Erik. Toscano wrote: Hello, Thank you very much for your responses. I understand what you want to say, but I'm afraid I don't know how to do it. My Wicket knowledge is poor yet, can you show me or redirect me to an example of this?. Again, thank you for your time! Oskar -- Erik van Oosten http://day-to-day-stuff.blogspot.com/
Re: FeedBackPanel
Hi tbt, Please repost on the wicket-user mailing list. This is the developers list. Erik. tbt wrote: I'm a newbie to wicket and would like to know how to add a customized icon near the error message thats generated by the feedback panel. Any help appreciated.
Re: Last change required for reloading classes
The ssl certificate of Jira has expired :) Erik. Jean-Baptiste Quenot wrote: Could you please decide where this feature goes and close https://issues.apache.org/jira/browse/WICKET-126 -- Erik van Oosten http://day-to-day-stuff.blogspot.com/
Re: wicket-examples compilation failure
Yes, the Eclipse and Sun compiler differ quite annoyingly in how they treat casts that have a generic component. Unfortunately this is not a setting. There are more differences. For example JRockit behaves weird around warnings for deprecated methods. Regards, Erik. Johan Compagner wrote: thx fix it. strange that compilers are that different. should be a setting then somewhere in eclipse. johan -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/
Re: Dinamically change header title
Hi Paolo, Just add(new Label(title, new title value)); Regards, Erik. Paolo Di Tommaso schreef: How to change an page header title? Is it possible to make something like this: wicket:head title wicket:id=title my dinamic title /title /wicket:head But how to map then in code? Or does exist another API method? Thank you, Paolo -- Erik van Oosten http://day-to-day-stuff.blogspot.com/
Re: [Wicket-user] Link#setEnabled( false ) does not disable button element
Hi Paolo, attempt-to-precise-semantics Actually, everything is uniform at this moment. The contract for Component#setEnabled says: * Sets whether this component is enabled. Specific components may decide to * implement special behavior that uses this property, like web form * components that add a disabled='disabled' attribute when enabled is * false. If it is not enabled, it will not be allowed to call any listener * method on it (e.g. Link.onClick) and the model object will be protected * (for the common use cases, not for programmer's misuse) Both Link and Button adhere to this contract. Furthermore Link and Button do not have an extends relation, otherwise the contract could be tightened by one of them. attempt-to-precise-semantics But I understand your point. Once you expect a component to render differently when it is not enabled, you would like all components to do so. I know that this is a very little thing, but great stuff are made of little things also. I like that statement :) Regards, Erik. Paolo Di Tommaso schreef: I disagree about that. Methods semantics for components should be uniform, this is the most important rule for API simplicity and coherence. If Button#setEnabled( false ) is rendering a button in disabled state, I will expect that Link#setEnabled( false ) attached to a input type=button / tag will do the same. I know that this is a very little thing, but great stuff are made of little things also. Thanks, - Paolo -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/
Re: [Wicket-user] Link#setEnabled( false ) does not disable button element
True. To make it rock solid, I think it should be adaptable and/or extendable. IMHO it is not fair to expect that the change you propose is done perfectly from the start and maybe not even ever. If you go for slightly less rock solid, one can write code for every component known in the html specification (and perhaps some more). Anyway, supporting buttons is a great first step. Regards, Erik. Eelco Hillenius wrote: You're right of course. It would blow up link quite some, but that's just code; nothing that would hurt your runtime system. Can anyone (you?) provide a rock-solid patch for this and/ or open up an issue at JIRA? Eelco -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/
Re: AW: [Wicket-user] Link#setEnabled( false ) does not disable button element
Actually you can disable a button (I believe starting with HTML 4.0). For example: input type=submit disabled=disabled / This even works well for a css styled button. Regards, Erik. Korbinian Bachl schreef: You know that HTML does not provide a disabled button?- so what do you expect? in case of link its easy as its just underlined text, but what do you want in case of button? - img wont work, as usually CSS styles it, text isnt a button so the options are gone Regards -Ursprüngliche Nachricht- Von: Paolo Di Tommaso [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 13. Dezember 2006 08:33 An: wicket-dev@incubator.apache.org Betreff: Re: [Wicket-user] Link#setEnabled( false ) does not disable button element I disagree about that. Methods semantics for components should be uniform, this is the most important rule for API simplicity and coherence. If Button#setEnabled( false ) is rendering a button in disabled state, I will expect that Link#setEnabled( false ) attached to a input type=button / tag will do the same. I know that this is a very little thing, but great stuff are made of little things also. Thanks, - Paolo On 12/12/06, Erik van Oosten [EMAIL PROTECTED] wrote: Well, a Link can be attached to any HTML element so I think it can not know (in general) how to render the element disabled. A Button component can only be attached to an html button; for an html button it is known what to do. One could argue that the Link component can see what type of element it is attached to and do something appropriate. But that would blow up the implementation of Link which is probably not a good thing. Regards, Erik. Paolo Di Tommaso schreef: Invoking the Link#setEnabled( false ) on a input type=button / element will not disable the component. The onclick handler will not be invoked (disabled) but it does not apper as a disabled component. Instead invoking Button#setEnabled( false ) will render the button disabled. I think it would be simpler if it will be rendered disabled in both cases. Won't be? - Paolo -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/ -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/
Re: WicketFilter for dummies
Johan Compagner wrote: Then i need to know that /app in the filter. You can't ask it anywhere (not that i know) Perhaps it is possible to parse the web.xml from Wicket? Erik. -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/
Re: VOTE: make all onComponentTag and onComponentTagBody methods non-final
Hi Martijn, Nice excercise. As a user of Wicket, I'd say: Which one gets precedent? The modifier or onComponentTag? either modifier or neither (an exception). The modifier is added later and provides a one-time way to adapt an existing component. Letting the component have precedence is weird because then the modifier was added for nothing. If it is not possible to make this consistent, it should not be allowed (the exception). If it is not possible to check the consistency, the whole model is wrong so I do not believe that this is the case. Does it even matter? yes and users will expect it to be consistent for eternity (I would). Is the order of execution something that needs to be documented as a fixed contract, don't we care, should we even care? yes, no, yes. I understand your reservation; there are many ways in which a small misunderstandings of the user can lead to users. However, I feel sometimes feel the same frustration as Eelco describes. It happens at points where I want to combine some simple stuff (like 1 line in JSP) where in Wicket I have to either copy a whole class from the core, or add 3 behaviors each with their own custom anonymous model class (20 lines). Wicket is super duper excellent for combining larger things, but it gets a bit cumbersome when you're trying to combine small things. Besides, a fool will shoot himself in the foot eventually. Regards, Erik. -- Erik van Oosten http://day-to-day-stuff.blogspot.com/
Re: VOTE: make all onComponentTag and onComponentTagBody methods non-final
[X] Yes [ ] no Yes! My first vote here :) (These are open votes, right?) Erik. Eelco Hillenius wrote: I think using final for the onComponentTag and onComponentTagBody methods have served their purposes fine during our wild two years of development, but our core components are now stable enough to not have to be worried about painting ourselves in the corner when we would open up these methods (ie remove final). Please vote: [ ] yes, make all onComponentTag and onComponentTagBody methods of the standard components in core non-final. This does leave the door open for specific components to not adhere to that - I'm not proposing a new standard - but if this wins we would remove final for most of em [ ] no, leave the code as it is now Eelco
New property expression langauge: MVEL
Hello, There is a new property expression language called MVEL. If you look at http://wiki.mvflex.org/index.php?title=MVEL_Language_Reference you can see it is quite powerful. It also claims to be very fast. Perhaps it is appropriate to use MVEL as Wicket's default property language? Or do you think it is too powerful? Regards, Erik. -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/
Re: my feedback after using 1.2.x in a real app
You can override keys in any component. Please see here: http://cwiki.apache.org/WICKET/i18n-and-resource-boundles.html Alexei Sokolov wrote: 1. Please remove 'null' and 'nullValid' properties from wicket/Application.properties The names are too generic and used by Dropdown controls. So that leaves just number 2. Erik. -- Erik van Oosten http://day-to-day-stuff.blogspot.com/
Re: JIRA as our changes.xml
What I don't like is that is a plain list without any notion on what is important and what is not. Of course, its ok to maintain the changes in a tracking system. But presenting the list of changes exactly as they come from Jira is pretty hard on the reader. It should be fun to read change notes, its what makes you want to use the new stuff. So release notes are an important part of the product. What the heck, I'll volunteer to write those release notes if someone gives me that jira list. Erik. Igor Vaynberg schreef: what about them do you find unreadable? i would be +1 for this. keeping up changes.xml is a pain imho, and since a good amount will already be entered into jira it will take work off us. -igor -- Erik van Oosten http://day-to-day-stuff.blogspot.com/
Re: JIRA as our changes.xml
Ok, let me know when its needed. Erik. Igor Vaynberg schreef: On 11/13/06, Erik van Oosten [EMAIL PROTECTED] wrote: What the heck, I'll volunteer to write those release notes if someone gives me that jira list. https://issues.apache.org/jira/browse/WICKET?report=com.atlassian.jira.plugin.system.project:changelog-panel :) -igor Erik. Igor Vaynberg schreef: what about them do you find unreadable? i would be +1 for this. keeping up changes.xml is a pain imho, and since a good amount will already be entered into jira it will take work off us. -igor -- Erik van Oosten http://day-to-day-stuff.blogspot.com/ -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/
Re: License headers
My point is that in checkstyle you are free to enforce both the presence _and absence_ of anything that can be expressed as a regular expression. So that includes the $Id$ tag. That I always enforce inclusion of an $Id$ is just an example. In most of my projects I don't have a lot of merging to do. I can imagine that you would enforce exclusion of $Id$ for Wicket. Regards, Erik. Johan Compagner schreef: i don't hope that #Id# is mandatory! I hate those things. Because those things mess up merging of branches because they constantly change. It is totally stupid that this is the case. A merge should ignore those completely. johan -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/
Re: License headers
Hi Martijn, There are checkstyle plugins for Eclipse and for IDEA. Don't know about Netbeans. In addition checkstyle is able to check for a header (even as a RE), or check for the presence/absence of any RE. I used checkstyle frequently to enforce a correct copyright header, the presence of an $Id$ tag, presence of javadoc and a lot of code formatting rules. Regards, Erik. Martijn Dashorst schreef: I was going to propose to use checkstyle instead. Problem with checkstyle is that it is not a unit test and doesn't run inside Eclipse, NetBeans or IDEA :-). -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/
