Questions about delegate & VAR passing to an event

[12u...@gmail.com]

Hi people,

My question about delegate is :

1)- can I play it "yo-yo", meaning calling a function of module A from module B, delegating postback to module B, then can I do the same from module B ? (toward either module A or module X).

2)- how can I avoid using a wf:state or wf:session VAR for an event ?

 

    To be clear :

        * call : function(VAR) I'd like to use in an event of one of it's element (let's say it's a button)

        * pass this VAR to the event when it's called (so the event can use it in it's processing)

    I tried to : postback={event_of_the_death_that_kills, VAR}, but it zapps straight away the whole event :/

Jean-Yves

[Jesse Gumm]

1)- can I play it "yo-yo", meaning calling a function of module A from module B, delegating postback to module B, then can I do the same from module B ? (toward either module A or module X).

Yes, the delegate attribute doesn't really care about context, if the delegate, it will call that module's event function.  If it's not set, or is 'undefined', it will default to wf:page_module()

 

2)- how can I avoid using a wf:state or wf:session VAR for an event ?

 

    To be clear :

        * call : function(VAR) I'd like to use in an event of one of it's element (let's say it's a button)

        * pass this VAR to the event when it's called (so the event can use it in it's processing)

    I tried to : postback={event_of_the_death_that_kills, VAR}, but it zapps straight away the whole event :/

Could you clarify this question?  I'm not sure what is being asked.  My guess: You can pass any var along with a postback as any valid erlang term (atoms, tuples, lists, maps, etc).  So something like {my_term, SomeVar, SomeOtherVar}, is perfectly acceptable.  You just need to make sure you capture the variables with pattern matching in the event function:

event({my_term, SomeVar, SomeOtherVar}) ->

   %% do something

 

But maybe I'm not answering the question you're asking.

-Jesse

Jean-Yves

--
You received this message because you are subscribed to the Google Groups "Nitrogen Project / The Nitrogen Web Framework for Erlang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nitrogenweb...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/nitrogenweb/dd9d45ea-9301-450c-b48c-3163cb9f2a7cn%40googlegroups.com.

--

Jesse Gumm
Owner, Sigma Star Systems
414.940.4866 || sigma-star.com || @jessegumm

[12u...@gmail.com]

Hi Jesse,

NB: the email system of gogol groups is… quite strange (I still have not received the notification from your above answer:/)

> Yes, the delegate attribute doesn't really care about context, if the delegate, it will call that module's event function.  If it's not set, or is 'undefined',

> it will default to wf:page_module()

Ok, that's what I thought :)

> Could you clarify this question?  I'm not sure what is being asked.  My guess: You can pass any var along with a postback as any valid erlang term

> (atoms, tuples, lists, maps, etc).  So something like {my_term, SomeVar, SomeOtherVar}, is perfectly acceptable.

> You just need to make sure you capture the variables with pattern matching in the event function:

>

> event({my_term, SomeVar, SomeOtherVar}) ->

 >  %% do something

This is odd but not the first time I see that : when there's a non-lethal error(s) in the page (such as a missing comma between 2 blocks of panels), it acts strangely - this is probably what has happened,'cos I did it exactly the way you wrote it. It is now working.

Anyway, this is a good thing I can now suppress the wf:state|session VAR :)

Thanks Jesse.

Jean-Yves

[Jesse Gumm]

I just noticed I never replied to this:

This is odd but not the first time I see that : when there's a non-lethal error(s) in the page (such as a missing comma between 2 blocks of panels), it acts strangely - this is probably what has happened,'cos I did it exactly the way you wrote it. It is now working.

Yeah, this is a side-effect of Erlang's record handling - there's not really much that can be done for it.

Since records can be "chained" to be modified, if you miss a comma between two records, you will get one of two results:

1) If the record types are the same (e.g. 2 #panels{}), the fields from the second one will overwrite the fields from the first, or

2) If the record types are different, it'll produce an even weirder "this clause can never match" error.

This is to allow things like:

MyThing = #panel{class=something},

MyThing#panel{text="whatever"}.

That second line is more or less functionally equivalent to:

#panel{class=something}#panel{text=whatever}.

And that *looks* odd, but it's syntactically legal.

As far as I understand, earlier versions of Erlang required the first record in that term to be wrapped in parentheses, but that was removed sometime ago, so it had to look like this:

(#panel{class=something})#panel{text=whatever}.

I wonder if I could build a parse-transform that would look at Nitrogen code and give a warning of "you have two records without a comma separating." I hadn't thought of it before, but it is an odd error to fix.

-Jesse

 

To view this discussion on the web visit https://groups.google.com/d/msgid/nitrogenweb/2f22bfb7-36fc-46f4-bda0-6e5283961508n%40googlegroups.com.