You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Ilya Obshadko <il...@gmail.com> on 2015/07/25 14:16:30 UTC
decoupling business logic and frontend
At this moment, my own project has grown big enough, so I've started to
consider delegating various parts of the workload to others.
However, there is one particular issue: when the whole thing is built on
Tapestry, any person involved should understand the framework, and it's not
possible to isolate frontend tasks from backend ones (because all the
Tapestry "endpoints" are in fact event handlers and all AJAX requests are
handled through usual event processing chain).
One obvious solution is Tapestry+RestEASY (or any other similar REST
module) and moving all controller logic to JS on the frontend and to REST
handlers on the backend. This way pages/components are becoming just
"stubs" that initialize required HTML/JS.
Any other thoughts maybe?
--
Ilya Obshadko
Re: decoupling business logic and frontend
Posted by "mailinglist@j-b-s.de" <ma...@j-b-s.de>.
I go with Thiago.
We use different maven modules for our business logic and persistence classes so both maven modules are standalone using their own tests. There is no relation to Tapestry at all for these modules.
We use Tapestry services and Tapestry IOC to tie it together in our webapps
We even use these budinesslogic in non Tapestry war's e.g to support cron based jobs in parallel or reuse the backend services in different Tapestry Apps. I do not see any reason to use a remote connection, beside you have different life cycles for these modules and deployment is out of your control
Jens
Von meinem iPhone gesendet
> Am 27.07.2015 um 14:56 schrieb Thiago H de Paula Figueiredo <th...@gmail.com>:
>
> Hi!
>
>> On Sat, 25 Jul 2015 09:16:30 -0300, Ilya Obshadko <il...@gmail.com> wrote:
>>
>>
>> However, there is one particular issue: when the whole thing is built on
>> Tapestry, any person involved should understand the framework, and it's not possible to isolate frontend tasks from backend ones (because all the
>> Tapestry "endpoints" are in fact event handlers and all AJAX requests are
>> handled through usual event processing chain).
>
> I'm not sure I can agree with you. Business logic is supposed to be written inside Tapestry-IoC services, so people working on them only need to know T-IoC basics, which are very simple, so you can easily create tasks that don't need any knowledge at all on Tapestry-core (the web framework).
>
> --
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: decoupling business logic and frontend
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
Hi!
On Sat, 25 Jul 2015 09:16:30 -0300, Ilya Obshadko
<il...@gmail.com> wrote:
>
> However, there is one particular issue: when the whole thing is built on
> Tapestry, any person involved should understand the framework, and it's
> not possible to isolate frontend tasks from backend ones (because all the
> Tapestry "endpoints" are in fact event handlers and all AJAX requests are
> handled through usual event processing chain).
I'm not sure I can agree with you. Business logic is supposed to be
written inside Tapestry-IoC services, so people working on them only need
to know T-IoC basics, which are very simple, so you can easily create
tasks that don't need any knowledge at all on Tapestry-core (the web
framework).
--
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: decoupling business logic and frontend
Posted by Ilya Obshadko <il...@gmail.com>.
Thanks Chung,
That seems very close to the solution I was looking for.
On Sat, Jul 25, 2015 at 3:54 PM, Chung Khanh Duy <
chungkhanhduy1985@gmail.com> wrote:
> Hi,
>
> I suggest Tapestry+RestEasy+AngularJS. AngularJS is powerful MVC font-end
> framework. Moreover you should research to try integrate bower grunt in
> your project. Bower is used to pull necessary third party js go with
> angular and grunt is used for building css based on sass.
>
> So the final project structure should be: Tapestry+RestEasy+AnguarJS +
> Bower + Grunt and Gradle.
>
> Here is the link about demo to integrate angularjs into tapestry + restful
> web service: https://github.com/ffacon/tapestry5-angular-demo
>
> Hopefully it can help.
>
> Duy
>
>
> On Sat, Jul 25, 2015 at 7:16 PM, Ilya Obshadko <il...@gmail.com>
> wrote:
>
> > At this moment, my own project has grown big enough, so I've started to
> > consider delegating various parts of the workload to others.
> >
> > However, there is one particular issue: when the whole thing is built on
> > Tapestry, any person involved should understand the framework, and it's
> not
> > possible to isolate frontend tasks from backend ones (because all the
> > Tapestry "endpoints" are in fact event handlers and all AJAX requests are
> > handled through usual event processing chain).
> >
> > One obvious solution is Tapestry+RestEASY (or any other similar REST
> > module) and moving all controller logic to JS on the frontend and to REST
> > handlers on the backend. This way pages/components are becoming just
> > "stubs" that initialize required HTML/JS.
> >
> > Any other thoughts maybe?
> >
> > --
> > Ilya Obshadko
> >
>
>
>
> --
> Chung Khánh Duy
> Project Support Manager
> Formos
>
--
Ilya Obshadko
Re: decoupling business logic and frontend
Posted by Chung Khanh Duy <ch...@gmail.com>.
Hi,
I suggest Tapestry+RestEasy+AngularJS. AngularJS is powerful MVC font-end
framework. Moreover you should research to try integrate bower grunt in
your project. Bower is used to pull necessary third party js go with
angular and grunt is used for building css based on sass.
So the final project structure should be: Tapestry+RestEasy+AnguarJS +
Bower + Grunt and Gradle.
Here is the link about demo to integrate angularjs into tapestry + restful
web service: https://github.com/ffacon/tapestry5-angular-demo
Hopefully it can help.
Duy
On Sat, Jul 25, 2015 at 7:16 PM, Ilya Obshadko <il...@gmail.com>
wrote:
> At this moment, my own project has grown big enough, so I've started to
> consider delegating various parts of the workload to others.
>
> However, there is one particular issue: when the whole thing is built on
> Tapestry, any person involved should understand the framework, and it's not
> possible to isolate frontend tasks from backend ones (because all the
> Tapestry "endpoints" are in fact event handlers and all AJAX requests are
> handled through usual event processing chain).
>
> One obvious solution is Tapestry+RestEASY (or any other similar REST
> module) and moving all controller logic to JS on the frontend and to REST
> handlers on the backend. This way pages/components are becoming just
> "stubs" that initialize required HTML/JS.
>
> Any other thoughts maybe?
>
> --
> Ilya Obshadko
>
--
Chung Khánh Duy
Project Support Manager
Formos
Re: decoupling business logic and frontend
Posted by Ilya Obshadko <il...@gmail.com>.
On Sat, Jul 25, 2015 at 3:55 PM, Dmitry Gusev <dm...@gmail.com>
wrote:
You may be mixing "business logic" with tapestry's page/component classes.
>
No, that's not the case actually.
> You shouldn't put any business logic to the presentation layer
> (which is TMLs and page/component java classes).
>
Even if business logic is completely moved to service layer, that doesn't
solve the problem of exposing other potential developers to Tapestry (which
is undesired). Using Angular + RESTEasy does look like a good solution here
(I was thinking of something similar).
> All logic should be extracted to tapestry services, or even EJB as in the
> JumpStart examples:
> http://jumpstart.doublenegative.com.au/jumpstart/examples/state/atejb
>
> If you don't like tapestry services nor EJB, then nothing really stops you
> from wrapping your tapestry services or EJBs with REST API and creating
> client API
> that will be consumed from tapestry page/component classes.
>
> With this approach you may develop backend separately from backend.
>
> If you're going to deploy your app as a single monolith app you
> can move your BL to tapestry services and that's it -- you don't need to
> create
> any API between them if they live in the same JVM.
>
> You may even package you services in a separate JAR containing tapestry
> modules
> and add these JARs to your frontend app.
>
> If you want to deploy them separately -- you obviously need some
> communication protocol,
> like REST or EJB. In this case you may continue using tapestry+tynamo
> resteasy to implement your services,
> but it could be any other technology stack, like Spring Boot or anything
> else.
>
> I'd also advise you to think of splitting your app not by layers (frontend
> vs. business logic),
> but using functional aspects, each function would include both frontend &
> backend and be sufficient by itself.
> For example, you may extract part of your pages into a separate tapestry
> app and run it next to your "main" app,
> maybe even in the same JVM, or package these apps all together during build
> time into one monolith.
>
> As you see there are many options.
> You need to decide how are you going to deploy resulting app(s).
>
> General advise here may be that one deployable unit should have one
> dedicated team of developers
> who are responsible for that unit.
>
> Unless this is a really simple service that once developed & deployed stays
> untouched,
> otherwise I don't think you'll have any benefits from delegating your
> workload.
>
> On Sat, Jul 25, 2015 at 3:16 PM, Ilya Obshadko <il...@gmail.com>
> wrote:
>
> > At this moment, my own project has grown big enough, so I've started to
> > consider delegating various parts of the workload to others.
> >
> > However, there is one particular issue: when the whole thing is built on
> > Tapestry, any person involved should understand the framework, and it's
> not
> > possible to isolate frontend tasks from backend ones (because all the
> > Tapestry "endpoints" are in fact event handlers and all AJAX requests are
> > handled through usual event processing chain).
> >
> > One obvious solution is Tapestry+RestEASY (or any other similar REST
> > module) and moving all controller logic to JS on the frontend and to REST
> > handlers on the backend. This way pages/components are becoming just
> > "stubs" that initialize required HTML/JS.
> >
> > Any other thoughts maybe?
> >
> > --
> > Ilya Obshadko
> >
>
>
>
> --
> Dmitry Gusev
>
> AnjLab Team
> http://anjlab.com
>
--
Ilya Obshadko
Re: decoupling business logic and frontend
Posted by Dmitry Gusev <dm...@gmail.com>.
Hi,
You may be mixing "business logic" with tapestry's page/component classes.
You shouldn't put any business logic to the presentation layer
(which is TMLs and page/component java classes).
All logic should be extracted to tapestry services, or even EJB as in the
JumpStart examples:
http://jumpstart.doublenegative.com.au/jumpstart/examples/state/atejb
If you don't like tapestry services nor EJB, then nothing really stops you
from wrapping your tapestry services or EJBs with REST API and creating
client API
that will be consumed from tapestry page/component classes.
With this approach you may develop backend separately from backend.
If you're going to deploy your app as a single monolith app you
can move your BL to tapestry services and that's it -- you don't need to
create
any API between them if they live in the same JVM.
You may even package you services in a separate JAR containing tapestry
modules
and add these JARs to your frontend app.
If you want to deploy them separately -- you obviously need some
communication protocol,
like REST or EJB. In this case you may continue using tapestry+tynamo
resteasy to implement your services,
but it could be any other technology stack, like Spring Boot or anything
else.
I'd also advise you to think of splitting your app not by layers (frontend
vs. business logic),
but using functional aspects, each function would include both frontend &
backend and be sufficient by itself.
For example, you may extract part of your pages into a separate tapestry
app and run it next to your "main" app,
maybe even in the same JVM, or package these apps all together during build
time into one monolith.
As you see there are many options.
You need to decide how are you going to deploy resulting app(s).
General advise here may be that one deployable unit should have one
dedicated team of developers
who are responsible for that unit.
Unless this is a really simple service that once developed & deployed stays
untouched,
otherwise I don't think you'll have any benefits from delegating your
workload.
On Sat, Jul 25, 2015 at 3:16 PM, Ilya Obshadko <il...@gmail.com>
wrote:
> At this moment, my own project has grown big enough, so I've started to
> consider delegating various parts of the workload to others.
>
> However, there is one particular issue: when the whole thing is built on
> Tapestry, any person involved should understand the framework, and it's not
> possible to isolate frontend tasks from backend ones (because all the
> Tapestry "endpoints" are in fact event handlers and all AJAX requests are
> handled through usual event processing chain).
>
> One obvious solution is Tapestry+RestEASY (or any other similar REST
> module) and moving all controller logic to JS on the frontend and to REST
> handlers on the backend. This way pages/components are becoming just
> "stubs" that initialize required HTML/JS.
>
> Any other thoughts maybe?
>
> --
> Ilya Obshadko
>
--
Dmitry Gusev
AnjLab Team
http://anjlab.com