We certainly will need some sort of lightweight MVC to help us process security, templating, etc....  I read that blog by sandoz a while ago, and just skimmed through it this time.

Especially with mobile apps the typical use case does play well with always linking to actions concept.  Your pages are more focused on a task, and getting something done. 

Just brainstorming through some things:

• What would the view files be represented as; JSP (like the blog), html, ruby, mixed?
  • This would need to handle model-value replacements
  • Or would the model just be made available as a JSON object in the view somehow?
• Would you want to explore the implicit or explicit approach first?
• I can see how security could link in with standard JAX-RS, but I still have questions around more app-based type auth.
  • Likely still a separate topic, but any MVC we think about will need a good way to manage access, and auth
• Does RESTEasy have the right hooks in place for this, and/or have they looked at anything like this?
• How would we handle more complex tablet, or desktop pages, and stay in scope with action concepts?
  • Perhaps something like the implicit sub-resource idea from the blog

It would be good to get this mapped out a little more.  How long would it take you for a PoC for something like this?

I like the idea Douglas. Curious if you have looked into the following?

It may be worthwhile to checkout:

a) "Htmleasy is a simple, elegant HTML based MVC micro-framework that builds on Resteasy (JAX-RS)." http://code.google.com/p/htmleasy/

b) This article which mentions tying into Spring MVC. http://www.dzone.com/links/r/integrating_jboss_resteasy_and_spring_mvc_an_intr.html

Or maybe we could provide the de-facto recommendation (quickstart) for using frameworks like backbone with resteasy?

http://stackoverflow.com/questions/8225928/resteasy-jettison-return-java-object-as-json-without-the-root-node

regardless, we can learn from POC'ing this idea.

Douglas Campos wrote:

 

It may be worthwhile to checkout:

a) "Htmleasy is a simple, elegant HTML based MVC micro-framework that builds on Resteasy (JAX-RS)." http://code.google.com/p/htmleasy/

That's the true spirit of what I've said on Moscow, good find!

This does look like a good find Wesley, at the very least an approach to review.

Hi,

I have some ideas about what a cool modern framework might look like using AJAX, REST and client templates. And most of the pieces are there already, waiting to be integrated.

The general idea is to all the dynamic rendering on the client, by serving only static HTML files and dynamic JSON content from the server.

JAX-RS does a great job at writing the backend, regardless of what other technos you use with it, and RESTEasy in particular supports two interesting features:

- A dynamic JavaScript API: http://docs.jboss.org/resteasy/docs/2.3.1.GA/userguide/html/AJAX_Client.html

- An Atom link injection facility: http://docs.jboss.org/resteasy/docs/2.3.1.GA/userguide/html/LinkHeader.html#d0e567

The first one allows you to do REST calls the boring way:

var orderJSON = Orders.getOrder({id: 23}); 
orderJSON.text == "hello";
Orders.putOrder({id: 23; $entity: orderJSON});

While the second allows for:

- Dynamic injection of Atom links into every returned entity, including collections and sub-entities

- Every JAX-RS resource that is relevant will have links injected automatically, while evaluating security constraints on the server to only inject links that the user has permission to invoke

For example you might get this sort of entity:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<collection xmlns:atom="http://www.w3.org/2005/Atom" totalRecords="2" start="0">
<atom.link href="http://localhost:8081/book/foo/comments" rel="add"/>
<atom.link href="http://localhost:8081/book/foo/comments" rel="list"/>
<comment xmlid="0">
  <text>great book</text>
  <atom.link href="http://localhost:8081/book/foo/comment/0" rel="self"/>
  <atom.link href="http://localhost:8081/book/foo/comment/0" rel="update"/>
  <atom.link href="http://localhost:8081/book/foo/comment/0" rel="remove"/>
  <atom.link href="http://localhost:8081/book/foo/comments" rel="add"/>
  <atom.link href="http://localhost:8081/book/foo/comments" rel="list"/>
</comment>
<comment xmlid="1">
  <text>terrible book</text>
  <atom.link href="http://localhost:8081/book/foo/comment/1" rel="self"/>
  <atom.link href="http://localhost:8081/book/foo/comment/1" rel="update"/>
  <atom.link href="http://localhost:8081/book/foo/comment/1" rel="remove"/>
  <atom.link href="http://localhost:8081/book/foo/comments" rel="add"/>
  <atom.link href="http://localhost:8081/book/foo/comments" rel="list"/>
</comment>
</collection>

This solves the following problems:

- Discovery of API

- Figuring out what your permissions are on the client while keeping security code on the server (you don't get the "remove" link if you can't remove it)

- Navigation

With these two integrated, we can imagine the client JS code to be such:

{code:javascript}
var order = Orders.getOrder({id: 23}); 
order.text == "hello";
order.save();
{code}

Now we can build on this using client templates such as Stamps.js (or anything really):

{code:javascript}
<ul>
 ~{list items: Orders.list(), var: 'order'}
  <li>
   Order ^{order.text}
   ~{if order.remove}
     <a href="#" onclick="`{order.remove}();">Remove</a>
   ~{/if}
  </li>
 ~{/list}
</ul>
{code}

This makes for really cool templating.

Now, in order to integrate this into a framework, we need additionnal goodies, such as a CRUD server component: https://github.com/lunatech-labs/play-module-resteasycrud/wiki

That module gives you a CRUD JAX-RS controller dynamically built for your entities:

- List entities, with paging, multi-column sorting and filtering

- Get/update/add/delete entities

- Autocomplete on custom fields

- Get a descriptor for the entity which tells you about validation constraints (JPA or BV), data types of every column, human-readable names, which column supports sorting, etc…

This sort of backend allows you to build generic client components that can be used as such:

{code:html}
 <table data-crud="^{orders.list.url}"></table>
{code}

And the table component would fetch the CRUD service descriptor, figure out the required columns, the ones that are sortable, which renderer/editor to use for each column, then fetch the data, check which cell is editable, which row supports which operation (delete/edit/clone, etc) and you get a dynamic table editor with zero JS code for the user, which works for every entity for which you have a CRUD REST service.

Building a nice smart-client web framework requires an integration of cool features such as these, but most of the pieces are already there.

First, thanks for posting this information, it is some really cool ideas!! 

I know you are a big fan of Play, and I have yet to really dig into it - I know shame on me :-(   Just to confirm many of your ideas are not tied to Play directly correct?  They all seem very JAX-RS & HTML based, which is good, although after a quick look the RESTEasy plugin seems to be play specific.  I've got nothing against play, but just want to be sure about the context.  Also what is the current status of the RESTEasy CRUD play module?  I see it has not been updated in a while.

I have reviewed the RESTEasy client library before, and had hoped to integrate it into our quickstart example, but decided to wait due to timing.  We should review that again for our efforts - I think it could help make client-server interaction easier which is a common goal with this. 

At the core of your suggestions there needs to be a central request dispatcher and approach for defining the pages, correct?  I believe this is what Doug is referring to with the basic page rendering, and a phase 1.  This would be something similar to htmleasy, at least with some of the concepts.  Building in features like security first, then moving to other items imo.  We are just at PoC stuff atm, but I think a lot of comments you refer to could be interesting for this. 

And finally the server-side processing of the dynamic atom links.  I remember reading about some of this when I read Bill's book on REST :-)  It does seem appealing, but I could see some complexities once it gets to the client side.  Is your suggestion to have this be a data feed, or have a client-side framework in place to build the UI?  The former seem more appealing to me than the latter.

Stephane Epardaud wrote:

 

This sort of backend allows you to build generic client components that can be used as such:

 

 

 

 

And the table component would fetch the CRUD service descriptor, figure out the required columns, the ones that are sortable, which renderer/editor to use for each column, then fetch the data, check which cell is editable, which row supports which operation (delete/edit/clone, etc) and you get a dynamic table editor with zero JS code for the user, which works for every entity for which you have a CRUD REST service.

 

Building a nice smart-client web framework requires an integration of cool features such as these, but most of the pieces are already there.

I think some of the links or items did not get included or were lost by SBS.  What linked/info was above.

Btw - I get a littler nervous about maintaining client widgets (not saying never), but they are hard to maintain and be optimized across browsers, devices, etc...  The supporting server-side concepts though are cool.

Again - very cool stuff!!

I know you are a big fan of Play, and I have yet to really dig into it - I know shame on me :-(   Just to confirm many of your ideas are not tied to Play directly correct?  They all seem very JAX-RS & HTML based, which is good, although after a quick look the RESTEasy plugin seems to be play specific.  I've got nothing against play, but just want to be sure about the context.  Also what is the current status of the RESTEasy CRUD play module?  I see it has not been updated in a while.

I haven't updated it since I stopped using it in my previous job and concentrated on Ceylon

It's using Play! because that's what I was using at the time and it offered me integration with Hibernate, BV and RESTEasy. Plus it let me do the incredibly dirty bytecode enhancements that were required to add services dynamically to RESTEasy. Remember JAX-RS (and hence RESTEasy) only support the definition of new services from annotations, there's no API to declare new services, so dynamic controllers would need a controller class to be enhanced with pluggable annotations. Dirty as hell, and easily fixable if we add such a feature to RESTEasy (which no doubt would end up in JAX-RS 3 if we get our stuff together behind it).

It can definitely be rewritten with APT if we can't add support for dynamic JAX-RS resources in RESTEasy for some reason.

At the core of your suggestions there needs to be a central request dispatcher and approach for defining the pages, correct?  I believe this is what Doug is referring to with the basic page rendering, and a phase 1.  This would be something similar to htmleasy, at least with some of the concepts.  Building in features like security first, then moving to other items imo.  We are just at PoC stuff atm, but I think a lot of comments you refer to could be interesting for this.

I haven't talked at all about how to serve pages, handle navigation and form submitting, but I am pretty fond of the RoR style used in Play which is simple enough for anyone to grasp. IMO this is essentially an easy problem to solve, compared to rendering of dynamic data.

And finally the server-side processing of the dynamic atom links.  I remember reading about some of this when I read Bill's book on REST :-)  It does seem appealing, but I could see some complexities once it gets to the client side.  Is your suggestion to have this be a data feed, or have a client-side framework in place to build the UI?  The former seem more appealing to me than the latter.

There is definitely need of a client framework, with jQuery, templating and a shit load of goodies that deal with validation, editors, components etc. What JSF failed to do on the server.

 

Stephane Epardaud wrote:

 

This sort of backend allows you to build generic client components that can be used as such:

 

 

 

 

And the table component would fetch the CRUD service descriptor, figure out the required columns, the ones that are sortable, which renderer/editor to use for each column, then fetch the data, check which cell is editable, which row supports which operation (delete/edit/clone, etc) and you get a dynamic table editor with zero JS code for the user, which works for every entity for which you have a CRUD REST service.

 

Building a nice smart-client web framework requires an integration of cool features such as these, but most of the pieces are already there.

I think some of the links or items did not get included or were lost by SBS.  What linked/info was above.

 

Ah, I meant to show: <table data-contents="^{orders.list.url}"></table>

Btw - I get a littler nervous about maintaining client widgets (not saying never), but they are hard to maintain and be optimized across browsers, devices, etc...  The supporting server-side concepts though are cool.

IMO the future is about smart clients, and integration with RESTful servers. RESTful servers is essentially solved, or trivial to get to that point with RESTEasy and Play or whatever. Clients are not so easy, because you start with jQuery and HTML5 and Twitter Bootstrap and that gets you a long way, but you're lacking a component library, REST integration, validation and templating. The future belongs to the first Seam-class web framework that lives on the client and uses whatever REST backend you throw at it.

Hi guys, have you reviewed AngularJS?