Genie Discord forum

Hello! I try to use genie-builder 2.0 and I have some questions. May be some of them is a frequent questions:

There are macros in new iristutorial: @in, @out, @handlers, @onchangeany, @page, @show, @genietools, some of them: @out is inside @handlers block, and one is outside: what is the difference of this declaration?

What difference between @in and @out, I correctly understand, that if I change variable with @out on site it will not changed in model?

Is any other macroses I can use?

In genie-builder template I see @onchange. Is any other macroses to handle events?

What events can be handled? Is it possible to handle events from page loading? Or for specific request.

In iristutorial there is no separate module, but in template I have module App , is it necessary? When I should use wrapping into module?

In iristutorial there is code <% table(:datatable; dense=true, flat=true, style="height: 350px;", pagination=:datatablepagination) %> - genie-builder every time replace " on " ets... So, can I do something to prevent it?

I cant make working q-table with DataTable with code: <q-table v-model="datatable" :title="TABLE" :pagination="datatablepagination"></q-table> where datatable declared as @out datatable = DataTable() where I'm wrong?

When I use buttons it displays like small invisible square by default. Can I change it? It is a bug or feature?

Is any macros to work with buttons?

PS I'm sorry there are many questions because I plan to make Web GUI for my pharmacokinetics package and I try to understand on what stage of genie builder I can start prototyping.

Please next time open separate topics for each question 😅

Macros: @in, @out can be used inside or outside @handlers. There's no difference, although the recommended way is to have them in @handlers.

One thing should be clear: variables tagged with @in and @out should only be modified inside @handlers. Any modification made outside will not take effect in the UI

Available macros: this has not been fully documented yet, and we're working on new macros to handle events. As of now, @in, @out, @onchange , @onchangeany (for multiple vars), and @page are the recommended macros to use.

To handle page loading for instance, you could use the isready variable, which becomes true when the page is done loading. For instance

@onchange isready begin ... end

App module: GenieBuilder wraps the code in app.jl in a module. This is done for safety purposes to avoid conflicts with other code, but it is not necessary

GB replacing " with &quot: not sure that should be happening, will look into it

GB replacing " with &quot: - it happens when you insert it in app.jl.htm manually then modify in GB then save.

Well, yes and no. As long as you call @handlers after @in, @out etc. they are valid and will be part of the model and handlers. Any fields added after the after calling @handlers begin <...> end will be added to the model but will not used as triggers for the UI. I am currently proposing a slight modification of the API that doesn't need the @handlers at all. Please have a look at https://github.com/GenieFramework/Stipple.jl/pull/159 if you are interested or want to take part in the discussion

The macros @in, @out, etc. all define variables of the same name as the fieldnames in the current name space. This is ok in modules but can lead to strange situations in Main. Imagine you'd like to add a field in you will end up with an error. In order to circumvent these errors you can use @in! @out! instead. These versions only define the model fields.

@Pere just realised that you are PGimenez on Github, so you are well aware of the proposals ...

@hhaensel haha yes, that's me 😁. Thank you for making these changes, I like it better without having to use @handlers. It helps avoids confusion about where one should put @in@out variables

But currently, @onchange needs to be called last. I'm actually thinking about changing that. We would have to keep the unevaluated handler definitions instead of the evaluated ones and only evaluate upon calling @type. But we would have to invalidate the handler functions upon each adding or removing of variables. The big thing of storing unevaluated handler definitions would be to have the possibility of adding handlers as well as js_methods etc. to mixins.