dolibarr-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Dolibarr-dev] Default page after login / Page d'acceuil par defaut


From: Laurent Destailleur (eldy)
Subject: Re: [Dolibarr-dev] Default page after login / Page d'acceuil par defaut
Date: Sat, 26 Jan 2013 12:13:51 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2

On parle d'action métier, dans un context transactionnel.
- Un login n'est pas une action métier.
- Un context transactionnel est pour faire simple, un contexte entourré
de begin et rollback sur du code pour garantir que le changement des
statuts/d'info d'éléments fonctionnelle soit fait en tout ou rien.

Le trigger est donc limité à cela car ses caractéristiques sont faite
pour cela.
Il fonctionne selon un principe de scan (scan de répertoires) et non
déclaratif (contrairement au hook), ce qui fait qu'il est simple à un
module de le mettre en oeuvre, peu performant et ne doit pas être
utilisé partout.
Il intègre de plus un mécanisme pour annuler une transaction dans un
contexte de transactuion (donc CRUD mais aussi changement de status d'un
object dans un workflow, ou encore tout contexte transactionnel métier).
Il peut ainsi être enchainné en cascade, pour garantir des synchro avec
des systemes externes, tout en offrant un minimum de gestion d'erreur,
au moins pour la partie réalisée dans dolibarr.
Voir la littérature pour une définition plus détaillée de ce qu'est une
transaction, ou un object métier.

Le hook a les propriétés inverses. Ne bénéficie pas de mécanismes
d'annulation de transactions (donc peut être utilisé partout en dehors
de transactions, mais ne peut l'être dans un transaction métier si il
faut une gestion d'erreur ou une annulation en cas d'échec du composant
du module externe), et il fonctionne sur un mode déclaratif (descripteur
du module), le prix du surcout de complexité (requiert déclaration,
requiert désaction/activation du module pour prendre effet en cas de
changement) permet de bénéficier d'un mécanisme sans scan et pouvant
donc etre exécuté très fréquemment à plusieurs endroits, et à chaque
page, même pour de la lecture ou des appels assurant de la présentation.


Le 26/01/2013 00:48, Régis Houssin a écrit :
> Ouaich... C'est très ambigu !
> Un trigger aussi insert du code externe, mais ce code exécute un événement 
> d'après une action, et a défaut du contraire, le login valide est une action. 
> Ici on ne veut pas afficher du code mais  effectuer un événement en fonction 
> de l'action du login validé.
> Le trigger ne doit pas être limité au crud, il devrait couvrir toutes actions 
> sur lesquelles on voudrait interagir.
>
> -----------------------------------------
> Régis Houssin
> Tél. +33633020797
> http://www.dolibarr.fr
> http://www.dolibox.fr
>
> Le 26 janv. 2013 à 00:14, "Laurent Destailleur (eldy)" <address@hidden> a 
> écrit :
>
>> Le 25/01/2013 21:25, Régis Houssin a écrit :
>>> Je ne suis pas d'accord avec ça,
>>> Un trigger permet d'exécuter une action par rapport à un événement, ce qui 
>>> est le cas ici.
>> Non, les triggers ont été conçu pour etre appelé dans un évenement
>> transactionnel d'une action métier (type CRUD).
>>
>> Hors de cela, le trigger n'est pas adapté et il faut utiliser les hooks.
>> Les hook sont des points d'interruptions de code qui peuvent se trouver
>> n'importe, ou la ou on a besoin d'insérer du code externe, quelquesoit
>> la nature et la position de ce code (cf documentation wiki).
>>
>>> Le hook permet lui de personnaliser ou rajouter des éléments. D'ailleurs il 
>>> ne devrait pas y avoir de hook dans les classes Dao comme actuellement pour 
>>> les extrafields !
>>>
>>> -----------------------------------------
>>> Régis Houssin
>>> Tél. +33633020797
>>> http://www.dolibarr.fr
>>> http://www.dolibox.fr
>>>
>>> Le 25 janv. 2013 à 20:53, "Laurent Destailleur (eldy)" <address@hidden> a 
>>> écrit :
>>>
>>>> Note that this will be replaced by a hook in future: A login isn't a
>>>> business event, so having a trigger here is not a good development.
>>>> Trigger are dedicated to businness event into a transactionnal context.
>>>>
>>>>
>>>> Le 25/01/2013 10:35, Florian Henry a écrit :
>>>>> Hi,
>>>>>
>>>>>   Thank for this answer. Simple solution is the better. I didn't
>>>>> think to it....
>>>>>
>>>>>   I do it with the trigger USER_LOGIN, because the first pages
>>>>> depend on Usergroup of the new connected users.
>>>>>
>>>>> Kind regards.
>>>>>
>>>>> Florian HENRY
>>>>> address@hidden
>>>>> +33 6 03 76 48 07
>>>>> http://www.open-concept.pro
>>>>>
>>>>> Le 25/01/2013 10:05, Laurent Destailleur (eldy) a écrit :
>>>>>> I don't remember any option tha can do that.
>>>>>> The best method is using the url of third party as login page.
>>>>>>
>>>>>> Le 24/01/2013 00:06, Florian Henry a écrit :
>>>>>>> Hello,
>>>>>>>
>>>>>>> I remember to read somewhere in the code a "hidden" dolibarr constant,
>>>>>>> or a Dolibarr settings to defaulted the first page after login (for
>>>>>>> exemple go to thirdparty page after login by default), but I cant'
>>>>>>> find it anymore. Did I dream it ?
>>>>>>>
>>>>>>> I found hook afterlogin or trigger USER_LOGIN, but as I remember
>>>>>>> somthing that do it, I ask to the community if it exists.
>>>>>>>
>>>>>>> Kind regards
>>>>>>>
>>>>>>> ------------------------------------------------------------------
>>>>>>>
>>>>>>> Bonjour a tous,
>>>>>>>
>>>>>>> J'ai le souvenir (peut être en rêve) d'avoir vue dans la conf ou une
>>>>>>> variable MAIN_... qui permet de définir la page d’accueil par défaut.
>>>>>>> Par exemple pour arrivé sur l'écran tiers par défaut et non sur la
>>>>>>> home Accueil après la connexion.
>>>>>>>
>>>>>>> J'ai bien vue les hook afterlogin ou le tigger USER_LOGIN, mais si ça
>>>>>>> existe en standard, je le préfère a une customization via un module.
>>>>>>>
>>>>>>> Ca vous parle ?
>>>>>>>
>>>>>>> Cdt.
>>>> -- 
>>>> Eldy (Laurent Destailleur).
>>>>
>>>> EMail: address@hidden
>>>> Web: http://www.destailleur.fr
>>>>
>>>> Dolibarr (Project leader): http://www.dolibarr.org
>>>> To make a donation for Dolibarr project via Paypal: address@hidden
>>>> AWStats (Author) : http://awstats.sourceforge.net
>>>> To make a donation for AWStats project via Paypal: address@hidden
>>>> AWBot (Author) : http://awbot.sourceforge.net
>>>> CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net
>>>>
>>>>
>>>> _______________________________________________
>>>> Dolibarr-dev mailing list
>>>> address@hidden
>>>> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
>>> _______________________________________________
>>> Dolibarr-dev mailing list
>>> address@hidden
>>> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
>>
>> -- 
>> Eldy (Laurent Destailleur).
>>
>> EMail: address@hidden
>> Web: http://www.destailleur.fr
>>
>> Dolibarr (Project leader): http://www.dolibarr.org
>> To make a donation for Dolibarr project via Paypal: address@hidden
>> AWStats (Author) : http://awstats.sourceforge.net
>> To make a donation for AWStats project via Paypal: address@hidden
>> AWBot (Author) : http://awbot.sourceforge.net
>> CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net
>>
>>
>> _______________________________________________
>> Dolibarr-dev mailing list
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
> _______________________________________________
> Dolibarr-dev mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev


-- 
Eldy (Laurent Destailleur).

EMail: address@hidden
Web: http://www.destailleur.fr

Dolibarr (Project leader): http://www.dolibarr.org
To make a donation for Dolibarr project via Paypal: address@hidden
AWStats (Author) : http://awstats.sourceforge.net
To make a donation for AWStats project via Paypal: address@hidden
AWBot (Author) : http://awbot.sourceforge.net
CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net




reply via email to

[Prev in Thread] Current Thread [Next in Thread]