Send us a link, when you do :) On Aug 30, 2012, at 6:49 PM, Juan José Gil wrote:
> sorry, where says "bog" its "blog" :S > > 2012/8/30 Juan José Gil <[email protected]> > >> Understood :) >> >> Thanks for such great guidelines! >> >> I'll see if it is possible to bog about vaadin & cayenne integration :) >> >> Regards >> Juanjo >> >> 2012/8/30 Andrus Adamchik <[email protected]> >> >>> In your app please keep using Guice. >>> >>> Cayenne DI (which is strongly inspired by Guice, but has much smaller >>> footprint) is intended for configuring stuff inside Cayenne. The container >>> itself is hidden inside CayenneRuntime and we are not promoting it for >>> general app-level use, even though in theory it should be possible. >>> >>> Andrus >>> >>> On Aug 30, 2012, at 4:13 PM, Juan José Gil wrote: >>> >>>> thanks Andrus! >>>> >>>> I'll give it a try :) >>>> >>>> which are the pros of using cayenne di instead of guice? (I've already >>>> worked on integrating guice + vaadin + shiro and I don't want to loose >>> all >>>> that effort :S) >>>> >>>> Regards >>>> Juanjo >>>> >>>> >>>> 2012/8/30 Andrus Adamchik <[email protected]> >>>> >>>>> 1. Serialization. There's not much to it really. Just make sure the >>>>> context you are using is session-scoped. See for instance this class >>> that >>>>> provides a session-bound context (used by CayenneFilter) : >>>>> >>>>> >>>>> >>> http://svn.apache.org/viewvc/cayenne/main/branches/STABLE-3.1/framework/cayenne-jdk1.5-unpublished/src/main/java/org/apache/cayenne/configuration/web/SessionContextRequestHandler.java?view=markup >>>>> >>>>> 2. Multi-tenancy... So if you go with DB-schema per tenant, it might >>> look >>>>> like this: >>>>> >>>>> // do it once per tenant, and cache the returned runtime in the app >>> scope >>>>> ServerRuntime createServerRuntime(final String tenantSchema) { >>>>> >>>>> // "cayenne-xyz.xml" is a mapping common to all tenants, that will be >>>>> further customized here >>>>> ServerRuntime runtime = new ServerRuntime("cayenne-xyz.xml", new >>>>> Module() { >>>>> >>>>> // in a custom module override the schema of all loaded DataMaps >>>>> public void configure(Binder binder) { >>>>> binder.bind(DataMapLoader.class).toInstance(new >>>>> TenantMapLoader(tenantSchema)); >>>>> } >>>>> }); >>>>> >>>>> >>>>> return runtime; >>>>> } >>>>> >>>>> class TenantMapLoader extends XMLDataMapLoader { >>>>> >>>>> private String tenantSchema; >>>>> >>>>> TenantMapLoader(String tenantSchema) { >>>>> this.tenantSchema = tenantSchema; >>>>> } >>>>> >>>>> >>>>> public DataMap load(Resource configurationResource) { >>>>> DataMap map = super.load(configurationResource); >>>>> map.setDefaultSchema(tenantSchema); >>>>> >>>>> for(DbEntity e : map.getDbEntities()) { >>>>> e.setSchema(tenantSchema); >>>>> } >>>>> >>>>> return map; >>>>> } >>>>> } >>>>> >>>>> Andrus >>>>> >>>>> >>>>> On Aug 29, 2012, at 4:15 PM, Juan José Gil wrote: >>>>> >>>>>> Thanks for the reply Andrus! >>>>>> >>>>>> Could you point me to docs/samples about ObjectContext Serialization & >>>>>> multi-tenant approaches you describe? >>>>>> >>>>>> About the"adding-metadata" part, I was thinking in adding constraints >>> in >>>>> a >>>>>> similar way to active-record in RoR or GORM in grails, but using code >>>>>> generation phases of cayenne. >>>>>> >>>>>> By now i'll use some kind of "typed" KVC delegating to cayenne the >>>>>> properties access and then providing some kind a "class metadata" >>> which >>>>> can >>>>>> be extended by subclasses... but i'll prefer the "code generation" >>> form, >>>>> so >>>>>> I can use IDEs capabilities. >>>>>> >>>>>> maybe I'll generate some "java code configuration" which then will be >>>>> used >>>>>> to generate final classes... it sounds as a mess but it could give >>> really >>>>>> nice possibilities! don't you think? >>>>>> >>>>>> if i get to somewhere with this approach I'll tell you :) >>>>>> >>>>>>> >>>>>>> >>>>>>>> the data objects will reside at the http session, and will be used >>>>>>> directly by the vaadin widgets, does this kind of cayenne data >>> objects >>>>>>> "use" could arrive with attaching/detaching problems? >>>>>>> >>>>>>> Shouldn't be a problem. You can store Cayenne objects in a session. >>> The >>>>>>> simplest way to avoid attach/detach issues is to have a >>> session-scoped >>>>>>> ObjectContext. Then it is serialized/deserialized together with the >>>>> objects >>>>>>> in case the session is saved to disk, or replicated across the >>> cluster. >>>>>>> >>>>>>>> Also, is there a way to add metadata info in cayenne metamodel? I >>> would >>>>>>> like to add constraints / validations to generated classes, so they >>> can >>>>> be >>>>>>> used to define searching criterias on indexed attributes (something >>> like >>>>>>> active-records class filters, but only on indexed properties) and >>>>> generate >>>>>>> model validations on properties so they can be used at UI fields >>>>> directly, >>>>>>> facilitating the app development. >>>>>>> >>>>>>> You can add extra info using callbacks or lifecycle listeners. Any >>> extra >>>>>>> properties can be defined either manually in generated subclasses, or >>>>> even >>>>>>> stored in the base CayenneDataObject (with 'readProperty' / >>>>> 'writeProperty' >>>>>>> methods, and custom property names). >>>>>>> >>>>>>>> Finally, I'm looking for a multitenant implementation to use, and I >>>>>>> believe that the solution pointed at >>>>>>> >>>>> >>> http://blog.jerodsanto.net/2011/07/building-multi-tenant-rails-apps-with-postgresql-schemas/couldbealso >>> used with cayenne; is there any constraint I should look for? >>>>>>> >>>>>>> Cayenne is certainly friendly to various multi-tenancy approaches. In >>>>> 3.1 >>>>>>> API terms, you might assign a separate instance of ServerRuntime to >>> each >>>>>>> tenant, and use that to create ObjectContexts for its users. You may >>>>> start >>>>>>> all runtimes from the same basic configuration, and "namespace" them >>>>> using >>>>>>> tenant-unique DB URL. Or you may use a single DataSource, and after a >>>>>>> runtime is loaded, scan through all its DbEntities and assign a >>> tenant >>>>>>> "schema" to them. Feel free to ask about further details. >>>>>>> >>>>>>> Andrus >>>>>>> >>>>>>> >>>>>>> On Aug 26, 2012, at 5:15 PM, Juan J. Gil wrote: >>>>>>>> Hello, I'm thinking to use cayenne in conjunction with vaadin ( >>>>>>> http://vaadin.com). >>>>>>>> >>>>>>>> I'm trying to use some kind of tight integration between both >>>>> frameworks >>>>>>> (defining cayenne generated classes which are vaadin data models >>>>>>> implementations). >>>>>>>> That way I could define forms directly on data objects, querying & >>>>>>> mutating its state directly from vaadin widgets. >>>>>>>> As vaadin is an stateful web framework, should I have to expect for >>>>> some >>>>>>> kind of problem with data objects between requests? I mean, the data >>>>>>> objects will reside at the http session, and will be used directly by >>>>> the >>>>>>> vaadin widgets, does this kind of cayenne data objects "use" could >>>>> arrive >>>>>>> with attaching/detaching problems? >>>>>>>> >>>>>>>> Also, is there a way to add metadata info in cayenne metamodel? I >>> would >>>>>>> like to add constraints / validations to generated classes, so they >>> can >>>>> be >>>>>>> used to define searching criterias on indexed attributes (something >>> like >>>>>>> active-records class filters, but only on indexed properties) and >>>>> generate >>>>>>> model validations on properties so they can be used at UI fields >>>>> directly, >>>>>>> facilitating the app development. >>>>>>>> >>>>>>>> Finally, I'm looking for a multitenant implementation to use, and I >>>>>>> believe that the solution pointed at >>>>>>> >>>>> >>> http://blog.jerodsanto.net/2011/07/building-multi-tenant-rails-apps-with-postgresql-schemas/couldbealso >>> used with cayenne; is there any constraint I should look for? >>>>>>>> >>>>>>>> Best regards >>>>>>>> Juanjo >>>>>>>> >>>>>>>> ps: pardon my really poor English! :P >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>> >>> >>
