Aller au contenu
Fredmas

Questions de débutant en Quick Apps sur HC3

Recommended Posts

c'est différent, mais pas tant que ça. Il n'y a pas de meilleur choix, tout dépend de ce que tu veux faire.

 

Si tu la déclares en local, elle ne sera accessible que :

- après la déclaration (je veux dire, linéairement dans le sens de la lecture du code, au moment de la précompilation avant exécution)

- uniquement dans le même fichier

 

Si tu la déclares dans quickApp, alors elle sera accessible... de partout ! Et oui :

- depuis une fonction membre de QuickApp : self.myVar

- depuis n'importe où : quickApp.myVar

 

Car en fait, quickApp, qui est l'objet instancié à partir de la classe QuickApp (notez la majuscule), est global, donc accessible de partout. Ses membres (fonctions comme variables... les fonctions étant en réalité des variables) ne sont pas privés, ils sont publics, donc accessibles de partout.

 

Quand je dis partout, je parle du QA.

Un autre QA, une scène, etc, n'y ont évidemment pas accès.

Ils peuvent juste appeler l'éxécution d'une fonction membre de QuickApp (via le mécanisme fibaro.call)

Partager ce message


Lien à poster
Partager sur d’autres sites

 

il y a 14 minutes, Lazer a dit :

Quand je dis partout, je parle du QA.

Un autre QA, une scène, etc, n'y ont évidemment pas accès.

Donc qu'elle que soit le mode de déclaration : myVar ou local myVar ou self.myVar celle ci ne sera pas utilisable depuis un autre QA et donc pas de conflit avec un autre QA.

Seules les fonctions Quickapp:myFonc () sont accessibles par fibaro.call..... 

 

Partager ce message


Lien à poster
Partager sur d’autres sites
Il y a 18 heures, Fredmas a dit :

Maybe I missed something, but what is the advantage of writting the content you put in local rules table (condition='condition1',action='action1'), instead of listing this same content directly in the mainCode(self) without using a function ipairs?

 

Il y a 20 heures, jang a dit :

P.S I probably wouldn't declare conditions/actions as QuickApp methods.

Il y a 18 heures, Fredmas a dit :

Thanks for the advise. I don't know. I don't care to do it as QuickApp methods (or not) if it is a better way to code and to work, I can ;) But I feel it a little bit heavy...

Each new step is pushing me to do in a different better way, and this is good ^_^

 

But for this reason, I wonder why not put all conditions as a list in mainCode(), only calling QuickApp:function() for actions... (able to be called from another QA if needed).

 

I need to think more about it to clean my mind  :2:

 

Hello @jang, I am curious, how should you do it in regards of your advise not declaring all as QuickApp methods?

From my side, as a first step of improvement (except if it is a bad idea from code and architecture point of view), after have thought about it since yesterday, I am still on listing each condition in mainCode and calling function() for each action needed.

 

Partager ce message


Lien à poster
Partager sur d’autres sites

Well, all QuickApp functions declared are callable from other QAs or through the web interface as has been discussed in other posts previously.

Functions that are local to the QA I believe should be declared as just local functions.

The problem is that you don't have access to 'self' in local functions, for calling ex. self:updateProperty() self:debug() etc.

However, there is a global Lua variable that fibaro sets for us 'quickApp' that gets the value of 'self' - or the QuickApp object.

The problem with 'quickApp' is that it's not set until we exit the QuickApp:onInit() function.

 

So I use something like this.

local function foo()
   quickApp:debug("Foo")
end

function QuickApp:onInit()
   quickApp = self
   foo()
end

 

The reason they set 'quickApp' after we exit :onInit() is that the object is not considered initialised until :onInit() has run. So just be careful that you don't access self variables that you initialise in :onInit() from, in this case, 'foo'.

A purist would say we shouldn't use global variables like 'quickApp' but pass around the self value - however it tends to be a bit tedious if we only have one QuickApp object.

 

However, there is an exception (or rule). If you have QuickAppChild objects too in your QA, then you in effect have several 'QuickApps' and need to pass around the right self to your local functions. 

local function foo(self)
   self:debug("Foo")
end

class 'Child'(QuickAppChild)
function Child:onInit()
   foo(self) -- Child's self
end

function QuickApp:onInit()
   foo(self) -- QuickApp's self
end

Remember to declare 'local foo' before it's referenced in the Child:onInit() function. 

  • Like 2

Partager ce message


Lien à poster
Partager sur d’autres sites

So the example becomes

local function condition1(self) return true end
local function condition2(self) return math.random(1,3) > 1 end
local function condition3(self) return false end
local function action1(self) fibaro.call(...) end
local function action2(self) fibaro.call(...) end

local rules = {
  {condition=condition1,action=action1},
  {condition=condition2,action=action2},
  {condition=condition3,action=action2}
}

function mainCode(self)
    for _,r in ipairs(rules) do  -- Test conditions and run actions if true
       if r.condition(self) then r.action(self) end
    end
end

with the "passing around self' style.

Modifié par jang

Partager ce message


Lien à poster
Partager sur d’autres sites

Thanks a lot for your time @jang , the explanation and the example ;)

And yes I prefer to keep local function and just real QuickApp when it is needed.

 

 

Today as you understood I am like that:`

function mainCode(self)
--------------------------------------------------
  if condition1 then fibaro.call(...) end
--------------------------------------------------
  if condition2 then fibaro.call(...) end
--------------------------------------------------
  if condition3 then fibaro.call(...) end
--------------------------------------------------
end

 

 

Reading again your example for better understanding, I will think and maybe change the architecture in 2 step.

Step 1 to get out actions from mainCode, and step 2 (time to think about it) to maybe apply something like in your example.

So for step 1, I will probably structure the current code like that:

local function action1(self) fibaro.call(...) end
local function action2(self) fibaro.call(...) end
local function action3(self) fibaro.call(...) end

function mainCode(self)
--------------------------------------------------
  if condition1 then action1(self) end
--------------------------------------------------
  if condition2 then action2(self) end
--------------------------------------------------
  if condition3 then action3(self) end
--------------------------------------------------
end

Thanks to that I believe the code will be easier for maintenance, and it will allow me to call function with parameters.

And in case of (clearly not needed today), I can define and call one action function from another out of this QA.

 

Partager ce message


Lien à poster
Partager sur d’autres sites

×