Hi Daniel, not quite sure what exactly you mean by Controller but it sounds like what you would do in a Tapestry Page or Component class. If so, I'd pack that with the webui stuff. @CommitAfter will work on Tapestry Page and Component Methods. The last project I set up had the following division:
- model (only Entities) - dao (only Dao's and Entity related utility) - webapp (application specific tapestry pages, components and services) - tapestry-utility (general tapestry components and services) - various java utility modules I hope this helps. Best Regards, Wulf -----Original Message----- From: Poggenpohl, Daniel [mailto:daniel.poggenp...@isst.fraunhofer.de] Sent: Mittwoch, 22. April 2015 15:53 To: Tapestry users Subject: AW: AW: Splitting a tapestry web app into modules Hello, I'm gonna pick up this strand because more problems seem to arise when splitting the application... Okay, right now I have 5 modules/projects: 1) model (the data model for the application; annotated using the Bean Validation API) 2) dao-interfaces (the DAO interface layer for the data model) 3) dao-hibernate (the DAO interface implementation, name is probably not right because I don't use Hibernate-specific stuff right now...) 4) webui (containing Tapestry pages, components etc.) 5) controller (at the moment processes methods like resetTestdata, which clears the database and stores the testdata) Dependencies are: dao-interfaces -> model dao-hibernate -> dao-interfaces, model controller -> dao-interfaces, model webui -> controller, model Several things: a) I have problems making appropriate splits or rather putting code in the right module. What I do at the moment is coding a page, and when an entity is needed, I call the controller to fetch the entity. The controller uses a DAO object to fetch the entity and returns the entity to the webui. In a single module tapestry web application, I declared the DAO layer to be services in the AppModule. Then I could inject the DAO class into a page or component and queried for the entity directly. How do I do this with a controller doing the fetching? Do I declare the controller as a service? b) The persistence.xml is still placed in the webui module, isn't it? My first instinct was to place it in the "model" module, but now I'm not sure... c) Say I click a button on a page. Doing this ultimately changes the state of an entity in the database. - The e.g. ActionLink method onActionFromButton() calls the Controller method doStuff(Entity toSomeEntity). - The Controller changes the entity and then updates the database to reflect the changes using the DAO interfaces. - The Controller then returns the changed entity to the webui. - The webui receivers the entity and reloads the page or updates the zone or whatever. Before splitting, my DAO interface methods always were annotated with @CommitAfter. First, to be generic with my DAO interfaces, I can't use @CommitAfter on them, because then I'd need a dependency to tapestry-jpa. Second, I've read that having a controller, it is always more logical to commit after the end of the controller method, as this is a more logical point in time. So do I add the tapestry-jpa dependency to my controller methods? And what then? Do I have to register my controller as a service with Tapestry? Hope you can help me, as I'm a little bit confused. Regards, Daniel P. -----Ursprüngliche Nachricht----- Von: Thiago H de Paula Figueiredo [mailto:thiag...@gmail.com] Gesendet: Donnerstag, 16. April 2015 18:08 An: Tapestry users Betreff: Re: AW: Splitting a tapestry web app into modules On Thu, 16 Apr 2015 11:09:53 -0300, Poggenpohl, Daniel <daniel.poggenp...@isst.fraunhofer.de> wrote: > Hello again, > > I think I understand now. > > The only problem I see at the moment is that once I split the app into > model and tapestry app, I can't use e.g. @NonVisual or @Validate > anymore because those are Tapestry-specific. Or could I add a > dependency to the annotation packages? If the model would be used in a > non-Tapestry application, the annotations would be ignored, wouldn't they? These annotations are in the tapestry5-annotations package, not tapestry-core, so you can add a tapestry5-annotations depenency to your non-web packages/modules/projects without bringing the web-related classes (i.e. tapestry-core). -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org