[OT] Web apps should be structured to reflect domain?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[OT] Web apps should be structured to reflect domain?

Vjeran Marcinko
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?

-Vjeran



--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.322 / Virus Database: 266.11.14 - Release Date: 20.5.2005


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [OT] Web apps should be structured to reflect domain?

Markus Eberle
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 <[hidden email]>:

> 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: [hidden email]
For additional commands, e-mail: [hidden email]