isis-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andi Huber <ahu...@apache.org>
Subject Re: Customize UI behavior
Date Mon, 27 Nov 2017 08:18:40 GMT
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











Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message