You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Juan M Garrido de Paz <ju...@gmail.com> on 2016/08/18 20:43:07 UTC
Project Folder Structure ...
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.
Re: Project Folder Structure ...
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Thu, 18 Aug 2016 20:54:49 -0300, Juan M Garrido de Paz
<ju...@gmail.com> 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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Project Folder Structure ...
Posted by Juan M Garrido de Paz <ju...@gmail.com>.
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 <th...@gmail.com>:
> On Thu, 18 Aug 2016 18:59:43 -0300, Juan M Garrido de Paz <
> juanm.garrido.paz@gmail.com> 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: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: Project Folder Structure ...
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Thu, 18 Aug 2016 18:59:43 -0300, Juan M Garrido de Paz
<ju...@gmail.com> 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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Project Folder Structure ...
Posted by Juan M Garrido de Paz <ju...@gmail.com>.
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 <th...@gmail.com>
:
> On Thu, 18 Aug 2016 17:43:07 -0300, Juan M Garrido de Paz <
> juanm.garrido.paz@gmail.com> 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: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: Project Folder Structure ...
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Thu, 18 Aug 2016 17:43:07 -0300, Juan M Garrido de Paz
<ju...@gmail.com> 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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org