Mailing-List: contact users-help@isis.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@isis.apache.org
MIME-Version: 1.0
In-Reply-To: <a9dee12f-5953-838f-f9de-fec8fff5cd04@apache.org>
References: <a9dee12f-5953-838f-f9de-fec8fff5cd04@apache.org>
From: SE Song <sesong11@gmail.com>
Date: Mon, 27 Nov 2017 16:58:49 +0700
Message-ID: <CAGvS_CQ4bxpQq1_4UEUMgVWy2hzfkwb-KDpqMJDBKgQK-szFDg@mail.gmail.com>
Subject: Re: Customize UI behavior
To: users@isis.apache.org
Content-Type: multipart/alternative; boundary="001a1141b72eff1c2e055ef3f228"
archived-at: Mon, 27 Nov 2017 09:58:56 -0000

--001a1141b72eff1c2e055ef3f228
Content-Type: text/plain; charset="UTF-8"

Andi Huber You're the person I'm looking for, You save my life finally.
Thank you so much, I will follow your guide

On Mon, Nov 27, 2017 at 3:18 PM, Andi Huber <ahuber@apache.org> wrote:

> I'd like to share my experience with customized UI, ZK and Isis:
>
> We had to develop a simple questionnaire form, but we did not see an
> easy way of implementing it in Isis such that it would not confuse the
> arbitrary user, that has never seen Isis before. So we resorted to using
> the ZK framework.
>
>   * domain-war: web-archive where all the business logic domain objects
>     reside
>   * frontend-war: web-archive packaged with ZK that makes up the UI as
>     presented to the user
>
> On the domain side we define boundary classes like ...
>
> @DomainService(nature = NatureOfService.VIEW_REST_ONLY)
> public class FormBoundary {
>
>     @Inject private RepositoryService repository;
>
>     @Action
>     public List<Person> listPersons(){
>         return repository.allInstances(Person.class);
>     }
>
>     ...
>
> }
>
> On the frontend side we access these boundaries with the jax-rs 2.x
> client API.
>
> // home brew jax-rs client helper class, injected by JEE's CDI
> @Inject private JaxRSManager jax;
>
> public List<Person> listPersons(){
>     Response response =
>
> jax.request("services/domainapp.dom.boundary.FormBoundary/actions/
> listPersons/invoke")
>             .post(Entity.json("{}"));
>
>     return jax.digestList(response, Person.class)
>             .onFailure(this::onError)
>             .getOrElseGet(cause->null);
> }
>
> We then utilize ZK's facility of binding zul templates to java
> controllers, as explained here [1].
>
> Though I'm happy with the end-result (we can customize the look and feel
> however we want to), there is no longer the benefit of automated UI
> generation. You have to do every little piece by hand. This dramatically
> increases development time, which needs to be considered especially on
> larger projects.
>
> In retrospect, we could have saved some time by not separating domain
> from frontend, but instead putting Isis and ZK on the same web-app and
> access the boundary services from within ZK controllers directly via
>
> public class MyZKController {
>
>     // wraps the request in a transaction
>
>     public List<Person> listPersons(){
>
>      return IsisContext.getSessionFactory().doInSession(new
> Callable<List<Person>>() {
>         @Override
>         public List<Person> call() {
>
>             final FormBoundary formBoundary =
> IsisContext.getSessionFactory()
>                 .getServicesInjector().lookupService(FormBoundary.class);
>
>             return formBoundary.listPersons();
>         }
>     });
>
>    }
>
> }
>
> Note: FormBoundary is managed (life-cycled) by Isis and MyZKController
> is managed by ZK (ultimatively a servlet).
>
> However, I'm curious, what path you will take finally. ^^
>
> Regards, Andi.
>
> [1] http://books.zkoss.org/zk-mvvm-book/8.0/data_binding/index.html
>
>
>
>
>
>
>
>
>
>
>

--001a1141b72eff1c2e055ef3f228--