Re: [openplacos-dev] Re: Documentation over libification

[ Thread Index | Date Index | More lists.tuxfamily.org/openplacos-dev Archives ]


oki,
j'ai pas trop d'avis la dessus.
a la base j'avais entamé cette lib pour faire un vrai client en pur js (avec register et tout) qui sera utile pour l'extension chrome.

on peut rester plus bas niveau si tu le souhaite.

juste un truc, je te laisserais corriger tout les appel get et post de tout nos clients quand on corrigera la faute d’orthographe sur le namespace 'ressources' de notre api ;-) ( c'est une blague hein , mais bon  ca illustre un peut le fait que notre api est pas super stable et que encapsuler un peut de truc a droite a gauche c'est pas inutile)

Le 22 juin 2012 18:27, flagos <flagospub@xxxxxxxxx> a écrit :
J'ai fait un commit en ce sens sur la lib js. Evidemment, ca peut se
reverter si on est pas d'accord.

Le 22 juin 2012 10:44, flagos <flagospub@xxxxxxxxx> a écrit :
> Yop le kirsh,
>
> Je mattais un coup d'eil aux commits que tu as liché pour la lib js et
> il m'est venu une petite reflexion. J'ai l'impression qu'on prefere
> generer des libs remplis de helpers plutot que de fournir de la doc.
>
> L'exemple parfait étant la derniere lib js. Alors, ne le prend pas
> pour toi, j'y ai également contribué a ajouter du helper, c'est juste
> une réflexion qui m'est venue avec un peu de recul.
>
> En fait, ce qui est criant dans cette lib, c'est qu'on s'amuse a
> ajouter des helpers pour accéder aux ressources REST. L'idée de base
> de cette lib, c'est de faciliter la vie avec oauth2, surtout que nous
> meme on débute avec ce genre de technos. Après, on fournit des
> méthodes get et post qui sont vraiment très bien, et qui permettent
> l'abstraction de oauth2 tout en conservant la richesse de l'api.
> Jusque la, c'est parfait.
>
> Et après, on commence a faire une public api qui restreignent l'accès
> aux get et aux post en y calant des valeurs en dur. Je trouve ca
> contreproductif. (Encore une fois, j'en ai laché du helper, donc le
> prend pas pour toi.) Autant limiter la lib a la gestion de oauth2 et
> renvoyer les gonzes a la doc de l'api rest pour savoir où accéder a
> quoi. On s'amuse a entretenir une serie de lib, a gerer des
> abstractions. C'est un effort de développement non négligeable alors
> qu'il suffirait de renvoyer les développeurs vers la description de
> l'api rest pour bien faire.
>
> Au niveau des interfaces, on fait beaucoup de libification et peu de
> documentation.
>
> Après, c'est pas un mal partout, par exemple les composants: on a
> quasiment aucune doc de notre systeme de composants, mais par contre
> on a une super lib. Dans ce cas la, je pense qu'on a bien géré le
> truc, utiliser la libcomponent est certainement plus simple que de
> repartir d'un binding *-dbus et de gerer notre système d'introspect.
> Et puis ca permet de gerer le mode thread. Ce n'est clairement pas une
> réflexion a sens unique.
>
> T'en dis quoi ?
>
> --
> Tapé depuis mon clavier



--
Tapé depuis mon clavier





Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/