Re: When NOT to use models ?
> What I found was that I was instantiating my LDM's as private variables in > my custom components but that they were not being detached. In this case > you need to programatically register your non default models to participate > in the detachment process. See the Wiki here for an example: > http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models#WorkingwithWicketmodels-ManagingthelifecycleofnondefaultdetachableIModel%27s Which part there in particular? I read it and it didn't yet ring my bell... is there really "another way" to register for onDetach events apart from the model being directly involved in render cycle as a formcomponent's or another component's defaultmodel? > For your option 3 I would say you should create a custom IModel > implementation that is aware of your caching strategy so that your > Component's don't need to care about how the data is loaded. Well.. that's the dream ;) Furthermore, I would like it to be more or less automatic. Maybe models like: 1. SettingThisModelWillResetCacheModel extends IModel 2. SettingThisModelWillNOTResetCacheModel extends IModel Furthremore, they would probably be created using a factory method in a cache manager: CacheManager cacheManager = new CacheManager(detachableToo); cacheManager.newIndependentCachedModel(IModel ...) cacheManager.newCachedModelWhoseChangeFiresExpire(IModel ...) AND maybe I could chain cacheManagers to say "cache manger A will expire if any of its dependent managers B-C-D expire." Also it should be easy to add cacheManager.addCacheExpirationListener(Runnable ..) or something. ... Anybody else need something like this? We could write a draft and see if it works and continue improving the design. ** Martin > > Your implementation could hold a Map of all related models and update > according to your rules or better yet build a service that does the caching > and dirty detection and then just have the LDM source the cell value from > the service. Something like: > > new LoabableDetachableModel () { > > protected CellValue load () { > > return cellService.getValue (row, col); > } > } > > Regards, > > Mike > >>> evaluated only one time per render can be done with >>> LoadableDetachedModel .. >>> >> >> I do not mean LOADED once per render. I mean EVALUATED once per >> render. In my understanding LoadableDetachableModel does not guarantee >> "reset" in any particular stage. >> >> >>> >>> can you explain it a littly bit (a link to your original message?) >>> >> >> I mean for rexample I have many models like this: >> >> new AbstractReadOnlyModel() { >> public String getObject() { >> // evaluate message with some logic >> return message; >> } >> } >> >> Furthermore, I have several components that, say, depend on this >> value. This getObject() will be called many times durung render and >> the logic will be evaluated many times. >> >> If I make it detachable it will yes be detached but I am not sure that >> the detaching is guaranteed at some specific point in request cycle? >> >> To make my "use case" more clear I will give an example: say I have a >> wicket page with a panel that contains a table with columns rows and y >> rows. Furthermore, let's assume it is a spreadsheet emulator: you can >> write formulas into the cells that depend on the other cells which >> means that the value of each cell is recursively evaluated dependent >> on the other cell's values. >> >> Requirements: >> 1. During render time each cell's model value should be cached once it >> has been evaluated (we do not want to recurse many times to fetch the >> same value). >> 2. If the value of any cell changes, all the dependent cells should be >> (for example) ajax refreshed and re-evaluated. For simplicity, we >> could re-set the cache of all models when change occurs. And >> redraw-all. >> 3. We want to reset cache ONLY if change occurs. >> >> In my understanding requirement 3 cannot be directly reached with >> detachable models. >> >> ** >> Martin >> >> > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Proposal: Fake implementation of AjaxRequestTarget instead of null
On Sat, Oct 24, 2009 at 5:23 PM, Vladimir K wrote: > > Although it is possible I wouldn't recommend authoring certainly different UI > basing on the asynchronisity of the request. For instance I experience > inconvinience when mistakely opening Outlook Web Access in Firefox instead > of MS IE and seeing a bit different non-ajaxy UI. just because something is not to your "liking" doesnt mean it should not be possible, so modify your proposal accordingly. > From the other hand I would prefer to just call RequestTarget.isAjax() to > distinguish what interface I should present to the user in case when it is > reasonable different. Checking whether the object is null is much dangerous > and non-self-descriptive. IMHO it is no-no design practice. in that case it should just be an onclick() inside which you can do: if (requestcycle.getrequesttarget() instanceof ajaxrequesttarget) { } -igor > > Since the number of fallback components is pretty small it is not difficult > to derive from them some project-local components and wrap event handling in > a manner I proposed to guard from NPE. But intention was to improve the > Wicket API not only for that particular case. > > > igor.vaynberg wrote: >> >> On Sat, Oct 24, 2009 at 7:18 AM, Sven Meier wrote: >> >>> I don't think he meant a *complete* no-op request target, just the method >>> addComponent() would be a no-op. The fake request target will rerender >>> the >>> complete page as any other standard request would do. >> >> this is not possible. all public contracts of the request target have >> to be properly implemented. eg if a component was added it should be >> returned by getcomponents(), also any registered listeners have to be >> notified, etc. >> >> i really dont understand the point of this change. if you have a fake >> ajaxrequesttarget then the code for a fallback is essentially a noop, >> so your app is broken in fallback. >> >> most of the code i have written that utilizes the fallback >> functionality looks like this: >> >> onclick(target) { >> if (target==null) { >> setresponsepage(new editpage(...)); >> } else { >> setupInp+laceEditPanel(); >> } >> } >> >> the workflows are divergent. >> >> -igor >> >>> >>> BTW why don't we get rid of all those AjaxFallback... components and just >>> let *all* Ajax... components support use of a standard HTML request as >>> fallback? >>> >>> Regards >>> >>> Sven >>> >>> Martin Grigorov wrote: I think he meant wasting CPU cycles for constructing your components which will be added to no-op ajaxrequesttarget then you'll have to make check like "if (target instanceOf NullAjaxRequestTarget) {return;}" which is not better than before El sáb, 24-10-2009 a las 12:18 +0200, Andreas Petersson escribió: > > I think it absolutely makes sense (for a future release of wicket). > having a NullObject instance of AjaxRequestTarget would not waste a lot > of cpu cycles at all, at least not how i use it. the only thing i do > with > the object is call .addComponent() and then refering a > already-initialized > variable. > > how likely is it that the object is in fact null? its <5% of users who > have javascript disabled. so this would affect only a small amount of > requests. > > from a jvm perspective calling methods with empty bodys very often is > not > something expensive. they will get inlined by the hotspot compiler and > be > effectively free. (i am not 100% sure if this also applys to > polymorphism > chains.) > > from a "clean-code" prespective it is often considered a code smell to > have a lot of null checks. > in your example providing a FakeDatabaseConnection that throws an > UnsrupportedOperationException("you have no database!") is better than > seeing a null pointer exception. > > >> >> Sounds weird. >> >> Why should my component burn cpu cycles to feed a fake ajax target >> which >> does nothing at all? >> >> I would prefer some null checks in that case. >> >> Would you also provide a FakeDatabaseConnection in case you >> application >> does not support databases? :-) >> >> >> Am 24.10.2009 um 07:42 schrieb Vladimir Kovalyuk: >> >> >>> >>> I believe all those null-checks of request target can be omited in >>> user >>> code >>> if fallback components would provide fake implementation of >>> AjaxRequestTarget instead of passing null. >>> >>> Does it make sense? >>> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > > - To unsubscribe, e-mail: users-unsubscr...@wicket.ap
Re: Proposal: Fake implementation of AjaxRequestTarget instead of null
Although it is possible I wouldn't recommend authoring certainly different UI basing on the asynchronisity of the request. For instance I experience inconvinience when mistakely opening Outlook Web Access in Firefox instead of MS IE and seeing a bit different non-ajaxy UI. All the handlers of fallback components in my code perform the same logic for ajax and non-ajax requests. The only difference is that I have to tell Wicket what components are invalidated due to changes in data model. I find it to be a good design style. That sort of information is just a garbage for the current Wicket rendering algorithm but thing could be different in the future if you decided to optimize the re-rendering process. >From the other hand I would prefer to just call RequestTarget.isAjax() to distinguish what interface I should present to the user in case when it is reasonable different. Checking whether the object is null is much dangerous and non-self-descriptive. IMHO it is no-no design practice. Since the number of fallback components is pretty small it is not difficult to derive from them some project-local components and wrap event handling in a manner I proposed to guard from NPE. But intention was to improve the Wicket API not only for that particular case. igor.vaynberg wrote: > > On Sat, Oct 24, 2009 at 7:18 AM, Sven Meier wrote: > >> I don't think he meant a *complete* no-op request target, just the method >> addComponent() would be a no-op. The fake request target will rerender >> the >> complete page as any other standard request would do. > > this is not possible. all public contracts of the request target have > to be properly implemented. eg if a component was added it should be > returned by getcomponents(), also any registered listeners have to be > notified, etc. > > i really dont understand the point of this change. if you have a fake > ajaxrequesttarget then the code for a fallback is essentially a noop, > so your app is broken in fallback. > > most of the code i have written that utilizes the fallback > functionality looks like this: > > onclick(target) { > if (target==null) { > setresponsepage(new editpage(...)); > } else { > setupInp+laceEditPanel(); > } > } > > the workflows are divergent. > > -igor > >> >> BTW why don't we get rid of all those AjaxFallback... components and just >> let *all* Ajax... components support use of a standard HTML request as >> fallback? >> >> Regards >> >> Sven >> >> Martin Grigorov wrote: >>> >>> I think he meant wasting CPU cycles for constructing your components >>> which will be added to no-op ajaxrequesttarget >>> >>> then you'll have to make check like "if (target instanceOf >>> NullAjaxRequestTarget) {return;}" which is not better than before >>> >>> El sáb, 24-10-2009 a las 12:18 +0200, Andreas Petersson escribió: >>> I think it absolutely makes sense (for a future release of wicket). having a NullObject instance of AjaxRequestTarget would not waste a lot of cpu cycles at all, at least not how i use it. the only thing i do with the object is call .addComponent() and then refering a already-initialized variable. how likely is it that the object is in fact null? its <5% of users who have javascript disabled. so this would affect only a small amount of requests. from a jvm perspective calling methods with empty bodys very often is not something expensive. they will get inlined by the hotspot compiler and be effectively free. (i am not 100% sure if this also applys to polymorphism chains.) from a "clean-code" prespective it is often considered a code smell to have a lot of null checks. in your example providing a FakeDatabaseConnection that throws an UnsrupportedOperationException("you have no database!") is better than seeing a null pointer exception. > > Sounds weird. > > Why should my component burn cpu cycles to feed a fake ajax target > which > does nothing at all? > > I would prefer some null checks in that case. > > Would you also provide a FakeDatabaseConnection in case you > application > does not support databases? :-) > > > Am 24.10.2009 um 07:42 schrieb Vladimir Kovalyuk: > > >> >> I believe all those null-checks of request target can be omited in >> user >> code >> if fallback components would provide fake implementation of >> AjaxRequestTarget instead of passing null. >> >> Does it make sense? >> - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>> For additional com
Re: Absolute static file references
have you actually hit a scalability problem? if you are trying to optimize upfront you can use a less invasive technique. all resource urls in wicekt are served under the /resources/ virtual folder. you can enable the setting where wicket will append a last-modified date to the end of each resource url, and then have an apache-side cache to cache and serve everything under /resources/. alternatively see how ContextImage works if you want to serve your own stuff out of webapp folder. -igor On Sat, Oct 24, 2009 at 10:53 AM, Luther Baker wrote: > Have another question about serving up CSS (JS, img, etc) files statically: > > a) I'd like to have the option to serve my CSS up statically via an apache > proxy. I'd also like to avoid serving CSS requests up via the wicket filter > - even if served up by Jetty - as I think it will scale just a bit better > ... > b) With my current URL mounts, many pages with different base URLs refer to > the same CSS file. Consequently, a relative URL for the common CSS files as > referenced in the master template won't work since the CSS file would be > looked up relative to each different URL mount point. > > Does that makes sense? So, I would like to create a simple, absolute > reference mechanism for my static CSS, image or other files (without > hardcoding). > > I'm not as knowledgeable about the way that components are mapped to wicket > tags, how to add my own tags or even how to create my own components (other > than Panels of course). Does the approach below adhere to the "wicket way"? > It feels a bit manual ... and I'm not fond of the static WEB_CONTEXT > assignment - but I don't see an elegant/efficient way to get it from within > the Page or the AbstractBehavior on a per request basis. > > Just looking for a bit of advice. > > Does the WIKI have some detailed docs that really get into the nitty gritty > of low-level component and tag design? IE: Details of ComponentTag, > MarkupElement, WicketTag, > > On the other hand, is there any strong advice to put custom CSS, image and > JS files in the classpath and reference ala wicket or is my approach > perfectly reasonable here. An alternate goal of mine to keep custom > components/solutions to a minimum. > > Thanks in advance, > > -Luther > > > > *MARKUP IN:* > > > href="style/default/main.css"/> > > > *MARKUP OUT:* > > > > > > *JAVA* > > final static String WEB_CONTEXT = > WebApplication.get().getServletContext().getContextPath(); > > protected DefaultPageTemplate() > { > // > http://www.mkyong.com/wicket/how-to-dynamic-add-attribute-to-a-html-tag-in-wicket/ > > final WebMarkupContainerWithAssociatedMarkup cssLink = new > WebMarkupContainerWithAssociatedMarkup("head.link"); > add(cssLink); > > cssLink.add(new AbstractBehavior() > { > private static final long serialVersionUID = 1L; > > �...@override > public void onComponentTag(final Component component, > final ComponentTag tag) > { > String href = tag.getAttribute("href"); > href = WEB_CONTEXT + "/" + href; > tag.put("href", href); > } > }); > } > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Proposal: Fake implementation of AjaxRequestTarget instead of null
In case of AjaxFallback components you would construct them anyway. Martin Grigorov wrote: I think he meant wasting CPU cycles for constructing your components which will be added to no-op ajaxrequesttarget then you'll have to make check like "if (target instanceOf NullAjaxRequestTarget) {return;}" which is not better than before El sáb, 24-10-2009 a las 12:18 +0200, Andreas Petersson escribió: I think it absolutely makes sense (for a future release of wicket). having a NullObject instance of AjaxRequestTarget would not waste a lot of cpu cycles at all, at least not how i use it. the only thing i do with the object is call .addComponent() and then refering a already-initialized variable. how likely is it that the object is in fact null? its <5% of users who have javascript disabled. so this would affect only a small amount of requests. from a jvm perspective calling methods with empty bodys very often is not something expensive. they will get inlined by the hotspot compiler and be effectively free. (i am not 100% sure if this also applys to polymorphism chains.) from a "clean-code" prespective it is often considered a code smell to have a lot of null checks. in your example providing a FakeDatabaseConnection that throws an UnsrupportedOperationException("you have no database!") is better than seeing a null pointer exception. Sounds weird. Why should my component burn cpu cycles to feed a fake ajax target which does nothing at all? I would prefer some null checks in that case. Would you also provide a FakeDatabaseConnection in case you application does not support databases? :-) Am 24.10.2009 um 07:42 schrieb Vladimir Kovalyuk: I believe all those null-checks of request target can be omited in user code if fallback components would provide fake implementation of AjaxRequestTarget instead of passing null. Does it make sense? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Wicket Wizard Functionality (Extensions)
Sven, I created my own implementation of a Wizard ButtonBar that adds the AjaxFormSubmittingBehavior to the existing buttons. I am not sure what I need to do in the overridden onSubmit(...) for each of the buttons. My current implementation simply calls wizard.getForm().onFormSubmitted() in each of the onSubmit methods, and haven't added anything to the onError. Is this the appropriate onSubmit behavior for the wizard buttons? J.D. -Original Message- From: Sven Meier [mailto:s...@meiers.net] Sent: Saturday, October 24, 2009 11:35 AM To: users@wicket.apache.org Subject: Re: Wicket Wizard Functionality (Extensions) Hi James, regretfully the standard Wicket dialog doesn't support non-AJAX request - perhaps this restriction applies to the YUI version too? You'll have to ajax-ify the wizard - see Wizard#newButtonBar(). I've done it for our project but I don't have the code available at the moment. Regards Sven Corbin, James wrote: > Hi Sven, > > I'm running the wizard in a modal popup (YUI). > > One other thing that is happening is when I press the next button in the > wizard that should take me to the next step, my dialog closes. I'm not > sure what would cause the dialog to dismiss/close in this manner. > > J.D. > > -Original Message- > From: Sven Meier [mailto:s...@meiers.net] > Sent: Saturday, October 24, 2009 8:32 AM > To: users@wicket.apache.org > Subject: Re: Wicket Wizard Functionality (Extensions) > > Hi James, > > >but Wicket's implementation seems to only evaluate the condition at > step > >creation and not when I'm changing the state of my radios. > > see NextButton#isEnabled() and FinishButton#isEnabled(). As far as I can > > see these method should support your usecase. Implementing ICondition as > > you did seems right to me. > > I assume you're notifying changes of the current radio choice to the > server via AJAX? Are you adding the whole wizard to the request so the > button bar is re-rendered? > > Sven > > Corbin, James wrote: > >> I am writing a two step wizard using wicket's wizard implementation >> > and > >> having some issues. >> >> I am using Wicket 1.4.1. >> >> My first wizard step contains a RadioChoice with 3 options. >> >> I would like the Finish Button to be enabled on Wizard Step 1 if >> > either > >> the first or second radio choice is selected. Also, if the first or >> second radio is selected, then the next button should not be enabled. >> >> If the 3rd Radio Choice is selected, then I want the Finish Button to >> > be > >> DISABLED, and the next button to be enabled so the user can go to the >> final step. >> >> My question >> >> I'm not sure how to set this up in wicket's wizard implementation. I >> tried specifying an ICondition on step two, to only make that step >> available if the selected type is Radio Choice Option 3 from step one, >> but Wicket's implementation seems to only evaluate the condition at >> > step > >> creation and not when I'm changing the state of my radios >> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket 1.4.3 Released!
Thanks! giovanni Resources are limited, Imagination is unlimited. From: Igor Vaynberg To: users@wicket.apache.org; d...@wicket.apache.org; annou...@wicket.apache.org Sent: Sat, October 24, 2009 12:12:55 AM Subject: Wicket 1.4.3 Released! release tag: https://svn.apache.org/repos/asf/wicket/releases/wicket-1.4.3 download: http://www.apache.org/dyn/closer.cgi/wicket/1.4.3 changelog: https://issues.apache.org/jira/browse/WICKET/fixforversion/12314250 ( full release notes below ) maven: org.apache.wicket wicket 1.4.3 thank you. -igor ps. our website has not yet been updated with the release announcement, something is broken with the confluence publishing plugin. --- Release Notes - Wicket - Version 1.4.3 ** Bug * [WICKET-2348] - always insert encoding in http response header * [WICKET-2436] - invalid DataTable markup breaks table layout * [WICKET-2497] - AutoComplete textfield ignores "visible" property within hierarchy. * [WICKET-2501] - BaseWicketTester clickLink calls onBeginRequest two times. * [WICKET-2505] - Button.onSubmit javadoc is misleading * [WICKET-2506] - Regression: "Could not find child with id: in the wicket:enclosure" for non-component tag * [WICKET-2507] - Inconsistent resource path using and HeaderContributor after second request * [WICKET-2508] - NullPointerException in BehaviorRequestTarget.processEvents(BehaviorRequestTarget.java:96) * [WICKET-2513] - wicket:enclosure does not work if child is a container and not a component (regression from 1.4.1) * [WICKET-2516] - Javadoc for Component.getMarkupId is incorrect * [WICKET-2518] - Application_bg.properties property file is incorrectly encoded * [WICKET-2520] - Use of Object instead of generic T in StringAutoCompleteRenderer * [WICKET-2522] - Easy fix suggestion: In BaseWicketTester 'IFormSubmitting' component should be the submitting component, not just a 'Button' * [WICKET-2525] - DatePicker consume too much memory * [WICKET-2527] - wicket:enclosure child attribute search path has changed * [WICKET-2528] - CheckBoxMultipleChoice ignores isDisabled() checks * [WICKET-2530] - Class not found when using OSGI class loader ** Improvement * [WICKET-2344] - Performance improvement: more efficient AnnotProxyFieldValueFactory cache * [WICKET-2459] - Add new German Wicket Book * [WICKET-2511] - Upgrade to SLF4J version 1.5.8 * [WICKET-2524] - Configurable Throttle delay for AutoCompleteBehavior ** Wish * [WICKET-2468] - AjaxLazyLoadPanel do not respect especific projects components configuration * [WICKET-2515] - ModalWindow javadoc improvent - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket Wizard Functionality (Extensions)
Yes, you can implement your own button bar which adds AjaxFormSubmitBehavior to the normal wizard buttons. Sven Corbin, James wrote: Thanks for the info Sven. I assume by Ajax-ify you mean to create a new implementation that mirrors WizardButton but extends AjaxButton instead of just Button? Also, our code base is currently on 1.4.1, I noticed 1.4.3 (stable?) is released but the main Apache Wicket Page hasn't been updated? What are your thoughts on upgrading directly to 1.4.3, or should we stick with a 1.4.2 upgrade? J.D. -Original Message- From: Sven Meier [mailto:s...@meiers.net] Sent: Saturday, October 24, 2009 11:35 AM To: users@wicket.apache.org Subject: Re: Wicket Wizard Functionality (Extensions) Hi James, regretfully the standard Wicket dialog doesn't support non-AJAX request - perhaps this restriction applies to the YUI version too? You'll have to ajax-ify the wizard - see Wizard#newButtonBar(). I've done it for our project but I don't have the code available at the moment. Regards Sven Corbin, James wrote: Hi Sven, I'm running the wizard in a modal popup (YUI). One other thing that is happening is when I press the next button in the wizard that should take me to the next step, my dialog closes. I'm not sure what would cause the dialog to dismiss/close in this manner. J.D. -Original Message- From: Sven Meier [mailto:s...@meiers.net] Sent: Saturday, October 24, 2009 8:32 AM To: users@wicket.apache.org Subject: Re: Wicket Wizard Functionality (Extensions) Hi James, >but Wicket's implementation seems to only evaluate the condition at step >creation and not when I'm changing the state of my radios. see NextButton#isEnabled() and FinishButton#isEnabled(). As far as I can see these method should support your usecase. Implementing ICondition as you did seems right to me. I assume you're notifying changes of the current radio choice to the server via AJAX? Are you adding the whole wizard to the request so the button bar is re-rendered? Sven Corbin, James wrote: I am writing a two step wizard using wicket's wizard implementation and having some issues. I am using Wicket 1.4.1. My first wizard step contains a RadioChoice with 3 options. I would like the Finish Button to be enabled on Wizard Step 1 if either the first or second radio choice is selected. Also, if the first or second radio is selected, then the next button should not be enabled. If the 3rd Radio Choice is selected, then I want the Finish Button to be DISABLED, and the next button to be enabled so the user can go to the final step. My question I'm not sure how to set this up in wicket's wizard implementation. I tried specifying an ICondition on step two, to only make that step available if the selected type is Radio Choice Option 3 from step one, but Wicket's implementation seems to only evaluate the condition at step creation and not when I'm changing the state of my radios - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Proposal: Fake implementation of AjaxRequestTarget instead of null
Nothing broken on this side of the fence: onclick(target) { deleteRow(); if (target==null) { // don't bother } else { target.addComponent(table); } } Sven Igor Vaynberg wrote: On Sat, Oct 24, 2009 at 7:18 AM, Sven Meier wrote: I don't think he meant a *complete* no-op request target, just the method addComponent() would be a no-op. The fake request target will rerender the complete page as any other standard request would do. this is not possible. all public contracts of the request target have to be properly implemented. eg if a component was added it should be returned by getcomponents(), also any registered listeners have to be notified, etc. i really dont understand the point of this change. if you have a fake ajaxrequesttarget then the code for a fallback is essentially a noop, so your app is broken in fallback. most of the code i have written that utilizes the fallback functionality looks like this: onclick(target) { if (target==null) { setresponsepage(new editpage(...)); } else { setupInp+laceEditPanel(); } } the workflows are divergent. -igor BTW why don't we get rid of all those AjaxFallback... components and just let *all* Ajax... components support use of a standard HTML request as fallback? Regards Sven Martin Grigorov wrote: I think he meant wasting CPU cycles for constructing your components which will be added to no-op ajaxrequesttarget then you'll have to make check like "if (target instanceOf NullAjaxRequestTarget) {return;}" which is not better than before El sáb, 24-10-2009 a las 12:18 +0200, Andreas Petersson escribió: I think it absolutely makes sense (for a future release of wicket). having a NullObject instance of AjaxRequestTarget would not waste a lot of cpu cycles at all, at least not how i use it. the only thing i do with the object is call .addComponent() and then refering a already-initialized variable. how likely is it that the object is in fact null? its <5% of users who have javascript disabled. so this would affect only a small amount of requests. from a jvm perspective calling methods with empty bodys very often is not something expensive. they will get inlined by the hotspot compiler and be effectively free. (i am not 100% sure if this also applys to polymorphism chains.) from a "clean-code" prespective it is often considered a code smell to have a lot of null checks. in your example providing a FakeDatabaseConnection that throws an UnsrupportedOperationException("you have no database!") is better than seeing a null pointer exception. Sounds weird. Why should my component burn cpu cycles to feed a fake ajax target which does nothing at all? I would prefer some null checks in that case. Would you also provide a FakeDatabaseConnection in case you application does not support databases? :-) Am 24.10.2009 um 07:42 schrieb Vladimir Kovalyuk: I believe all those null-checks of request target can be omited in user code if fallback components would provide fake implementation of AjaxRequestTarget instead of passing null. Does it make sense? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Proposal: Fake implementation of AjaxRequestTarget instead of null
On Sat, Oct 24, 2009 at 7:18 AM, Sven Meier wrote: > I don't think he meant a *complete* no-op request target, just the method > addComponent() would be a no-op. The fake request target will rerender the > complete page as any other standard request would do. this is not possible. all public contracts of the request target have to be properly implemented. eg if a component was added it should be returned by getcomponents(), also any registered listeners have to be notified, etc. i really dont understand the point of this change. if you have a fake ajaxrequesttarget then the code for a fallback is essentially a noop, so your app is broken in fallback. most of the code i have written that utilizes the fallback functionality looks like this: onclick(target) { if (target==null) { setresponsepage(new editpage(...)); } else { setupInp+laceEditPanel(); } } the workflows are divergent. -igor > > BTW why don't we get rid of all those AjaxFallback... components and just > let *all* Ajax... components support use of a standard HTML request as > fallback? > > Regards > > Sven > > Martin Grigorov wrote: >> >> I think he meant wasting CPU cycles for constructing your components >> which will be added to no-op ajaxrequesttarget >> >> then you'll have to make check like "if (target instanceOf >> NullAjaxRequestTarget) {return;}" which is not better than before >> >> El sáb, 24-10-2009 a las 12:18 +0200, Andreas Petersson escribió: >> >>> >>> I think it absolutely makes sense (for a future release of wicket). >>> having a NullObject instance of AjaxRequestTarget would not waste a lot >>> of cpu cycles at all, at least not how i use it. the only thing i do with >>> the object is call .addComponent() and then refering a already-initialized >>> variable. >>> >>> how likely is it that the object is in fact null? its <5% of users who >>> have javascript disabled. so this would affect only a small amount of >>> requests. >>> >>> from a jvm perspective calling methods with empty bodys very often is not >>> something expensive. they will get inlined by the hotspot compiler and be >>> effectively free. (i am not 100% sure if this also applys to polymorphism >>> chains.) >>> >>> from a "clean-code" prespective it is often considered a code smell to >>> have a lot of null checks. >>> in your example providing a FakeDatabaseConnection that throws an >>> UnsrupportedOperationException("you have no database!") is better than >>> seeing a null pointer exception. >>> >>> Sounds weird. Why should my component burn cpu cycles to feed a fake ajax target which does nothing at all? I would prefer some null checks in that case. Would you also provide a FakeDatabaseConnection in case you application does not support databases? :-) Am 24.10.2009 um 07:42 schrieb Vladimir Kovalyuk: > > I believe all those null-checks of request target can be omited in user > code > if fallback components would provide fake implementation of > AjaxRequestTarget instead of passing null. > > Does it make sense? > >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>> For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> >>> >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Wicket Wizard Functionality (Extensions)
Thanks for the info Sven. I assume by Ajax-ify you mean to create a new implementation that mirrors WizardButton but extends AjaxButton instead of just Button? Also, our code base is currently on 1.4.1, I noticed 1.4.3 (stable?) is released but the main Apache Wicket Page hasn't been updated? What are your thoughts on upgrading directly to 1.4.3, or should we stick with a 1.4.2 upgrade? J.D. -Original Message- From: Sven Meier [mailto:s...@meiers.net] Sent: Saturday, October 24, 2009 11:35 AM To: users@wicket.apache.org Subject: Re: Wicket Wizard Functionality (Extensions) Hi James, regretfully the standard Wicket dialog doesn't support non-AJAX request - perhaps this restriction applies to the YUI version too? You'll have to ajax-ify the wizard - see Wizard#newButtonBar(). I've done it for our project but I don't have the code available at the moment. Regards Sven Corbin, James wrote: > Hi Sven, > > I'm running the wizard in a modal popup (YUI). > > One other thing that is happening is when I press the next button in the > wizard that should take me to the next step, my dialog closes. I'm not > sure what would cause the dialog to dismiss/close in this manner. > > J.D. > > -Original Message- > From: Sven Meier [mailto:s...@meiers.net] > Sent: Saturday, October 24, 2009 8:32 AM > To: users@wicket.apache.org > Subject: Re: Wicket Wizard Functionality (Extensions) > > Hi James, > > >but Wicket's implementation seems to only evaluate the condition at > step > >creation and not when I'm changing the state of my radios. > > see NextButton#isEnabled() and FinishButton#isEnabled(). As far as I can > > see these method should support your usecase. Implementing ICondition as > > you did seems right to me. > > I assume you're notifying changes of the current radio choice to the > server via AJAX? Are you adding the whole wizard to the request so the > button bar is re-rendered? > > Sven > > Corbin, James wrote: > >> I am writing a two step wizard using wicket's wizard implementation >> > and > >> having some issues. >> >> I am using Wicket 1.4.1. >> >> My first wizard step contains a RadioChoice with 3 options. >> >> I would like the Finish Button to be enabled on Wizard Step 1 if >> > either > >> the first or second radio choice is selected. Also, if the first or >> second radio is selected, then the next button should not be enabled. >> >> If the 3rd Radio Choice is selected, then I want the Finish Button to >> > be > >> DISABLED, and the next button to be enabled so the user can go to the >> final step. >> >> My question >> >> I'm not sure how to set this up in wicket's wizard implementation. I >> tried specifying an ICondition on step two, to only make that step >> available if the selected type is Radio Choice Option 3 from step one, >> but Wicket's implementation seems to only evaluate the condition at >> > step > >> creation and not when I'm changing the state of my radios >> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Absolute static file references
Have another question about serving up CSS (JS, img, etc) files statically: a) I'd like to have the option to serve my CSS up statically via an apache proxy. I'd also like to avoid serving CSS requests up via the wicket filter - even if served up by Jetty - as I think it will scale just a bit better ... b) With my current URL mounts, many pages with different base URLs refer to the same CSS file. Consequently, a relative URL for the common CSS files as referenced in the master template won't work since the CSS file would be looked up relative to each different URL mount point. Does that makes sense? So, I would like to create a simple, absolute reference mechanism for my static CSS, image or other files (without hardcoding). I'm not as knowledgeable about the way that components are mapped to wicket tags, how to add my own tags or even how to create my own components (other than Panels of course). Does the approach below adhere to the "wicket way"? It feels a bit manual ... and I'm not fond of the static WEB_CONTEXT assignment - but I don't see an elegant/efficient way to get it from within the Page or the AbstractBehavior on a per request basis. Just looking for a bit of advice. Does the WIKI have some detailed docs that really get into the nitty gritty of low-level component and tag design? IE: Details of ComponentTag, MarkupElement, WicketTag, On the other hand, is there any strong advice to put custom CSS, image and JS files in the classpath and reference ala wicket or is my approach perfectly reasonable here. An alternate goal of mine to keep custom components/solutions to a minimum. Thanks in advance, -Luther *MARKUP IN:* *MARKUP OUT:* *JAVA* final static String WEB_CONTEXT = WebApplication.get().getServletContext().getContextPath(); protected DefaultPageTemplate() { // http://www.mkyong.com/wicket/how-to-dynamic-add-attribute-to-a-html-tag-in-wicket/ final WebMarkupContainerWithAssociatedMarkup cssLink = new WebMarkupContainerWithAssociatedMarkup("head.link"); add(cssLink); cssLink.add(new AbstractBehavior() { private static final long serialVersionUID = 1L; @Override public void onComponentTag(final Component component, final ComponentTag tag) { String href = tag.getAttribute("href"); href = WEB_CONTEXT + "/" + href; tag.put("href", href); } }); }
i18n and resource bundles (wicket wiki)
Hi, on the wicket-wiki (http://cwiki.apache.org/WICKET/i18n-and-resource-bundles.html) I've found a point that won't work. Below the point "Load resources dynamically for a component" there is the first alternative using ...PackageResource.get(MyComponent.class, "Mycomponent.properties")... I've tried that to load properties but it doesn't work. The reason is that the PackageResource calls their accept method internally. This loads a PackageResourceGuard from the Application. But this PackageResourceGuard has a list of blocked extensions: java, class and properties. If you make this call above it'll result in a "PackageResourceBlockedException". marc - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket Wizard Functionality (Extensions)
Hi James, regretfully the standard Wicket dialog doesn't support non-AJAX request - perhaps this restriction applies to the YUI version too? You'll have to ajax-ify the wizard - see Wizard#newButtonBar(). I've done it for our project but I don't have the code available at the moment. Regards Sven Corbin, James wrote: Hi Sven, I'm running the wizard in a modal popup (YUI). One other thing that is happening is when I press the next button in the wizard that should take me to the next step, my dialog closes. I'm not sure what would cause the dialog to dismiss/close in this manner. J.D. -Original Message- From: Sven Meier [mailto:s...@meiers.net] Sent: Saturday, October 24, 2009 8:32 AM To: users@wicket.apache.org Subject: Re: Wicket Wizard Functionality (Extensions) Hi James, >but Wicket's implementation seems to only evaluate the condition at step >creation and not when I'm changing the state of my radios. see NextButton#isEnabled() and FinishButton#isEnabled(). As far as I can see these method should support your usecase. Implementing ICondition as you did seems right to me. I assume you're notifying changes of the current radio choice to the server via AJAX? Are you adding the whole wizard to the request so the button bar is re-rendered? Sven Corbin, James wrote: I am writing a two step wizard using wicket's wizard implementation and having some issues. I am using Wicket 1.4.1. My first wizard step contains a RadioChoice with 3 options. I would like the Finish Button to be enabled on Wizard Step 1 if either the first or second radio choice is selected. Also, if the first or second radio is selected, then the next button should not be enabled. If the 3rd Radio Choice is selected, then I want the Finish Button to be DISABLED, and the next button to be enabled so the user can go to the final step. My question I'm not sure how to set this up in wicket's wizard implementation. I tried specifying an ICondition on step two, to only make that step available if the selected type is Radio Choice Option 3 from step one, but Wicket's implementation seems to only evaluate the condition at step creation and not when I'm changing the state of my radios - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: When NOT to use models ?
Hi Martin, I saw the same type of behavior you are talking about with LoadableDetachableModels not detaching but AbstractReadOnlyModel's working properly. What I found was that I was instantiating my LDM's as private variables in my custom components but that they were not being detached. In this case you need to programatically register your non default models to participate in the detachment process. See the Wiki here for an example: http://cwiki.apache.org/confluence/display/WICKET/Working+with+Wicket+models#WorkingwithWicketmodels-ManagingthelifecycleofnondefaultdetachableIModel%27s For your option 3 I would say you should create a custom IModel implementation that is aware of your caching strategy so that your Component's don't need to care about how the data is loaded. Your implementation could hold a Map of all related models and update according to your rules or better yet build a service that does the caching and dirty detection and then just have the LDM source the cell value from the service. Something like: new LoabableDetachableModel () { protected CellValue load () { return cellService.getValue (row, col); } } Regards, Mike evaluated only one time per render can be done with LoadableDetachedModel .. I do not mean LOADED once per render. I mean EVALUATED once per render. In my understanding LoadableDetachableModel does not guarantee "reset" in any particular stage. can you explain it a littly bit (a link to your original message?) I mean for rexample I have many models like this: new AbstractReadOnlyModel() { public String getObject() { // evaluate message with some logic return message; } } Furthermore, I have several components that, say, depend on this value. This getObject() will be called many times durung render and the logic will be evaluated many times. If I make it detachable it will yes be detached but I am not sure that the detaching is guaranteed at some specific point in request cycle? To make my "use case" more clear I will give an example: say I have a wicket page with a panel that contains a table with columns rows and y rows. Furthermore, let's assume it is a spreadsheet emulator: you can write formulas into the cells that depend on the other cells which means that the value of each cell is recursively evaluated dependent on the other cell's values. Requirements: 1. During render time each cell's model value should be cached once it has been evaluated (we do not want to recurse many times to fetch the same value). 2. If the value of any cell changes, all the dependent cells should be (for example) ajax refreshed and re-evaluated. For simplicity, we could re-set the cache of all models when change occurs. And redraw-all. 3. We want to reset cache ONLY if change occurs. In my understanding requirement 3 cannot be directly reached with detachable models. ** Martin
RE: Wicket Wizard Functionality (Extensions)
Hi Sven, I'm running the wizard in a modal popup (YUI). One other thing that is happening is when I press the next button in the wizard that should take me to the next step, my dialog closes. I'm not sure what would cause the dialog to dismiss/close in this manner. J.D. -Original Message- From: Sven Meier [mailto:s...@meiers.net] Sent: Saturday, October 24, 2009 8:32 AM To: users@wicket.apache.org Subject: Re: Wicket Wizard Functionality (Extensions) Hi James, >but Wicket's implementation seems to only evaluate the condition at step >creation and not when I'm changing the state of my radios. see NextButton#isEnabled() and FinishButton#isEnabled(). As far as I can see these method should support your usecase. Implementing ICondition as you did seems right to me. I assume you're notifying changes of the current radio choice to the server via AJAX? Are you adding the whole wizard to the request so the button bar is re-rendered? Sven Corbin, James wrote: > I am writing a two step wizard using wicket's wizard implementation and > having some issues. > > I am using Wicket 1.4.1. > > My first wizard step contains a RadioChoice with 3 options. > > I would like the Finish Button to be enabled on Wizard Step 1 if either > the first or second radio choice is selected. Also, if the first or > second radio is selected, then the next button should not be enabled. > > If the 3rd Radio Choice is selected, then I want the Finish Button to be > DISABLED, and the next button to be enabled so the user can go to the > final step. > > My question > > I'm not sure how to set this up in wicket's wizard implementation. I > tried specifying an ICondition on step two, to only make that step > available if the selected type is Radio Choice Option 3 from step one, > but Wicket's implementation seems to only evaluate the condition at step > creation and not when I'm changing the state of my radios - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket Wizard Functionality (Extensions)
I am using Ajax but not adding wizard to target. I will play with that. Thank you for the suggestion. Sent from my iPhone On Oct 24, 2009, at 8:32, "Sven Meier" wrote: Hi James, >but Wicket's implementation seems to only evaluate the condition at step >creation and not when I'm changing the state of my radios. see NextButton#isEnabled() and FinishButton#isEnabled(). As far as I can see these method should support your usecase. Implementing ICondition as you did seems right to me. I assume you're notifying changes of the current radio choice to the server via AJAX? Are you adding the whole wizard to the request so the button bar is re-rendered? Sven Corbin, James wrote: I am writing a two step wizard using wicket's wizard implementation and having some issues. I am using Wicket 1.4.1. My first wizard step contains a RadioChoice with 3 options. I would like the Finish Button to be enabled on Wizard Step 1 if either the first or second radio choice is selected. Also, if the first or second radio is selected, then the next button should not be enabled. If the 3rd Radio Choice is selected, then I want the Finish Button to be DISABLED, and the next button to be enabled so the user can go to the final step. My question I'm not sure how to set this up in wicket's wizard implementation. I tried specifying an ICondition on step two, to only make that step available if the selected type is Radio Choice Option 3 from step one, but Wicket's implementation seems to only evaluate the condition at step creation and not when I'm changing the state of my radios - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket Wizard Functionality (Extensions)
Hi James, >but Wicket's implementation seems to only evaluate the condition at step >creation and not when I'm changing the state of my radios. see NextButton#isEnabled() and FinishButton#isEnabled(). As far as I can see these method should support your usecase. Implementing ICondition as you did seems right to me. I assume you're notifying changes of the current radio choice to the server via AJAX? Are you adding the whole wizard to the request so the button bar is re-rendered? Sven Corbin, James wrote: I am writing a two step wizard using wicket's wizard implementation and having some issues. I am using Wicket 1.4.1. My first wizard step contains a RadioChoice with 3 options. I would like the Finish Button to be enabled on Wizard Step 1 if either the first or second radio choice is selected. Also, if the first or second radio is selected, then the next button should not be enabled. If the 3rd Radio Choice is selected, then I want the Finish Button to be DISABLED, and the next button to be enabled so the user can go to the final step. My question I'm not sure how to set this up in wicket's wizard implementation. I tried specifying an ICondition on step two, to only make that step available if the selected type is Radio Choice Option 3 from step one, but Wicket's implementation seems to only evaluate the condition at step creation and not when I'm changing the state of my radios - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Proposal: Fake implementation of AjaxRequestTarget instead of null
Hi all, IMHO Vladimir has made a reasonable suggestion. > I think he meant wasting CPU cycles for constructing your components > which will be added to no-op ajaxrequesttarget I don't think he meant a *complete* no-op request target, just the method addComponent() would be a no-op. The fake request target will rerender the complete page as any other standard request would do. BTW why don't we get rid of all those AjaxFallback... components and just let *all* Ajax... components support use of a standard HTML request as fallback? Regards Sven Martin Grigorov wrote: I think he meant wasting CPU cycles for constructing your components which will be added to no-op ajaxrequesttarget then you'll have to make check like "if (target instanceOf NullAjaxRequestTarget) {return;}" which is not better than before El sáb, 24-10-2009 a las 12:18 +0200, Andreas Petersson escribió: I think it absolutely makes sense (for a future release of wicket). having a NullObject instance of AjaxRequestTarget would not waste a lot of cpu cycles at all, at least not how i use it. the only thing i do with the object is call .addComponent() and then refering a already-initialized variable. how likely is it that the object is in fact null? its <5% of users who have javascript disabled. so this would affect only a small amount of requests. from a jvm perspective calling methods with empty bodys very often is not something expensive. they will get inlined by the hotspot compiler and be effectively free. (i am not 100% sure if this also applys to polymorphism chains.) from a "clean-code" prespective it is often considered a code smell to have a lot of null checks. in your example providing a FakeDatabaseConnection that throws an UnsrupportedOperationException("you have no database!") is better than seeing a null pointer exception. Sounds weird. Why should my component burn cpu cycles to feed a fake ajax target which does nothing at all? I would prefer some null checks in that case. Would you also provide a FakeDatabaseConnection in case you application does not support databases? :-) Am 24.10.2009 um 07:42 schrieb Vladimir Kovalyuk: I believe all those null-checks of request target can be omited in user code if fallback components would provide fake implementation of AjaxRequestTarget instead of passing null. Does it make sense? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: I18N for bookmarkable urls
Hi folks, Since my app will be english and german aswell, that is something I need too. I tried to mount and unmount my pages when the locale changes from german to english or vice versa. I tried using ResourceModel Strings for the urls, but it's not working the way I want it to be. And it would be a massive amount of code for something that seems to be so simple. The problem is, that I want both urls to be accessed via the url like in the example: http://xxx/impressum and http://xxx/imprint should be accessible not depending on a specific locale setting. (Perhaps the locale should change to english or german depending on the url when accessed via a browser bookmark with no session) The problem is, that you can mount a class multiple times, but for creating the BookmarkablePageLinks the first one mounted will be used for the link. (tested with wicket 1.4.3). Wouldn't it be cool to have such a mechanism which uses the Locale setting to generate links and mount pages. For example (Just pseudo code): .mount( new HybridUrlCodingStrategy( "impressum", ImprintPage.class, Locale.GERMAN) ); .mount( new HybridUrlCodingStrategy( "imprint", ImprintPage.class, Locale.ENGLISH) ); And when you then generate a url you could use: add(new BookmarkablePageLink( "bookmarked", ImprintPage.class, getSession().getLocale()) ); That way both urls would be accessible if bookmarked. And the user gets the url generated in his locale while browsing through the app. Is there a cool(=easy) way to do that or will it lead to a massive code section that mounts and unmounts pages on locale change? Bernhard Ilja Pavkovic schrieb: Hi, as we need some SEO optimization I want to provide the following bookmarkable pages: http://xxx/impressum http://xxx/imprint the native approach would be somethink like: mountBookmarkablePage("imprint", ImprintPage.class); mountBookmarkablePage("impressum", ImprintPage.class); This looks ugly but works. Now I don't know how to create a bookmarkable links having an url in the expected language. if( getLocale().equals(Locale.GERMAN)) { //create http://xxx/impressum } else { // http://xxx/imprint } Obviously the following code does not help: add(new BookmarkablePageLink("link", ImprintPage.class)); Does anyone have a good idea? Best regards, Ilja Pavkovic - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Proposal: Fake implementation of AjaxRequestTarget instead of null
I think he meant wasting CPU cycles for constructing your components which will be added to no-op ajaxrequesttarget then you'll have to make check like "if (target instanceOf NullAjaxRequestTarget) {return;}" which is not better than before El sáb, 24-10-2009 a las 12:18 +0200, Andreas Petersson escribió: > I think it absolutely makes sense (for a future release of wicket). > having a NullObject instance of AjaxRequestTarget would not waste a lot > of cpu cycles at all, at least not how i use it. the only thing i do > with the object is call .addComponent() and then refering a > already-initialized variable. > > how likely is it that the object is in fact null? its <5% of users who > have javascript disabled. so this would affect only a small amount of > requests. > > from a jvm perspective calling methods with empty bodys very often is > not something expensive. they will get inlined by the hotspot compiler > and be effectively free. (i am not 100% sure if this also applys to > polymorphism chains.) > > from a "clean-code" prespective it is often considered a code smell to > have a lot of null checks. > in your example providing a FakeDatabaseConnection that throws an > UnsrupportedOperationException("you have no database!") is better than > seeing a null pointer exception. > > > Sounds weird. > > > > Why should my component burn cpu cycles to feed a fake ajax target > > which does nothing at all? > > > > I would prefer some null checks in that case. > > > > Would you also provide a FakeDatabaseConnection in case you > > application does not support databases? :-) > > > > > > Am 24.10.2009 um 07:42 schrieb Vladimir Kovalyuk: > > > >> I believe all those null-checks of request target can be omited in > >> user code > >> if fallback components would provide fake implementation of > >> AjaxRequestTarget instead of passing null. > >> > >> Does it make sense? > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Proposal: Fake implementation of AjaxRequestTarget instead of null
I think it absolutely makes sense (for a future release of wicket). having a NullObject instance of AjaxRequestTarget would not waste a lot of cpu cycles at all, at least not how i use it. the only thing i do with the object is call .addComponent() and then refering a already-initialized variable. how likely is it that the object is in fact null? its <5% of users who have javascript disabled. so this would affect only a small amount of requests. from a jvm perspective calling methods with empty bodys very often is not something expensive. they will get inlined by the hotspot compiler and be effectively free. (i am not 100% sure if this also applys to polymorphism chains.) from a "clean-code" prespective it is often considered a code smell to have a lot of null checks. in your example providing a FakeDatabaseConnection that throws an UnsrupportedOperationException("you have no database!") is better than seeing a null pointer exception. Sounds weird. Why should my component burn cpu cycles to feed a fake ajax target which does nothing at all? I would prefer some null checks in that case. Would you also provide a FakeDatabaseConnection in case you application does not support databases? :-) Am 24.10.2009 um 07:42 schrieb Vladimir Kovalyuk: I believe all those null-checks of request target can be omited in user code if fallback components would provide fake implementation of AjaxRequestTarget instead of passing null. Does it make sense? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Proposal: Fake implementation of AjaxRequestTarget instead of null
Sounds weird. Why should my component burn cpu cycles to feed a fake ajax target which does nothing at all? I would prefer some null checks in that case. Would you also provide a FakeDatabaseConnection in case you application does not support databases? :-) Am 24.10.2009 um 07:42 schrieb Vladimir Kovalyuk: I believe all those null-checks of request target can be omited in user code if fallback components would provide fake implementation of AjaxRequestTarget instead of passing null. Does it make sense? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: end tag not found in panel-div
Hi Igor, ah, you're completly right. I have forgotten to remove the wicket:message-tags from the panels after seperating them. Thanks for the hint! Have a nice saturday. Marc Igor Vaynberg schrieb: > so headerLogo is a Panel? > > you cannot do that, you cannot have markup with wicket:ids inside a > tag that you want to be replaced with a panel. > > -igor > > On Sat, Oct 24, 2009 at 12:16 AM, Marc Ende wrote: > >> Hi, >> >> I had worked on several projects with 1.3 and now I have changed to >> 1.4.2 (and now to 1.4.3). >> After that I have a strange error when I'm using panels: >> >> WicketMessage: close tag not found for tag: > wicket:id="headerLogo">. Component: [MarkupContainer [Component id = >> headerLogo]] >> >> This happens within a panel which looks like this: >> >> >> >> >>> key="services">services >>http://xxx.yyy.zzz/";>> key="projectmanagement">projectmanagement >> >> >> >> Home >> Item 1 >> Item 1 >> Item 2 >> Contact >> >> >> >> >> >> If I comment the contents of the div's (which have wicket:id) >> everything works fine. >> >> >> >> >> >> >> >> >> >> >> >> >> I'm not sure but I thought that the content of the div's (with >> wicket:id) will be replaced with the contents of the panel. So I would >> expect that this should work. (And I thought that I had used it this >> way on wicket 1.3). >> >> Does anybody have an idea? >> >> Marc >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> >> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: end tag not found in panel-div
so headerLogo is a Panel? you cannot do that, you cannot have markup with wicket:ids inside a tag that you want to be replaced with a panel. -igor On Sat, Oct 24, 2009 at 12:16 AM, Marc Ende wrote: > Hi, > > I had worked on several projects with 1.3 and now I have changed to > 1.4.2 (and now to 1.4.3). > After that I have a strange error when I'm using panels: > > WicketMessage: close tag not found for tag: wicket:id="headerLogo">. Component: [MarkupContainer [Component id = > headerLogo]] > > This happens within a panel which looks like this: > > > > > key="services">services > http://xxx.yyy.zzz/";> key="projectmanagement">projectmanagement > > > > Home > Item 1 > Item 1 > Item 2 > Contact > > > > > > If I comment the contents of the div's (which have wicket:id) > everything works fine. > > > > > > > > > > > > > I'm not sure but I thought that the content of the div's (with > wicket:id) will be replaced with the contents of the panel. So I would > expect that this should work. (And I thought that I had used it this > way on wicket 1.3). > > Does anybody have an idea? > > Marc > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
end tag not found in panel-div
Hi, I had worked on several projects with 1.3 and now I have changed to 1.4.2 (and now to 1.4.3). After that I have a strange error when I'm using panels: WicketMessage: close tag not found for tag: . Component: [MarkupContainer [Component id = headerLogo]] This happens within a panel which looks like this: services http://xxx.yyy.zzz/";>projectmanagement Home Item 1 Item 1 Item 2 Contact If I comment the contents of the div's (which have wicket:id) everything works fine. I'm not sure but I thought that the content of the div's (with wicket:id) will be replaced with the contents of the panel. So I would expect that this should work. (And I thought that I had used it this way on wicket 1.3). Does anybody have an idea? Marc - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org