element_tab from nitrogen_elements custom controls

128 views
Skip to first unread message

Roman.Shestakov

unread,
Oct 17, 2012, 5:00:36 PM10/17/12
to nitro...@googlegroups.com
hello,

there is a custom "element_tab" from nitrogen_elements custom controls package which seems to be useful but I can't get it working.

I cloned it from this repo:

I am wandering if anybody else tried to use it and got it working and if there are some tips?

Regards, Roman

Jesse Gumm

unread,
Oct 17, 2012, 9:28:32 PM10/17/12
to nitro...@googlegroups.com
Hi Roman,

Ah yes, the old nitrogen-elements repo! Most of those elements were
made for Nitrogen 1.0 and the original maintainer doesn't really
maintain it any longer. One of the things I'd like to tackle is
resurrecting that old repo and maintain it myself. It's a very useful
thing.

Since that particular element was last edited in 2009, it would have
been made for Nitrogen 1.0, which explains why it breaks. There are
some things you'd need to do to fix it up for Nitrogen 2.0:

1) Add -include_lib("nitrogen_core/include/wf.hrl").
2) Change element_panel:render(ControlID,Terms) to
element_panel:render_element(Terms).
3) Change the assignments from wf:q to be non-lists (ie [EventStr] =
wf:q(event) should be changed to just EventStr = wf:q(event) ). This
is due the change from Nitrogen 1.0 to Nitrogen 2.0 that made wf:q not
return a list of values any longer, just a single value)

That should cover most of the big issues, but it'll likely take a
little more debugging than that (may some JS issues, or other
compilation issues).

If you decide to tackle this, definitely post it here if you're able
to get it working.

-Jesse
> --
> You received this message because you are subscribed to the Google Groups
> "Nitrogen Project / The Nitrogen Web Framework for Erlang" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/nitrogenweb/-/ArwkJKCYO_UJ.
> To post to this group, send email to nitro...@googlegroups.com.
> To unsubscribe from this group, send email to
> nitrogenweb...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/nitrogenweb?hl=en.



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

Roman Shestakov

unread,
Oct 18, 2012, 4:28:54 AM10/18/12
to nitro...@googlegroups.com, nitro...@googlegroups.com
Thanks a lot Jesse - I will give it a shot
Regards, Roman

Sent from my iPhone

Roman Shestakov

unread,
Oct 19, 2012, 6:08:54 AM10/19/12
to nitro...@googlegroups.com

Jesse Gumm

unread,
Oct 19, 2012, 6:11:06 AM10/19/12
to nitro...@googlegroups.com
You're very welcome!

Be sure to let me know how it goes! I can definitely see the value in
having an easy-to-use tab control available for users.

-Jesse

Roman Shestakov

unread,
Nov 5, 2012, 5:29:15 PM11/5/12
to nitro...@googlegroups.com
hello,

I am trying to build a custom nitrogen element which wraps jQuery tab element.

I have some marginal success but there are couple of issues:

is there a standard way in nitrogen to output html id attribute in control?

nitrogen uses class as id (e.g. class="wfid_temp971451" )

but I want to be able to output something like this: <div id="fragment-1">

For 'tabs' element I need to use html id for div tag:

anchor <a href="#fragment-1"> need to address element <div id="fragment-1">

<div id="tabs">
<ul>
<li><a href="#fragment-1"><span>One</span></a></li>
<li><a href="#fragment-2"><span>Two</span></a></li>
</ul>
<div id="fragment-1">
<p>First tab is active by default:</p>
</div>
<div id="fragment-2">
Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.
Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.
</div>
</div>

the only way I can think to do this is to use jQuery like this:

[wf:wire(wf:f("jQuery(obj('~s')).attr('id', '~s')", [R#tab.id, R#tab.id])) || R <- Record#tabs.tabs]

this is *almost* ok, but unfortunetely , it makes difficult to wire other actions to the control, because the order of execution of jscript wired to the page becomes vital

any ideas?

Regards, Roman

Jesse Gumm

unread,
Nov 5, 2012, 5:58:27 PM11/5/12
to nitrogenweb
Hi Roman,

It depends on the element, but many elements have an html_id attribute that emit the expected HTML id attribute (at least as of the newest 2.1.0 release)

Let me know how it goes, if this helps.

-Jesse

Roman Shestakov

unread,
Nov 5, 2012, 6:15:56 PM11/5/12
to nitro...@googlegroups.com
argg, of course, html_id attribute, can't believe I overlooked it
many thanks
Regards, Roman

Roman Shestakov

unread,
Nov 5, 2012, 7:04:56 PM11/5/12
to nitro...@googlegroups.com
hello,

is there a way to control the order in which actions wired to the page?

e.g.

1. I have an element which emits jscript action within render_element function via wf:wire call. this action required so element renders correctly, e.g. it is a call to some jQuery func.
2. I also have another action wired to the instance of the element outside render_element function , which just does something to the control every time a page loads.

when page is created and nitrogen emits the jscript to the page, action #2 might be executed *before* #1 and element won't be rendered correctly

is there any way to control the order of jscript functions outputted to the page?

Regards, Roman


Jesse Gumm

unread,
Nov 5, 2012, 9:33:55 PM11/5/12
to nitrogenweb
Hello Roman,

Currently, there is not, you just want to make sure that the order of wf:wire calls happens in the order they should appear on the page.  If you need something to happen right after the element is rendered, you can try manually inserting <script> section at the bottom of the render_element function in your element module.

That said, I have some new functionality in the works for deferred wiring, which can help with this, but it's not ready beyond an initial commit that still hasn't exposed the functionality as an api, so while I can refer you to this particular feature branch, it won't help basically at all until it's done.

The api for this is currently slated to be a sister to wf:wire, and will be wf:defer. Any functions deferred will be guaranteed to run after all functions wired with wf:wire, but like wf:wire, will happen in the order they are called.

Do you think this would help?

-Jesse



--
You received this message because you are subscribed to the Google Groups "Nitrogen Project / The Nitrogen Web Framework for Erlang" group.
To post to this group, send email to nitro...@googlegroups.com.
To unsubscribe from this group, send email to nitrogenweb...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nitrogenweb?hl=en.

Roman Shestakov

unread,
Nov 6, 2012, 1:21:21 PM11/6/12
to nitro...@googlegroups.com
hi Jesse

thanks a lot for replying and btw congratulations on the 2.1.0 release, Nitrogen needed some love…

wf:defer might work  but I suspect even better api would be something like wf:eager (or whenever..) which could only be used *inside* render_element(Record)  and which would output jscript before any wf:wire action. This would guarantee that jscript emitted as part of elements is executed before actions wired to the instances of elements

Regards, Roman

Jesse Gumm

unread,
Nov 6, 2012, 2:25:30 PM11/6/12
to nitrogenweb
Thanks, it took a long time to tie up all the little loose ends before finally being comfortable with adding a new release :)

As for the javascript order, would you be able to point me at a work in progress (either privately or on this board), so I can see what you have and perhaps offer some recommendations?  I've never encountered a situation where prioritizing an item before everything else would have mattered.  I'd like to see this use-case.  The last thing I'd want to do is have a bunch of new calls that start cluttering up the wf-space that all do *pretty much* the same thing.

-Jesse

Roman Shestakov

unread,
Nov 6, 2012, 5:39:28 PM11/6/12
to nitro...@googlegroups.com
hi Jesse, sure - I will make an example available on github
Regards, Roman

Roman Shestakov

unread,
Nov 7, 2012, 3:10:19 PM11/7/12
to nitro...@googlegroups.com
hi Jesse,

I added the example to github.

g...@github.com:RomanShestakov/nitrogen_elements_test.git

1. clone the repo from the link above
2. run make

this will pull all the dependencies and build a project, pls. note that nitrogen is used a lib and project also used webmachine to route requests.
it also pulls nitrogen_elements fork from g...@github.com:RomanShestakov/nitrogen_elements which includes my version of tabs control compliant with nitrogen 2.1.0

see nitrogen_elements_test_sup.erl for details.

3. run ./start.sh - this will start VM
4. in your browser go to http://localhost:8000

hopefully you will get a page with tabs control

5. if you now go to index.erl and uncomment line

 wf:wire(tabs, #tab_select{tab = 1}),

I think this is reasonable action, it just selects tab 1

but if you re-run the page and inspect html source, script section , you will see that this event is getting executed before the event which renders the tabs jquery control

so , this action is never executed and tab 1 is never selected

pls. let me know if you run into problems with running the example

Regards, Roman

Jesse Gumm

unread,
Nov 7, 2012, 3:35:52 PM11/7/12
to nitrogenweb
Great,

I'll have a look at this sometime tonight or tomorrow.

-Jesse

Jesse Gumm

unread,
Nov 9, 2012, 6:30:42 PM11/9/12
to nitrogenweb
Hi Roman,

I've had a look and played around with it.

wf:defer would be sufficient in this scenario, if it was used with the
wf:defer(tabs, #tab_select{tab = 1}).

Alternatively, I would think setting an option such as this would make
more sense if it were an attribute of the tab element, just as you
already have the {selected,0} as an option - though I could see that
being a common enough option that it's worth making it an actual field
in the record (ie #tab.selected_tab).

I see the benefit of the "eager" recommendation, that would then not
require one to use wf:defer in their normal modules.

I'll have to give some thought to this, but I very much appreciate the use case.

Jesse Gumm

unread,
Nov 9, 2012, 6:34:22 PM11/9/12
to nitrogenweb
As a further thought to the tab element itself, I noticed that it's
zero-indexed. I would recommend, for the sake of consistency with the
rest of Erlang, to set the base index to 1.

ie, lists:nth(1, List) returns the first element, while the
element_tab has 0 as the first tab. That kind of inconsistency can
lead to having to look up things too frequently (ie looking up
inconsistent argument order for too many related PHP functions).

-Jesse

Roman Shestakov

unread,
Nov 9, 2012, 7:16:06 PM11/9/12
to nitro...@googlegroups.com
thank you very much for looking into it Jesse,

I will follow your recommendation for tab indexing, it makes good sense , will also look into converting the rest of nitrogen_elements controls, maybe someone will find it useful one day

I am quite surprised that the question of javascript order execution hasn't come up before, maybe I am doing something wacky or… Nitrogen doesn't have enough user base yet.

but I am glad you found my use case to be valid. (tab selection as a separate action was used just for illustration, as you noted the tab could be selected as part of jquery option during init)

Regards, Roman

Jesse Gumm

unread,
Nov 9, 2012, 7:56:07 PM11/9/12
to nitro...@googlegroups.com

Wiring order has actually come up before, typically with respect to dynamically added elements with validators, or attaching other events to those elements, which is why defer is in the works already.

-Jesse


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

Roman Shestakov

unread,
Jan 2, 2013, 6:45:13 AM1/2/13
to nitro...@googlegroups.com
hi, 

one of the possible solutions to enforce an order of execution for javascript code which Nitrogen generates, might be to use javascript custom events, feature available for HTML5 complient browsers

here is a blog post which gives an example how to use it for tabs control:


Regards, Roman

Jesse Gumm

unread,
Jan 2, 2013, 6:58:08 PM1/2/13
to nitrogenweb
Interesting solution. Thanks for posting, Roman.

The upcoming support for priority-queue based wiring will certainly
simplify that process overall (and have the benefit of being useful in
all browsers, not just HTML5-capable browsers).

-Jesse
Reply all
Reply to author
Forward
0 new messages