Multi-tenancy with style
We're building a multi-tenant capable application. The basic idea is to identify the tenant for a request and put the tenant information into a ThreadLocal. One requirement is to enable 'localization' per tenant, i.e. to allow tenant-specific labels, like for example one tenant wants to display the term 'client' instead of 'customer'. The first thing that comes to my mind is using tenant-specific styles, i.e. to read the properties from files like labels_tenant1.properties and labels_tenant2.properties. Any arguments against that? Is there any other multi-tenancy support in Wicket? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Multi-tenancy-with-style-tp3027221p3027221.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: AjaxEditableLabel uses wicketAjaxGet
Stupid me. Thx. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/AjaxEditableLabel-uses-wicketAjaxGet-tp2719139p2719168.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Announcing: Scala-Wicket Extensions Project
Antony Stubbs wrote: > > > Yes, the ⇒ is actually what the "=>" is supposed to be in Scala, and is a > UTF8 character, which I'm sure would be supported by all modern editors. > I'm surprised you can't see it properly. What OS and version of Eclipse > are you viewing them with? I am toying around with ⇒ atm and haven't > really reached a decision on which I prefer. But if it causes trouble for > people, and it's an open library, then causing _less_ trouble for people > is preferable :) > > I'm having the same problems, in any text editor. -- View this message in context: http://www.nabble.com/Announcing%3A-Scala-Wicket-Extensions-Project-tp24975011p25378371.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Turning off ModificationWatcher
Fixed as of Wicket 1.4.0-RC6. "now uses an interface. you may use IResourceSettings.setResourceWatcher() to set whatever IModificationWatcher you want " cretzel wrote: > > Posted https://issues.apache.org/jira/browse/WICKET-2340 > https://issues.apache.org/jira/browse/WICKET-2340 > > > igor.vaynberg wrote: >> >> or you can add an rfe into jira to make it more open... >> >> -igor >> > > -- View this message in context: http://www.nabble.com/Turning-off-ModificationWatcher-tp22963478p24301752.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Turning off ModificationWatcher
Posted https://issues.apache.org/jira/browse/WICKET-2340 https://issues.apache.org/jira/browse/WICKET-2340 igor.vaynberg wrote: > > or you can add an rfe into jira to make it more open... > > -igor > -- View this message in context: http://www.nabble.com/Turning-off-ModificationWatcher-tp22963478p24167315.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Turning off ModificationWatcher
This way you won't get no exceptions any more, but it's also terrible to develop without ModificationWatching. GAE does not allow spawning threads even in the local development environment. I tried to use my own implementation of a modification watcher, that does not spawn any threads but instead it does the modification watching before every request. Unfortunately it's not possible to replace the default ModificationWatcher in Wicket, because it's got dependencies to the concrete default ModificationWatcher and that is final, so you can't replace it with another implementation. You can work around this by doing some classpath messing and put your own ModificationWatcher implementation in your project into same package org.apache.wicket.util.watch of the Wicket ModificationWatcher see http://kimenye.blogspot.com/2009/06/google-app-engine-wicket.html here . Would be nice if Wicket relied on an interface IModificationWatcher in future versions, so that it can be replaced by a customized version. Or don't make it final. - cretzel Jonathan Locke wrote: > > > not sure, but try getResourceSettings().setResourcePollFrequency(null) in > your app init > > > Matt Welch wrote: >> >> I'm experimenting with Wicket inside Google's new Java support for its >> App >> Engine. My simple apps run fine if the configuration is set to >> DEPLOYMENT, >> however in development mode, I get an exception related to >> ModificationWatcher. Looking at the exception I think this >> ModificationWatcher is being used as part of a new thread which is a >> no-no >> inside the App Engine sandbox. Is there way way to just disbable this >> modification watcher without putting the entire app in deployment mode? >> There are a number of items I like about development mode but this one >> glitch is preventing me from using it. >> >> Matt >> >> > > -- View this message in context: http://www.nabble.com/Turning-off-ModificationWatcher-tp22963478p24099680.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Factory for Components
My primary reason is to be able to substitute another (improved) version for this component. For example, if we have a simple custom DropDown and we instantiate it by calling new DropDown() all over in the code it might be difficult, to replace that by a new version, e.g. DropDownWithCrazyAjaxEffects. If we have a factory, we'd have just one place where the component is created. Andreas Petersson wrote: > > > > On Fri, 24 Apr 2009 13:39:35 +0200, Martijn Dashorst > wrote: >> In what way is MyConvolutedComponentFactory.createNewMyComponent() >> better than "new MyComponent()"? >> > > ideas that come to my mind why to use this: > 0) you might be able to reduce generics cluttering by using > TextField = MyConvolutedComponentFactory.createTextField(model); > with public static TextField createTextField(IModel model); > 1) be able to use AOP on components (guice). for example use > @Transactional > on onClick method to tightly specify transaction boundaries. > 2) you might be able to reuse (immutable,stateless) components > 3) you might be able to chose any subtype of component depending on the > provided parameters > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > > -- View this message in context: http://www.nabble.com/Factory-for-Components-tp23212875p23217029.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Factory for Components
We are using Spring. Liam Clarke-Hutchinson-3 wrote: > > Are you using an IoC container at all? > > On 4/24/09, Nick Wiedenbrück wrote: >> Hi, >> >> I'm having many Components (DropDowns, ChoiceRenderers, ...) that are >> reused >> in different places in my application. For example I have one >> ChoiceRenderer for persons, one for accounts and so on. I want to >> centralize the creation of these components in a factory in order to >> decople >> the clients. For example I'm thinking about a ChoiceRendererFactory with >> methods createPersonChoiceRenderer() and createAccountChoiceRenderer(). >> >> Now, my question is where to put this factory. I need a central place, >> where >> the can find the factory. Is it a good idea to have a method >> createChoiceRendererFactory() on my Application class? >> >> Regards, >> Nick >> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > > -- View this message in context: http://www.nabble.com/Factory-for-Components-tp23212875p23216937.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: IDataProvider/LoadableDetachableModel for indexed lists
igor.vaynberg wrote: > > class addressmodel extends ldm { > private final int idx; > private final imodel customer; > public addressmodel(imodel customer, address address) { >this.customer=customer; >this.idx=customer.getaddresses().indexof(address); > } > ... > Nice. Thanks igor. Wouldn't you care about the performance of List.indexOf()? What about using just the index as a parameter instead of the adress? That would imply a different IDataProvider like this: public AdressDataProvider(IModel customerModel) { this.customerModel = customerModel; } public Iterator iterator(final int first, final int count) { return new Iterator() { private int i; public boolean hasNext() { return i < first + count; } public Integer next() { return i++; } public void remove() { } }; } public IModel model(final Object object) { final Integer index = (Integer) object; return new AdressModel(customerModel, index); } Although kind of weird, this way you would not have to determine the index by calling indexOf(). What do you think? By the way, is there a shorter way of getting an iterator over an Integer range? -- View this message in context: http://www.nabble.com/IDataProvider-LoadableDetachableModel-for-indexed-lists-tp21011916p21031001.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
IDataProvider/LoadableDetachableModel for indexed lists
Hi, what's the best way to implement an IDataProvider and a LoadableDetachable for an indexed list? Suppose I have a Customer who has a list of Adresses. class Customer { List adresses; } Now I want to implement a data provider/ldm for the adresses of a customer. I suppose the usual way is an IDataProvider as an inner class which refers to the customer model of the component, like: class AdressDataProvider implements IDataProvider { public Iterator iterator() { Customer c = (Customer)Component.this.getModel(); // somehow get the customer model return c.getAdresses().iterator(); } public IModel model(Object o) { Adress a = (Adress) o; // Return an LDM which loads the adress by id. return new AdressLoadableDetachableModel(a.getId()); } } Question: How would I implement this, when the adress does not have an ID (e.g. it's a Hibernate Embeddable/CollectionOfElements) but can only be identified by its index in the customer.adresses list? How do I keep reference to the owning entity and the index? In fact, I know a solution, but I wonder if there's a common pattern to do this. -- View this message in context: http://www.nabble.com/IDataProvider-LoadableDetachableModel-for-indexed-lists-tp21011916p21011916.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: JavaScript onChange after onClick
Hi Timo, thanks for that hint. Actually, we didn't prove these issues. We should give it a try ... Thanks Timo Rantalaiho wrote: > > Hello, > > Great that you could solve your issue, but I'll comment on a > couple of things anyway. > > On Wed, 16 Jul 2008, cretzel wrote: >> We are doing validation via Ajax, so we decided to not to validate on >> each >> key press because of performance issues. > > Have you proved empirically (load testing, profiling or > something such) that this would cause performance issues? > Because ajax validation on each keypress is a very common > place to start premature optimisation when starting to do > more responsive user interfaces; I've seen many people fall > into that trap, myself included :) > >> > And yet another possibility is to add the extra check in >> > the Button event handler... and just run the validation >> > manually from there before submit if needed. >> > >> We are doing validation on each text field to give feedback as soon as >> possible, so this is not an option. > > I actually thought that this would have been only an extra > validation round in addition to the normal one. > > But if you could get the events come always in right order, > great! > > Best wishes, > Timo > > -- > Timo Rantalaiho > Reaktor Innovations Oyhttp://www.ri.fi/ > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/JavaScript-onChange-after-onClick-tp18467010p18564659.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JavaScript onChange after onClick
Okay, sorry, this wasn't really a Wicket-Problem but an IE-Problem. The Button in my application is actually a div and IE has problems to focus() divs (sometimes), so that when clicking the div, the focus is not removed from the text field and no onchange-event is fired. I managed it by giving the button div a tabIndex="0" attribute on in its onclick I call this.focus(). Then it works (even in IE). cretzel wrote: > > Hi, > > I'm having a problem regarding JavaScript/Ajax and I'm not sure if it's > actually related to Wicket. > > I've got a Button and a TextField within a Form. The TextField uses an > AjaxUpdatingBehavior for validation, which is fired "onchange". The Button > submits the form via Ajax "onclick". In my case, sometimes the onchange > event occurs after the onclick event (on the clientside), which causes > problems. This is only a problem in IE(6) and not in FF. In FF the > onchange event always occurs before the onclick event. And even in IE in > simple examples I could never get the onchange event to occur after the > onclick. So my question is, if this could have something to do with > wicket's ajax JavaScript. > > Regards > -- View this message in context: http://www.nabble.com/JavaScript-onChange-after-onClick-tp18467010p18525139.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JavaScript onChange after onClick
Hi Timo, thanks for your reply. > Anyway, if your intent to only validate when the textfield > loses focus? If it would be OK to validate on each keypress, > you could try using OnChangeAjaxBehavior in the TextField. > We are doing validation via Ajax, so we decided to not to validate on each key press because of performance issues. > Another possibility would be to disable the submit button > until the validation does not pass -- but then if you want > to click the button directly when the focus is still on the > field, it gets kind of clumsy. > This would also mean, that the user first has to leave a text field (to trigger validation) before she could submit the form. > And yet another possibility is to add the extra check in > the Button event handler... and just run the validation > manually from there before submit if needed. > We are doing validation on each text field to give feedback as soon as possible, so this is not an option. Timo Rantalaiho wrote: > > Are you sure that it always works in Firefox? Sounds like it > could be a race condition. People who know Javascript and > HTML better than me have told me that the browser event > model is not too well defined. > > Anyway, if your intent to only validate when the textfield > loses focus? If it would be OK to validate on each keypress, > you could try using OnChangeAjaxBehavior in the TextField. > > Another possibility would be to disable the submit button > until the validation does not pass -- but then if you want > to click the button directly when the focus is still on the > field, it gets kind of clumsy. > > And yet another possibility is to add the extra check in > the Button event handler... and just run the validation > manually from there before submit if needed. > > Best wishes, > Timo > > -- > Timo Rantalaiho > Reaktor Innovations Oyhttp://www.ri.fi/ > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/JavaScript-onChange-after-onClick-tp18467010p18481468.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JavaScript onChange after onClick
Hi, I'm having a problem regarding JavaScript/Ajax and I'm not sure if it's actually related to Wicket. I've got a Button and a TextField within a Form. The TextField uses an AjaxUpdatingBehavior for validation, which is fired "onchange". The Button submits the form via Ajax "onclick". In my case, sometimes the onchange event occurs after the onclick event (on the clientside), which causes problems. This is only a problem in IE(6) and not in FF. In FF the onchange event always occurs before the onclick event. And even in IE in simple examples I could never get the onchange event to occur after the onclick. So my question is, if this could have something to do with wicket's ajax JavaScript. Regards -- View this message in context: http://www.nabble.com/JavaScript-onChange-after-onClick-tp18467010p18467010.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OpenSessionInView (OSIV), LoadableDetachableModel and Transactions
you are right. That's the reason of using OSIV, although these two concepts are somewhat related to each other. I mean, when you are not using OSIV, you have to collect all the data you want to display on the presentation tier within a facade, for example. One possiblity is then to (Hibernate-)initialize all needed entities and expose the domain model to the presentation tier, the other one is using DTOs that carry the data. igor.vaynberg wrote: > > no, the point of osiv is that you can use the beans you loaded even > after the transactions has ended without getting lazyload exceptions. > it has nothing to do with writing changes or not having to use dtos. > Anyway, igor.vaynberg wrote: > >> map a form to a bean and apply the changes to the entity yourself > is quite the same as writing DTOs, isn't it? -- View this message in context: http://www.nabble.com/OpenSessionInView-%28OSIV%29%2C-LoadableDetachableModel-and-Transactions-tp18115802p18140832.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OpenSessionInView (OSIV), LoadableDetachableModel and Transactions
jwcarman wrote: > > Are you positive that hibernate will write this data to the session? > The default flush mode of Spring's OpenSessionInViewFilter is "NEVER": > > ... you retrieve it using a DAO/Repository with a transaction demarcation > of readOnly/required ... > yeah, that's right. But there are some use cases where Hibernate *will* flush. For example Hibernate will flush when calling a service method (not read-only) that for some reason decides not to save the user, e.g. public void checkAndSaveUser(User u) { if (user.getUsername().length() > 3) saveOrUpdate(u); } This will flush at the end of the transaction. Another situation is where you start multiple transaction, e.g. to register a user to different groups. public void onSubmit() { User user = (User) getModelObject(); for (Group group : user.getGroups()) { service.registerUserForGroup(user, group); } } I agree, these might be some strange examples. But the point is, if you don't want changes to be persisted, you have to take care that between the beginning and the end of the request there are no (non-read-only) transactional service methods called. [As mentioned, the OSIV-Filter defaults to FlushMode.NEVER, so it won't flush by itself]. Another possibility is to use Wicket's validation capabilities, as Igor mentioned. Unlike other frameworks (I think Spring MVC is an example), Wicket validators get called before anything is written in to the model objects. So it's okay to call service methods from those validators. -- View this message in context: http://www.nabble.com/OpenSessionInView-%28OSIV%29%2C-LoadableDetachableModel-and-Transactions-tp18115802p18140556.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OpenSessionInView (OSIV), LoadableDetachableModel and Transactions
Thanks for the immediate replies. Seems that, when using that pattern, one really always has to be aware of the fact that changes are made directly to persistent instances. Otherwise it could easily happen to get inconsistent data into the DB. Michael Sparer wrote: > > I'd say either enable transactions only for write operations or put all > together in one transaction (i.e. don't let hibernate flush the session > before you did your backend checks) ... > This works if each request is a single transaction. If multiple transactions are run in one request, this wouldn't help, I think. igor.vaynberg wrote: > > map a form to a bean and apply the changes to the entity yourself or do > all validation via I(Form)Validators > The first solution sounds like using DTOs and one reason of using OSIV is to not to have to use DTOs. But I like the FormValidator solution. That should work in most cases. Regards -- View this message in context: http://www.nabble.com/OpenSessionInView-%28OSIV%29%2C-LoadableDetachableModel-and-Transactions-tp18115802p18129013.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
OpenSessionInView (OSIV), LoadableDetachableModel and Transactions
Hi, I'm using Wicket together with Spring and Hibernate. And it's quite common, I think, to use an OpenSessionInViewFilter and a LoadableDetachableModel which wraps the domain objects loaded with Hibernate, so that when the model is detached it only holds the ID of the domain object and when its load()-method is called it uses the ID to load the entity again from the database (see http://www.nabble.com/How-to-avoid-Lazy-loading-exception-td17040941.html#a17041351 this post for an example). So one advantage of this pattern is that you mainly never get into problems with detached entities (LazyInitializingException and so on). I only got one issue with this when using Spring's transaction support. Suppose you are editing a domain object in a form and you submit the form and it passes conversion and validation. Actually the changes you've made have been written into the domain object when you are in onSubmit() for example. Then in this situation these changes could easily get persistet to the DB, even if you don't want them to at this point, e.g. because you want to do some backend validation first. This can happen when Hibernate flushes the session, for example before another query. The problem is that the changes on the domain object are made outside of a transaction [OpenSessionInViewFilter just opens a Session but doesn't start a transaction]. An example: Suppose you are editing an entity User, changing the username for example. The onSubmit()-method could look like this: onSubmit() { // User with changed username, attached to the Session User user = (User) getModelObject(); // Do a query. This will cause the changes made to user // to be flushed to the DB userService.getUsers(); // This method does some backend validation, possibly // fails and the transaction is rolled back so that the // changes should not be persisted userService.saveUser(user); } After this, the changes could be persistent in the DB, although they shouldn't because the validation in the backend failed which should have rolled back the changes. I hope I made clear the point. What do you think? -- View this message in context: http://www.nabble.com/OpenSessionInView-%28OSIV%29%2C-LoadableDetachableModel-and-Transactions-tp18115802p18115802.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]