Project Folder Structure ...

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

Project Folder Structure ...

Juan M Garrido de Paz
Hello...

how do you organize the packages/folders in your projects? (I mean other
than pages, components, mixins, services).

Due to tapestry force us to have separate pakages for pages, components,
etc... I guess we cannot (or shouldn't) organize the whole root package by
"features" of business layer. For example, for "employee" feature, I cannot
put a EmployeeGridDataSource in the page package with the pages of that
feature, because it is not a page.

In the project I'm developing now I have:

pages --> organized by "features" of the business layer
components
...
util
     encoders ---> date encoder, search criteria encoder, etc
     grid ---> for grid data sources and related classes (for example
pagination)
     select --> for custom implementations of certain select models
     viewobjects --> for example classes for store form fields, and classes
that convert them to dto objects for the business layer
     ...
     WebUtils.java --> static methods for general utilities concerned with
web layer
base
     AbstractBasePage.java --> pages inherit from it (attributes/services
like log, messages, etc)


Do you think this approach is ok?
Do you have any best practices or rules to organize better the project?

Inside each util subfolder, do you organize the classes by "feature"? Now I
don't, for example I have all the encoders mixed in the ecoder folder.

Thank you.
Reply | Threaded
Open this post in threaded view
|

Re: Project Folder Structure ...

Thiago H. de Paula Figueiredo
On Thu, 18 Aug 2016 17:43:07 -0300, Juan M Garrido de Paz  
<[hidden email]> wrote:

> Hello...

Hi!

> how do you organize the packages/folders in your projects? (I mean other
> than pages, components, mixins, services).
>
> Due to tapestry force us to have separate pakages for pages, components,
> etc... I guess we cannot (or shouldn't) organize the whole root package  
> by "features" of business layer. For example, for "employee" feature, I  
> cannot
> put a EmployeeGridDataSource in the page package with the pages of that
> feature, because it is not a page.

That's correct. Tapestry applies bytecode transformation to pages,  
components, mixins and classes in the 'base' packages, so it needs to know  
exactly in what packages these classes are.

One thing you haven't thought is that you don't need to have a single root  
package, so you can organize your sources, packages and classes by  
feature. You just need to treat each one as a separate component library,  
even if they're in the same project/source tree.  
https://tapestry.apache.org/component-libraries.html tells you how.

--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br

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

Reply | Threaded
Open this post in threaded view
|

Re: Project Folder Structure ...

Juan M Garrido de Paz
Thank you Thiago.

I knew there were the posibility to have several root packages, but never
looked into it to learn about it, and I didn't imagine it could be useful
for this purpose. You mean that each feature would have a root package
(feature = root package = "component library")? In this case each feature
have their own pages, components, etc (they dont have to be centralized)?

I've just realized that another way could be to organize my "util" package
directly by feature instead of encoders, grid, etc. What do you think about
this? It would be simplier than using "component-libraries"?

How do you organize your projects?

Thank you.


2016-08-18 23:40 GMT+02:00 Thiago H de Paula Figueiredo <[hidden email]>
:

> On Thu, 18 Aug 2016 17:43:07 -0300, Juan M Garrido de Paz <
> [hidden email]> wrote:
>
> Hello...
>>
>
> Hi!
>
> how do you organize the packages/folders in your projects? (I mean other
>> than pages, components, mixins, services).
>>
>> Due to tapestry force us to have separate pakages for pages, components,
>> etc... I guess we cannot (or shouldn't) organize the whole root package
>> by "features" of business layer. For example, for "employee" feature, I
>> cannot
>> put a EmployeeGridDataSource in the page package with the pages of that
>> feature, because it is not a page.
>>
>
> That's correct. Tapestry applies bytecode transformation to pages,
> components, mixins and classes in the 'base' packages, so it needs to know
> exactly in what packages these classes are.
>
> One thing you haven't thought is that you don't need to have a single root
> package, so you can organize your sources, packages and classes by feature.
> You just need to treat each one as a separate component library, even if
> they're in the same project/source tree. https://tapestry.apache.org/co
> mponent-libraries.html tells you how.
>
> --
> Thiago H. de Paula Figueiredo
> Tapestry, Java and Hibernate consultant and developer
> http://machina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Project Folder Structure ...

Thiago H. de Paula Figueiredo
On Thu, 18 Aug 2016 18:59:43 -0300, Juan M Garrido de Paz  
<[hidden email]> wrote:

> Thank you Thiago.

De nada! :D

> I knew there were the posibility to have several root packages, but never
> looked into it to learn about it, and I didn't imagine it could be useful
> for this purpose. You mean that each feature would have a root package
> (feature = root package = "component library")? In this case each feature
> have their own pages, components, etc (they dont have to be centralized)?

Yes, that's a way you can leverage library components to have a more  
flexible package structure, which seems to be the your goal here.

> I've just realized that another way could be to organize my "util"  
> package directly by feature instead of encoders, grid, etc. What do you  
> think about this? It would be simplier than using "component-libraries"?

I think it would work. It would be simpler than component libraries, with  
the downside of a feature's pages, components and mixins not being as  
close to their other classes of the same feature (such as ValueEncoders,  
Tapestry-IoC services, etc).

> How do you organize your projects?

It depends a lot on their size. Small ones can have everything in the same  
place. Larger ones would definitely be separated in component libraries,  
which would make the application way more modular. Setting up a component  
library is a one-time cost which can be done relatively quickly.

--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br

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

Reply | Threaded
Open this post in threaded view
|

Re: Project Folder Structure ...

Juan M Garrido de Paz
Hola Thiago...

maybe I will take a look some day to component libraries, sure it's the way
to go to have the whole app well organized by feature.

But by now, I think I will use the util package by feature, with the
downside of having pages, components,... separated. The problem, as always,
is time, and I think component libraries is too complicated to do it
quickly. My project is medium size.

Just one more question...

Do you think that it's ok to have (in the root package) a base package as I
have, containing "abstract page" to inherit from it the common services and
other stuff? and maybe another abstract classes for another types of
objects.

Thank you very much for your answers, and for the tip about the component
libraries (I think it's the right way to go, when I have time :D )

Bye.



2016-08-19 0:43 GMT+02:00 Thiago H de Paula Figueiredo <[hidden email]>:

> On Thu, 18 Aug 2016 18:59:43 -0300, Juan M Garrido de Paz <
> [hidden email]> wrote:
>
> Thank you Thiago.
>>
>
> De nada! :D
>
> I knew there were the posibility to have several root packages, but never
>> looked into it to learn about it, and I didn't imagine it could be useful
>> for this purpose. You mean that each feature would have a root package
>> (feature = root package = "component library")? In this case each feature
>> have their own pages, components, etc (they dont have to be centralized)?
>>
>
> Yes, that's a way you can leverage library components to have a more
> flexible package structure, which seems to be the your goal here.
>
> I've just realized that another way could be to organize my "util" package
>> directly by feature instead of encoders, grid, etc. What do you think about
>> this? It would be simplier than using "component-libraries"?
>>
>
> I think it would work. It would be simpler than component libraries, with
> the downside of a feature's pages, components and mixins not being as close
> to their other classes of the same feature (such as ValueEncoders,
> Tapestry-IoC services, etc).
>
> How do you organize your projects?
>>
>
> It depends a lot on their size. Small ones can have everything in the same
> place. Larger ones would definitely be separated in component libraries,
> which would make the application way more modular. Setting up a component
> library is a one-time cost which can be done relatively quickly.
>
> --
> Thiago H. de Paula Figueiredo
> Tapestry, Java and Hibernate consultant and developer
> http://machina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Project Folder Structure ...

Thiago H. de Paula Figueiredo
On Thu, 18 Aug 2016 20:54:49 -0300, Juan M Garrido de Paz  
<[hidden email]> wrote:

> Hola Thiago...

Olá! :)

> But by now, I think I will use the util package by feature, with the
> downside of having pages, components,... separated. The problem, as  
> always,
> is time, and I think component libraries is too complicated to do it
> quickly. My project is medium size.

Well, it isn't complicated in my humble opinion. After you do your first  
one, the others come easy and quick.

> Do you think that it's ok to have (in the root package) a base package  
> as I have, containing "abstract page" to inherit from it the common  
> services and other stuff? and maybe another abstract classes for another  
> types of
> objects.

That's exactly the [root package].base package reason exists, so yes. :)  
Just remember that everything that should be meant to be a superclass of  
pages, components or mixins. Anything else shouldn't be put in a  
Tapestry-controlled package, and 'base' is one of them.

> Thank you very much for your answers, and for the tip about the component
> libraries (I think it's the right way to go, when I have time :D )

My pleasure to help. :)

--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br

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