Hello Alex,
Thank you for all the infos. So:
- we would join improving REST 2.0 (rtx-rest),
- we would develope an angularjs (or backbone.js) client.
I hope our work would be useful for all the RT community.
Hello Community,
If anyone has angularJS or backbone.js competency and could join us (any
way), just let us know please.
Thanks,
Ãkos
On Wed, Mar 12, 2014 at 8:33 PM, Alex Vandiver <alexmv@bestpractical.com>wrote:
> On Thu, 2014-03-06 at 17:21 +0100, akos.torok@docca.hu wrote:
> > This is some kind of request for comment. Please, feel free to give us
> > advice, support, ideas. If you have similar effort, if you know any
> > solution that makes this problems causeless, let us know please!
>
> Best Practical is always interested in contributions from the community
> which improve the product. As it happens, our focus for RT 4.4 is
> planned to include a concentration on the UI, as well as a rewrite of
> the REST API.
>
> For RT 4.2, we held to our previous restrictions that the entirety of
> the UI needed to be accessible to users without JS enabled. With
> JS-based UIs sufficiently prevalent now, it is our intent with RT 4.4
> that JS will be a required part of the UI.
>
> That being said, we do not intend to write the entirety of the UI in JS,
> as a thin wrapper around back-end APIs. Such a rewrite would be
> extremely time-intensive, and unlikely to be able to duplicate all of
> the features of the current server-side templating solution.
>
> However, we're quite interested in improving the REST API. The 1.0 REST
> API was written well before the advent of JSON, and indeed before the
> concept of "REST APIs" had begun to be commonplace -- as such, it has a
> number of very odd design decisions that hinder extensibility. Because
> of this, we are uninterested in expanding on it, but are more focused on
> providing a new implementation which is based on modern assumptions of
> how REST APIs should function.
>
> We currently have an initial sketch of a REST 2.0 already partially
> completed, with the aim to release it as an extension for RT 4.2, in
> core in RT 4.4, and remove REST 1.0 thereafter. It is now published at
> https://github.com/bestpractical/rtx-rest -- it also requires the RT
> branch https://github.com/bestpractical/rt/tree/4.2/support-rest-v2
>
> Bear in mind that this is highly experimental; we do _not_ suggest its
> use apart from developers working on it. It is in no way
> production-ready. As we are aware it is lacking in features, pull
> requests or patches welcome; simple bug reports are not helpful at this
> juncture.
>
> - Alex
>
>
>
> --
> RT Training London, March 19-20 and Dallas May 20-21
> http://bestpractical.com/training
>
Thank you for all the infos. So:
- we would join improving REST 2.0 (rtx-rest),
- we would develope an angularjs (or backbone.js) client.
I hope our work would be useful for all the RT community.
Hello Community,
If anyone has angularJS or backbone.js competency and could join us (any
way), just let us know please.
Thanks,
Ãkos
On Wed, Mar 12, 2014 at 8:33 PM, Alex Vandiver <alexmv@bestpractical.com>wrote:
> On Thu, 2014-03-06 at 17:21 +0100, akos.torok@docca.hu wrote:
> > This is some kind of request for comment. Please, feel free to give us
> > advice, support, ideas. If you have similar effort, if you know any
> > solution that makes this problems causeless, let us know please!
>
> Best Practical is always interested in contributions from the community
> which improve the product. As it happens, our focus for RT 4.4 is
> planned to include a concentration on the UI, as well as a rewrite of
> the REST API.
>
> For RT 4.2, we held to our previous restrictions that the entirety of
> the UI needed to be accessible to users without JS enabled. With
> JS-based UIs sufficiently prevalent now, it is our intent with RT 4.4
> that JS will be a required part of the UI.
>
> That being said, we do not intend to write the entirety of the UI in JS,
> as a thin wrapper around back-end APIs. Such a rewrite would be
> extremely time-intensive, and unlikely to be able to duplicate all of
> the features of the current server-side templating solution.
>
> However, we're quite interested in improving the REST API. The 1.0 REST
> API was written well before the advent of JSON, and indeed before the
> concept of "REST APIs" had begun to be commonplace -- as such, it has a
> number of very odd design decisions that hinder extensibility. Because
> of this, we are uninterested in expanding on it, but are more focused on
> providing a new implementation which is based on modern assumptions of
> how REST APIs should function.
>
> We currently have an initial sketch of a REST 2.0 already partially
> completed, with the aim to release it as an extension for RT 4.2, in
> core in RT 4.4, and remove REST 1.0 thereafter. It is now published at
> https://github.com/bestpractical/rtx-rest -- it also requires the RT
> branch https://github.com/bestpractical/rt/tree/4.2/support-rest-v2
>
> Bear in mind that this is highly experimental; we do _not_ suggest its
> use apart from developers working on it. It is in no way
> production-ready. As we are aware it is lacking in features, pull
> requests or patches welcome; simple bug reports are not helpful at this
> juncture.
>
> - Alex
>
>
>
> --
> RT Training London, March 19-20 and Dallas May 20-21
> http://bestpractical.com/training
>