Where communities thrive

  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
Repo info
  • Jul 21 21:23

    SunRiseGG on master

    hmac deleted (compare)

  • Jul 20 23:17

    5HT on master

    8.7.0 (compare)

  • Jun 02 10:10

    SunRiseGG on master

    version (compare)

  • Jun 02 09:31
    TotallyNotMay closed #72
  • Jun 02 09:31
    TotallyNotMay opened #72
  • Jun 02 09:15

    TotallyNotMay on master

    adjacent Merge pull request #72 from syn… (compare)

  • Jun 02 09:09

    5HT on comboLookupText_adjacent

    adjacent (compare)

  • May 28 11:34

    doxtop on master

    8.5.2 (compare)

  • May 20 07:46
    5HT commented on 619b8c3
  • May 19 22:47

    5HT on master

    Update COC.md (compare)

  • May 19 22:47

    5HT on master

    Update COC.md (compare)

  • May 19 22:36

    5HT on master

    Update COC.md (compare)

  • May 19 13:39

    doxtop on master

    saving writer on every request … (compare)

  • May 18 21:06

    doxtop on master

    patch to sync top/bot (compare)

  • May 18 13:40

    doxtop on master

    brake feed when out of elements… (compare)

  • May 18 09:44
    pal-alex removed as member
  • May 14 13:23

    5HT on master

    disable comboLookup dropdown + … fix (compare)

  • May 14 13:23
    5HT closed #71
  • May 14 13:21
    TotallyNotMay opened #71
  • May 14 13:18

    TotallyNotMay on disableOnclick

    fix (compare)

Namdak Tonpa
N2O makes reliable WS connection and provides BERT encoding
NITRO renders pages and provides SPA page signaling protocol (Nitrogen Web Framework in terms of Erlang API) on top of N2O BERT raw channel
N2O/NITRO stack introduce zero-overhead in terms of Erlang processes on top of COWBOY
Thereby we use raw COWBOY router and introduce no ours
N2O core consists of TWO callback functions:
  1. info/3 (message, query, #cx{}) for N2O contexts
  2. proc/2 (message, #pi{}) for Process Instance (SYNRC gen_server replacement)
info is for N2O protocols
proc is for Erlang protocols (native Erlang processes without sockets and encodings)
By combaning them you create your own application topology
Namdak Tonpa
E.g. FTP protocol spawns proc/2 per each file, while all starts stops and chunks are being passed first to info/3 as N2O protocol entry point
BPE protocols also could/should spawn proc/2 per business process, etc.
N2O Expire timer implemented as proc/2
I believe you got the idea. so PI is just gen_server replacement in our stack
while N2O protocol is a part of socket handlers (n2o protocols) chain
we specify list of N2O protocols in {n2o,protolos} env variable
> :application.get_env(:n2o,:protocols)
{:ok, [:nitro_n2o, :crm_ftp, :n2o_heart]}
as you may see my N2O instance contains three protocols (servlets in terms of Java) on top of each socket listener
that's are socket entry points
each of these modules expose info/3 functions
Kool Quark
@5HT , thanks . I will update once I progress through my project. This framework allows us to write everything in Erlang which is a great advantage.
Namdak Tonpa
The idea behing N2O/NITRO is to have constant size 5K js for everything (DOM manipulations) with zero-overhead on server side (you don't need to preprocess messages from JS, they are already BERT)!
Why you still can use any templater, DTL or any external library, they are just not needed, because you have native Erlang templater which is NITRO Elements API
on top of NITRO we also have FORM layer where you can declare UI and not to code it :-) for ERP.UNO apps
Namdak Tonpa
BPE is an engine where FORMs are being passed for user to input on each transactional step, that's how we build ERP apps
as NITRO the only component for DOM manipulations we have BPE as the only component for backend software
BPE provides action/2 (message, #process{})
Each N2O lib has such callback action that hides some N2O protocol
NITRO has event/1 (message) API as Nitrogen legacy, with implicit #cx{} inside Erlang process dictionary
Kool Quark

I am trying to render html from nitro ; how do we render following snippet ;

   <i class="right fas fa-angle-left"></i>
#p{ body = [ #WhatElementGoesHere ..  , 

For <i> I can use

#element{html_tag = <<"i">> , class = <<"fas fa-angle-left">> body = <<"">> }
Kool Quark
Figured out that :
#p{ body = [ #literal{body = "Dashboard"},
             #element{html_tag = <<"i">> class = <<"fas fa-angle-left">> body = <<"">>}
that should work
Namdak Tonpa
Yes, #i, #b elements was removed due to var interference with local variables i, b in Elixir
class could be rewritten as class = ['fas', 'fa-angle-left'] which looks more bold
also body = []
it already has =[] as default so could be ommited
you can bring back those records by introducing them in this way:
-record(i, ?DEFAULT_BASE).
-record(b, ?DEFAULT_BASE).
after that you can write:
#'div'{ body = [ #b{ body = "Text"}, #i{body = "Text"} ]}
Kool Quark
Ok, class as list is better to read.
In nitro can we just update some attributes of element without replacing it . When we do nitro:update are we not replacing the element identified by the id.
Kool Quark

In my initial loaded index.htm I have

    <li class="nav-item">
       <a id="sbSRNew" href="#" class="nav-link active">
        <i class="far fa-circle nav-icon"></i>
        <p>New Request</p>

What I would like do is just update the postback for
element sbSRNew . Currently when I use nitro:update,
I think I have to construct the entire segment ie the full <a>
using nitro records. Is there any way to just update the postback
attribute only ? .

Namdak Tonpa
The answer is no, when you need to update DOM with postback you usually replace full dom with its recursive reinitialization.
    #link{id="sbSRNew", href="#", class=['nav-link','active'],
          postback={mypost}, body = [#i{...},#p{...}]})
Namdak Tonpa
But there is a possibility to deliver only postback, we need just to implement new nitro API or snippet.
basically you need to emit NITRO.event
-define(B(E), nitro:to_binary(E)).

render_action(#event{source=undefined}) -> [];
                     target=Control,type=Type,delegate=D,validation=V}) ->
    E = ?B(Control),
    ValidationSource = [ S || S <- Source, not is_tuple(S) ],
    PostbackBin = wf_event:new(Postback, E, D, event, data(E,Source), ValidationSource, V),
    ["{var x=qi('",E,"'); x && x.addEventListener('",?B(Type),
     "',function (event){ event.preventDefault(); ",PostbackBin,"});};"].

data(E,SourceList) ->
    Type=fun(A) when is_atom(A)   -> [ "atom('",atom_to_list(A),"')" ];
            (A) when is_binary(A) -> [ "bin('",binary_to_list(A),"')" ];
                              (A) -> [ "string('",A,"')" ] end,
        [ case S of {Id,Code} -> [ ",tuple(",Type(Id),",",Code,")" ];
                            _ -> [ ",tuple(",Type(S),",querySource('",?B(S),"'))" ]
          end || S <- SourceList ],"]"]).
This is postback delivery.
As you can see the only requirement is presence of DOM element in DOM tree