Hi,
we mostly use something like
com.company.app.tapestry.pages.user
com.company.app.tapestry.pages.messages
com.company.app.tapestry.components.user
com.company.app.tapestry.components.messages
so you see what the tapestry part is and could there choose from the domain
part.
Cheers,
Markus
Zitat von Vjeran Marcinko <[EMAIL PROTECTED]>:
> Hi everyone.
>
> I just wanna hear best practices for structuring Tapestry web apps.
> I have seen frequently around a structure "pages" and "components" packages
> like this:
>
> com.mycompany.myapp.tapestry.pages
> com.mycompany.myapp.tapestry.components
>
> Following the rule that app should be modularized by domain, and not
> underlying framework, we should have something like this if imagining that
> web is interacting with some domain logic having "users" and "messages"
> subdomains:
> com.mycompany.myapp.tapestry.users (contains all pages and components
> related to users)
> com.mycompany.myapp.tapestry.messages (contains all pages and components
> related to messages)
>
> Or something like this, that combines both, but granularity seems like
> overkill:
> com.mycompany.myapp.tapestry.users.pages
> com.mycompany.myapp.tapestry.users.components
> com.mycompany.myapp.tapestry.messages.pages
> com.mycompany.myapp.tapestry.messages.components
>
> Thoughts? Experiences?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
