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

Reply via email to