RFC: User Application

[Cédric Krier]

Hi,

I would like to have feedbacks on this topic and implementation:
https://discuss.tryton.org/t/support-user-application/183

I think it could be a major improvement for Tryton and allow to create
"killer features".

I would like also to have feedback on Chronos especially the design
because the goal is to be very fast at timesheet encoding.

Thanks,
--
Cédric Krier - B2CK SPRL
Email/Jabber: cedric...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/

[Nikolay Baluk]

That's exactly what we need to have for our modules that integrated with mobile apps. 

Technically, the only thing I don't like is to have tryton's internals used directly in module (werkzeug, @app.route decorator). 

Looking forward to have this in further releases!

[Cédric Krier]

On 2016-09-05 03:02, Nikolay Baluk wrote:
> That's exactly what we need to have for our modules that integrated with
> mobile apps.
>
> Technically, the only thing I don't like is to have tryton's internals used
> directly in module (werkzeug, @app.route decorator).

Could you be more explicit on this? What is the problem?
We have to define the entry points somewhere and the route decorator is
the way to do it with werkzeug.


PS: Please do not top-post on this mailing list, see
http://groups.tryton.org/netiquette

[edbo....@gmail.com]

On Thursday, 1 September 2016 10:10:03 UTC+2, Cédric Krier wrote:

Hi,

I would like to have feedbacks on this topic and implementation:
https://discuss.tryton.org/t/support-user-application/183

I think it could be a major improvement for Tryton and allow to create
"killer features".

I'm also liking this. But instead putting it in __init__.py is it possible to put it in a separate file? e.g. webextension.py

 

I would like also to have feedback on Chronos especially the design
because the goal is to be very fast at timesheet encoding.

I think it's out of scope, but for javascript I'm using EmberJS as my framework, it's a bit like Tryton :-) : framework and modules (in EmberJS called components). In EmberJS an adapter which is keen enough to connect to Tryton and talks http://jsonapi.org/ is already their.

 

[Cédric Krier]

On 2016-09-05 11:07, edbo....@gmail.com wrote:
>
>
> On Thursday, 1 September 2016 10:10:03 UTC+2, Cédric Krier wrote:
> >
> > Hi,
> >
> > I would like to have feedbacks on this topic and implementation:
> > https://discuss.tryton.org/t/support-user-application/183
> >
> > I think it could be a major improvement for Tryton and allow to create
> > "killer features".
> >
>
> I'm also liking this. But instead putting it in __init__.py is it possible
> to put it in a separate file? e.g. webextension.py

There are no strict rule but for me, it has the same semantic as the
register method which is registering available resources.
But I do not think it is right to use the name webextension.py because
routes are not limited to web-extension. Probably routing.py will be
better.

> > I would like also to have feedback on Chronos especially the design
> > because the goal is to be very fast at timesheet encoding.
> >
> >
> I think it's out of scope, but for javascript I'm using EmberJS as my
> framework, it's a bit like Tryton :-) : framework and modules (in EmberJS
> called components). In EmberJS an adapter which is keen enough to connect
> to Tryton and talks http://jsonapi.org/ is already their.

But emberjs depends on Jquery so it will make Chronos bigger.
Also Chronos is a very simple application and indeed I first planned to
have no dependencies at all (no jQuery nor bootstrap). But I could
easily remove usage of jQuery but bootstrap would require a lot of work
to provide good css. And as bootstrap depends on jQuery, I did not
prevent to use it when it simplifies the code.
The chronos.zip is only 450K while ember.js-2.8.0 is alone 1.1M.

So I will welcome any patch that removes bootstrap from Chronos while
keeping the same UI design. This should reduce chronos to probably less
than 100M.

Back to the main topic, I do not think Tryton should force any tools on
the user application side. And the most important is to create agnostic
API on the modules side.

[Cédric Krier]

On 2016-09-06 00:27, Cédric Krier wrote:
> On 2016-09-05 11:07, edbo....@gmail.com wrote:
> > I'm also liking this. But instead putting it in __init__.py is it possible
> > to put it in a separate file? e.g. webextension.py
>
> There are no strict rule but for me, it has the same semantic as the
> register method which is registering available resources.
> But I do not think it is right to use the name webextension.py because
> routes are not limited to web-extension. Probably routing.py will be
> better.

I updated to put all routes in routes.py file

[Sergi Almacellas Abellana]

El 12/09/16 a les 09:58, Cédric Krier ha escrit:

> On 2016-09-06 00:27, Cédric Krier wrote:
>> > On 2016-09-05 11:07, edbo....@gmail.com wrote:
>>> > > I'm also liking this. But instead putting it in __init__.py is it possible
>>> > > to put it in a separate file? e.g. webextension.py
>> >
>> > There are no strict rule but for me, it has the same semantic as the
>> > register method which is registering available resources.
>> > But I do not think it is right to use the name webextension.py because
>> > routes are not limited to web-extension. Probably routing.py will be
>> > better.
> I updated to put all routes in routes.py file

For me It looks cleaner using a separate file, so probably this will be
a good practice but not a strict rule.

--
Sergi Almacellas Abellana
www.koolpi.com
Twitter: @pokoli_srk