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.
> I am wandering if anybody else tried to use it and got it working and if
> there are some tips?
> Regards, Roman
> --
> 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 nitrogenweb@googlegroups.com.
> To unsubscribe from this group, send email to
> nitrogenweb+unsubscribe@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
> 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
> On Wed, Oct 17, 2012 at 4:00 PM, Roman.Shestakov
> <roman.shesta...@gmail.com> wrote:
>> 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 am wandering if anybody else tried to use it and got it working and if
>> there are some tips?
>> Regards, Roman
>> --
>> 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 nitrogenweb@googlegroups.com.
>> To unsubscribe from this group, send email to
>> nitrogenweb+unsubscribe@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
> -- > 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 nitrogenweb@googlegroups.com.
> To unsubscribe from this group, send email to nitrogenweb+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/nitrogenweb?hl=en.
> Thanks a lot Jesse - I will give it a shot
> Regards, Roman
> Sent from my iPhone
> On 18 Oct 2012, at 02:28, Jesse Gumm <g...@sigma-star.com> wrote:
>> 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
>> On Wed, Oct 17, 2012 at 4:00 PM, Roman.Shestakov
>> <roman.shesta...@gmail.com> wrote:
>>> 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 am wandering if anybody else tried to use it and got it working and if
>>> there are some tips?
>>> Regards, Roman
>>> --
>>> 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 nitrogenweb@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> nitrogenweb+unsubscribe@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
>> -- >> 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 nitrogenweb@googlegroups.com.
>> To unsubscribe from this group, send email to nitrogenweb+unsubscribe@googlegroups.com.
>> For more options, visit this group at http://groups.google.com/group/nitrogenweb?hl=en.
<roman.shesta...@gmail.com> wrote:
>> Thanks a lot Jesse - I will give it a shot
>> Regards, Roman
>> Sent from my iPhone
>> On 18 Oct 2012, at 02:28, Jesse Gumm <g...@sigma-star.com> wrote:
>>> 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
>>> On Wed, Oct 17, 2012 at 4:00 PM, Roman.Shestakov
>>> <roman.shesta...@gmail.com> wrote:
>>>> 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 am wandering if anybody else tried to use it and got it working and if
>>>> there are some tips?
>>>> Regards, Roman
>>>> --
>>>> 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 nitrogenweb@googlegroups.com.
>>>> To unsubscribe from this group, send email to
>>>> nitrogenweb+unsubscribe@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
>>> --
>>> 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 nitrogenweb@googlegroups.com.
>>> To unsubscribe from this group, send email to nitrogenweb+unsubscribe@googlegroups.com.
>>> For more options, visit this group at http://groups.google.com/group/nitrogenweb?hl=en.
> --
> 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 nitrogenweb@googlegroups.com.
> To unsubscribe from this group, send email to nitrogenweb+unsubscribe@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
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
> 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
> On Fri, Oct 19, 2012 at 5:08 AM, Roman Shestakov
> <roman.shesta...@gmail.com> wrote:
>>> Thanks a lot Jesse - I will give it a shot
>>> Regards, Roman
>>> Sent from my iPhone
>>> On 18 Oct 2012, at 02:28, Jesse Gumm <g...@sigma-star.com> wrote:
>>>> 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
>>>> On Wed, Oct 17, 2012 at 4:00 PM, Roman.Shestakov
>>>> <roman.shesta...@gmail.com> wrote:
>>>>> 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 am wandering if anybody else tried to use it and got it working and if
>>>>> there are some tips?
>>>>> Regards, Roman
>>>>> --
>>>>> 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 nitrogenweb@googlegroups.com.
>>>>> To unsubscribe from this group, send email to
>>>>> nitrogenweb+unsubscribe@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
>>>> --
>>>> 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 nitrogenweb@googlegroups.com.
>>>> To unsubscribe from this group, send email to nitrogenweb+unsubscribe@googlegroups.com.
>>>> For more options, visit this group at http://groups.google.com/group/nitrogenweb?hl=en.
>> --
>> 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 nitrogenweb@googlegroups.com.
>> To unsubscribe from this group, send email to nitrogenweb+unsubscribe@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
> -- > 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 nitrogenweb@googlegroups.com.
> To unsubscribe from this group, send email to nitrogenweb+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/nitrogenweb?hl=en.
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
On Mon, Nov 5, 2012 at 4:29 PM, Roman Shestakov
<roman.shesta...@gmail.com>wrote:
> 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
> On 19 Oct 2012, at 11:11, Jesse Gumm wrote:
> > 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
> > On Fri, Oct 19, 2012 at 5:08 AM, Roman Shestakov
> > <roman.shesta...@gmail.com> wrote:
> >>> Thanks a lot Jesse - I will give it a shot
> >>> Regards, Roman
> >>> Sent from my iPhone
> >>> On 18 Oct 2012, at 02:28, Jesse Gumm <g...@sigma-star.com> wrote:
> >>>> 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
> >>>> On Wed, Oct 17, 2012 at 4:00 PM, Roman.Shestakov
> >>>> <roman.shesta...@gmail.com> wrote:
> >>>>> 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 am wandering if anybody else tried to use it and got it working
> and if
> >>>>> there are some tips?
> >>>>> Regards, Roman
> >>>>> --
> >>>>> 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 nitrogenweb@googlegroups.com.
> >>>>> To unsubscribe from this group, send email to
> >>>>> nitrogenweb+unsubscribe@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
> >>>> --
> >>>> 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 nitrogenweb@googlegroups.com.
> >>>> To unsubscribe from this group, send email to
> nitrogenweb+unsubscribe@googlegroups.com.
> >>>> For more options, visit this group at
> http://groups.google.com/group/nitrogenweb?hl=en.
> >> --
> >> 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 nitrogenweb@googlegroups.com.
> >> To unsubscribe from this group, send email to
> nitrogenweb+unsubscribe@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
> > --
> > 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 nitrogenweb@googlegroups.com.
> > To unsubscribe from this group, send email to
> nitrogenweb+unsubscribe@googlegroups.com.
> > For more options, visit this group at
> http://groups.google.com/group/nitrogenweb?hl=en.
> --
> 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 nitrogenweb@googlegroups.com.
> To unsubscribe from this group, send email to
> nitrogenweb+unsubscribe@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
> 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
> On Mon, Nov 5, 2012 at 4:29 PM, Roman Shestakov <roman.shesta...@gmail.com> wrote:
> 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
> On 19 Oct 2012, at 11:11, Jesse Gumm wrote:
> > 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
> > On Fri, Oct 19, 2012 at 5:08 AM, Roman Shestakov
> > <roman.shesta...@gmail.com> wrote:
> >>> Thanks a lot Jesse - I will give it a shot
> >>> Regards, Roman
> >>> Sent from my iPhone
> >>> On 18 Oct 2012, at 02:28, Jesse Gumm <g...@sigma-star.com> wrote:
> >>>> 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
> >>>> On Wed, Oct 17, 2012 at 4:00 PM, Roman.Shestakov
> >>>> <roman.shesta...@gmail.com> wrote:
> >>>>> 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 am wandering if anybody else tried to use it and got it working and if
> >>>>> there are some tips?
> >>>>> Regards, Roman
> >>>>> --
> >>>>> 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 nitrogenweb@googlegroups.com.
> >>>>> To unsubscribe from this group, send email to
> >>>>> nitrogenweb+unsubscribe@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
> >>>> --
> >>>> 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 nitrogenweb@googlegroups.com.
> >>>> To unsubscribe from this group, send email to nitrogenweb+unsubscribe@googlegroups.com.
> >>>> For more options, visit this group at http://groups.google.com/group/nitrogenweb?hl=en.
> >> --
> >> 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 nitrogenweb@googlegroups.com.
> >> To unsubscribe from this group, send email to nitrogenweb+unsubscribe@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
> > --
> > 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 nitrogenweb@googlegroups.com.
> > To unsubscribe from this group, send email to nitrogenweb+unsubscribe@googlegroups.com.
> > For more options, visit this group at http://groups.google.com/group/nitrogenweb?hl=en.
> --
> 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 nitrogenweb@googlegroups.com.
> To unsubscribe from this group, send email to nitrogenweb+unsubscribe@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
> -- > 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 nitrogenweb@googlegroups.com.
> To unsubscribe from this group, send email to nitrogenweb+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/nitrogenweb?hl=en.
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?
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
On Mon, Nov 5, 2012 at 6:04 PM, Roman Shestakov
<roman.shesta...@gmail.com>wrote:
> 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
> --
> 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 nitrogenweb@googlegroups.com.
> To unsubscribe from this group, send email to
> nitrogenweb+unsubscribe@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
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
> 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
> On Mon, Nov 5, 2012 at 6:04 PM, Roman Shestakov <roman.shesta...@gmail.com> wrote:
> 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
> --
> 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 nitrogenweb@googlegroups.com.
> To unsubscribe from this group, send email to nitrogenweb+unsubscribe@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
> -- > 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 nitrogenweb@googlegroups.com.
> To unsubscribe from this group, send email to nitrogenweb+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/nitrogenweb?hl=en.
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
On Tue, Nov 6, 2012 at 12:21 PM, Roman Shestakov
<roman.shesta...@gmail.com>wrote:
> 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
> On 6 Nov 2012, at 02:33, Jesse Gumm wrote:
> 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
> On Mon, Nov 5, 2012 at 6:04 PM, Roman Shestakov <roman.shesta...@gmail.com
> > wrote:
>> 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
>> --
>> 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 nitrogenweb@googlegroups.com.
>> To unsubscribe from this group, send email to
>> nitrogenweb+unsubscribe@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
> --
> 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 nitrogenweb@googlegroups.com.
> To unsubscribe from this group, send email to
> nitrogenweb+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/nitrogenweb?hl=en.
> --
> 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 nitrogenweb@googlegroups.com.
> To unsubscribe from this group, send email to
> nitrogenweb+unsubscribe@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
> 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
> On Tue, Nov 6, 2012 at 12:21 PM, Roman Shestakov <roman.shesta...@gmail.com> wrote:
> 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
> On 6 Nov 2012, at 02:33, Jesse Gumm wrote:
>> 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
>> On Mon, Nov 5, 2012 at 6:04 PM, Roman Shestakov <roman.shesta...@gmail.com> wrote:
>> 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
>> --
>> 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 nitrogenweb@googlegroups.com.
>> To unsubscribe from this group, send email to nitrogenweb+unsubscribe@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
>> -- >> 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 nitrogenweb@googlegroups.com.
>> To unsubscribe from this group, send email to nitrogenweb+unsubscribe@googlegroups.com.
>> For more options, visit this group at http://groups.google.com/group/nitrogenweb?hl=en.
> -- > 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 nitrogenweb@googlegroups.com.
> To unsubscribe from this group, send email to nitrogenweb+unsubscribe@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
> -- > 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 nitrogenweb@googlegroups.com.
> To unsubscribe from this group, send email to nitrogenweb+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/nitrogenweb?hl=en.
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
> hi Jesse, sure - I will make an example available on github
> Regards, Roman
> On 6 Nov 2012, at 19:25, Jesse Gumm wrote:
>> 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
>> On Tue, Nov 6, 2012 at 12:21 PM, Roman Shestakov <roman.shesta...@gmail.com> wrote:
>> 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
>> On 6 Nov 2012, at 02:33, Jesse Gumm wrote:
>>> 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
>>> On Mon, Nov 5, 2012 at 6:04 PM, Roman Shestakov <roman.shesta...@gmail.com> wrote:
>>> 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
>>> --
>>> 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 nitrogenweb@googlegroups.com.
>>> To unsubscribe from this group, send email to nitrogenweb+unsubscribe@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
>>> -- >>> 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 nitrogenweb@googlegroups.com.
>>> To unsubscribe from this group, send email to nitrogenweb+unsubscribe@googlegroups.com.
>>> For more options, visit this group at http://groups.google.com/group/nitrogenweb?hl=en.
>> -- >> 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 nitrogenweb@googlegroups.com.
>> To unsubscribe from this group, send email to nitrogenweb+unsubscribe@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
>> -- >> 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 nitrogenweb@googlegroups.com.
>> To unsubscribe from this group, send email to nitrogenweb+unsubscribe@googlegroups.com.
>> For more options, visit this group at http://groups.google.com/group/nitrogenweb?hl=en.
> 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
> On 6 Nov 2012, at 22:39, Roman Shestakov wrote:
> hi Jesse, sure - I will make an example available on github
> Regards, Roman
> On 6 Nov 2012, at 19:25, Jesse Gumm wrote:
> 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
> On Tue, Nov 6, 2012 at 12:21 PM, Roman Shestakov <
> roman.shesta...@gmail.com> wrote:
>> 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
>> On 6 Nov 2012, at 02:33, Jesse Gumm wrote:
>> 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
>> On Mon, Nov 5, 2012 at 6:04 PM, Roman Shestakov <
>> roman.shesta...@gmail.com> wrote:
>>> 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
>>> --
>>> 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 nitrogenweb@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> nitrogenweb+unsubscribe@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
>> --
>> 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 nitrogenweb@googlegroups.com.
>> To unsubscribe from this group, send email to
>> nitrogenweb+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/nitrogenweb?hl=en.
>> --
>> 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 nitrogenweb@googlegroups.com.
>> To unsubscribe from this group, send email to
>> nitrogenweb+unsubscribe@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
> --
> 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 nitrogenweb@googlegroups.com.
> To unsubscribe from this group, send email to
> nitrogenweb+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/nitrogenweb?hl=en.
> --
> 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 nitrogenweb@googlegroups.com.
> To unsubscribe from this group, send email to
> nitrogenweb+unsubscribe@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
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.
>> 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
>> On 6 Nov 2012, at 22:39, Roman Shestakov wrote:
>> hi Jesse, sure - I will make an example available on github
>> Regards, Roman
>> On 6 Nov 2012, at 19:25, Jesse Gumm wrote:
>> 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
>> On Tue, Nov 6, 2012 at 12:21 PM, Roman Shestakov
>> <roman.shesta...@gmail.com> wrote:
>>> 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
>>> On 6 Nov 2012, at 02:33, Jesse Gumm wrote:
>>> 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
>>> On Mon, Nov 5, 2012 at 6:04 PM, Roman Shestakov
>>> <roman.shesta...@gmail.com> wrote:
>>>> 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
>>>> --
>>>> 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 nitrogenweb@googlegroups.com.
>>>> To unsubscribe from this group, send email to
>>>> nitrogenweb+unsubscribe@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
>>> --
>>> 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 nitrogenweb@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> nitrogenweb+unsubscribe@googlegroups.com.
>>> For more options, visit this group at
>>> http://groups.google.com/group/nitrogenweb?hl=en.
>>> --
>>> 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 nitrogenweb@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> nitrogenweb+unsubscribe@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
>> --
>> 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 nitrogenweb@googlegroups.com.
>> To unsubscribe from this group, send email to
>> nitrogenweb+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/nitrogenweb?hl=en.
>> --
>> 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 nitrogenweb@googlegroups.com.
>> To unsubscribe from this group, send email to
>> nitrogenweb+unsubscribe@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
-- Jesse Gumm
Owner, Sigma Star Systems
414.940.4866 || sigma-star.com || @jessegumm
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).
On Fri, Nov 9, 2012 at 5:30 PM, Jesse Gumm <g...@sigma-star.com> wrote:
> 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.
> On Wed, Nov 7, 2012 at 2:35 PM, Jesse Gumm <g...@sigma-star.com> wrote:
>> Great,
>> I'll have a look at this sometime tonight or tomorrow.
>> -Jesse
>> On Wed, Nov 7, 2012 at 2:10 PM, Roman Shestakov <roman.shesta...@gmail.com>
>> wrote:
>>> 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
>>> On 6 Nov 2012, at 22:39, Roman Shestakov wrote:
>>> hi Jesse, sure - I will make an example available on github
>>> Regards, Roman
>>> On 6 Nov 2012, at 19:25, Jesse Gumm wrote:
>>> 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
>>> On Tue, Nov 6, 2012 at 12:21 PM, Roman Shestakov
>>> <roman.shesta...@gmail.com> wrote:
>>>> 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
>>>> On 6 Nov 2012, at 02:33, Jesse Gumm wrote:
>>>> 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
>>>> On Mon, Nov 5, 2012 at 6:04 PM, Roman Shestakov
>>>> <roman.shesta...@gmail.com> wrote:
>>>>> 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
>>>>> --
>>>>> 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 nitrogenweb@googlegroups.com.
>>>>> To unsubscribe from this group, send email to
>>>>> nitrogenweb+unsubscribe@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
>>>> --
>>>> 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 nitrogenweb@googlegroups.com.
>>>> To unsubscribe from this group, send email to
>>>> nitrogenweb+unsubscribe@googlegroups.com.
>>>> For more options, visit this group at
>>>> http://groups.google.com/group/nitrogenweb?hl=en.
>>>> --
>>>> 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 nitrogenweb@googlegroups.com.
>>>> To unsubscribe from this group, send email to
>>>> nitrogenweb+unsubscribe@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
>>> --
>>> 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 nitrogenweb@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> nitrogenweb+unsubscribe@googlegroups.com.
>>> For more options, visit this group at
>>> http://groups.google.com/group/nitrogenweb?hl=en.
>>> --
>>> 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 nitrogenweb@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> nitrogenweb+unsubscribe@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
> --
> Jesse Gumm
> Owner, Sigma Star Systems
> 414.940.4866 || sigma-star.com || @jessegumm
-- Jesse Gumm
Owner, Sigma Star Systems
414.940.4866 || sigma-star.com || @jessegumm
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)
> 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
> On Fri, Nov 9, 2012 at 5:30 PM, Jesse Gumm <g...@sigma-star.com> wrote:
>> 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.
>> On Wed, Nov 7, 2012 at 2:35 PM, Jesse Gumm <g...@sigma-star.com> wrote:
>>> Great,
>>> I'll have a look at this sometime tonight or tomorrow.
>>> -Jesse
>>> On Wed, Nov 7, 2012 at 2:10 PM, Roman Shestakov <roman.shesta...@gmail.com>
>>> wrote:
>>>> 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
>>>> On 6 Nov 2012, at 22:39, Roman Shestakov wrote:
>>>> hi Jesse, sure - I will make an example available on github
>>>> Regards, Roman
>>>> On 6 Nov 2012, at 19:25, Jesse Gumm wrote:
>>>> 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
>>>> On Tue, Nov 6, 2012 at 12:21 PM, Roman Shestakov
>>>> <roman.shesta...@gmail.com> wrote:
>>>>> 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
>>>>> On 6 Nov 2012, at 02:33, Jesse Gumm wrote:
>>>>> 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
>>>>> On Mon, Nov 5, 2012 at 6:04 PM, Roman Shestakov
>>>>> <roman.shesta...@gmail.com> wrote:
>>>>>> 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
>>>>>> --
>>>>>> 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 nitrogenweb@googlegroups.com.
>>>>>> To unsubscribe from this group, send email to
>>>>>> nitrogenweb+unsubscribe@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
>>>>> --
>>>>> 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 nitrogenweb@googlegroups.com.
>>>>> To unsubscribe from this group, send email to
>>>>> nitrogenweb+unsubscribe@googlegroups.com.
>>>>> For more options, visit this group at
>>>>> http://groups.google.com/group/nitrogenweb?hl=en.
>>>>> --
>>>>> 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 nitrogenweb@googlegroups.com.
>>>>> To unsubscribe from this group, send email to
>>>>> nitrogenweb+unsubscribe@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
>>>> --
>>>> 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 nitrogenweb@googlegroups.com.
>>>> To unsubscribe from this group, send email to
>>>> nitrogenweb+unsubscribe@googlegroups.com.
>>>> For more options, visit this group at
>>>> http://groups.google.com/group/nitrogenweb?hl=en.
>>>> --
>>>> 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 nitrogenweb@googlegroups.com.
>>>> To unsubscribe from this group, send email to
>>>> nitrogenweb+unsubscribe@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
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
On Nov 9, 2012 6:16 PM, "Roman Shestakov" <roman.shesta...@gmail.com> wrote:
> 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
> On 9 Nov 2012, at 23:34, Jesse Gumm wrote:
> > 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
> > On Fri, Nov 9, 2012 at 5:30 PM, Jesse Gumm <g...@sigma-star.com> wrote:
> >> 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.
> >> On Wed, Nov 7, 2012 at 2:35 PM, Jesse Gumm <g...@sigma-star.com> wrote:
> >>> Great,
> >>> I'll have a look at this sometime tonight or tomorrow.
> >>> -Jesse
> >>> On Wed, Nov 7, 2012 at 2:10 PM, Roman Shestakov <
> roman.shesta...@gmail.com>
> >>> wrote:
> >>>> 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
> >>>> On 6 Nov 2012, at 22:39, Roman Shestakov wrote:
> >>>> hi Jesse, sure - I will make an example available on github
> >>>> Regards, Roman
> >>>> On 6 Nov 2012, at 19:25, Jesse Gumm wrote:
> >>>> 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
> >>>> On Tue, Nov 6, 2012 at 12:21 PM, Roman Shestakov
> >>>> <roman.shesta...@gmail.com> wrote:
> >>>>> 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
> >>>>> On 6 Nov 2012, at 02:33, Jesse Gumm wrote:
> >>>>> 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
> >>>>> On Mon, Nov 5, 2012 at 6:04 PM, Roman Shestakov
> >>>>> <roman.shesta...@gmail.com> wrote:
> >>>>>> 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
> >>>>>> --
> >>>>>> 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 nitrogenweb@googlegroups.com.
> >>>>>> To unsubscribe from this group, send email to
> >>>>>> nitrogenweb+unsubscribe@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
> >>>>> --
> >>>>> 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 nitrogenweb@googlegroups.com.
> >>>>> To unsubscribe from this group, send email to
> >>>>> nitrogenweb+unsubscribe@googlegroups.com.
> >>>>> For more options, visit this group at
> >>>>> http://groups.google.com/group/nitrogenweb?hl=en.
> >>>>> --
> >>>>> 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 nitrogenweb@googlegroups.com.
> >>>>> To unsubscribe from this group, send email to
> >>>>> nitrogenweb+unsubscribe@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
> >>>> --
> >>>> You received this message because you are subscribed to the Google
> Groups
> >>>> "Nitrogen Project / The Nitrogen Web
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:
> 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
> On Nov 9, 2012 6:16 PM, "Roman Shestakov" <roman.shesta...@gmail.com> wrote:
> 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
> On 9 Nov 2012, at 23:34, Jesse Gumm wrote:
> > 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
> > On Fri, Nov 9, 2012 at 5:30 PM, Jesse Gumm <g...@sigma-star.com> wrote:
> >> 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.
> >> On Wed, Nov 7, 2012 at 2:35 PM, Jesse Gumm <g...@sigma-star.com> wrote:
> >>> Great,
> >>> I'll have a look at this sometime tonight or tomorrow.
> >>> -Jesse
> >>> On Wed, Nov 7, 2012 at 2:10 PM, Roman Shestakov <roman.shesta...@gmail.com>
> >>> wrote:
> >>>> 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
> >>>> On 6 Nov 2012, at 22:39, Roman Shestakov wrote:
> >>>> hi Jesse, sure - I will make an example available on github
> >>>> Regards, Roman
> >>>> On 6 Nov 2012, at 19:25, Jesse Gumm wrote:
> >>>> 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
> >>>> On Tue, Nov 6, 2012 at 12:21 PM, Roman Shestakov
> >>>> <roman.shesta...@gmail.com> wrote:
> >>>>> 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
> >>>>> On 6 Nov 2012, at 02:33, Jesse Gumm wrote:
> >>>>> 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
> >>>>> On Mon, Nov 5, 2012 at 6:04 PM, Roman Shestakov
> >>>>> <roman.shesta...@gmail.com> wrote:
> >>>>>> 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
> >>>>>> --
> >>>>>> 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 nitrogenweb@googlegroups.com.
> >>>>>> To unsubscribe from this group, send email to
> >>>>>> nitrogenweb+unsubscribe@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
> >>>>> --
> >>>>> 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 nitrogenweb@googlegroups.com.
> >>>>> To unsubscribe from this group, send email to
> >>>>> nitrogenweb+unsubscribe@googlegroups.com.
> >>>>> For more options, visit this group at
> >>>>> http://groups.google.com/group/nitrogenweb?hl=en.
> >>>>> --
> >>>>> 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 nitrogenweb@googlegroups.com.
> >>>>> To unsubscribe from this group, send email to
> >>>>> nitrogenweb+unsubscribe@googlegroups.com.
> >>>>> For more options, visit this
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).
> 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:
> 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
> On Nov 9, 2012 6:16 PM, "Roman Shestakov" <roman.shesta...@gmail.com> wrote:
>> 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
>> On 9 Nov 2012, at 23:34, Jesse Gumm wrote:
>> > 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
>> > On Fri, Nov 9, 2012 at 5:30 PM, Jesse Gumm <g...@sigma-star.com> wrote:
>> >> 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.
>> >> On Wed, Nov 7, 2012 at 2:35 PM, Jesse Gumm <g...@sigma-star.com> wrote:
>> >>> Great,
>> >>> I'll have a look at this sometime tonight or tomorrow.
>> >>> -Jesse
>> >>> On Wed, Nov 7, 2012 at 2:10 PM, Roman Shestakov
>> >>> <roman.shesta...@gmail.com>
>> >>> wrote:
>> >>>> 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
>> >>>> On 6 Nov 2012, at 22:39, Roman Shestakov wrote:
>> >>>> hi Jesse, sure - I will make an example available on github
>> >>>> Regards, Roman
>> >>>> On 6 Nov 2012, at 19:25, Jesse Gumm wrote:
>> >>>> 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
>> >>>> On Tue, Nov 6, 2012 at 12:21 PM, Roman Shestakov
>> >>>> <roman.shesta...@gmail.com> wrote:
>> >>>>> 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
>> >>>>> On 6 Nov 2012, at 02:33, Jesse Gumm wrote:
>> >>>>> 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
>> >>>>> On Mon, Nov 5, 2012 at 6:04 PM, Roman Shestakov
>> >>>>> <roman.shesta...@gmail.com> wrote:
>> >>>>>> 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
>> >>>>>> --
>> >>>>>> 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 nitrogenweb@googlegroups.com.
>> >>>>>> To unsubscribe from this group, send email to
>> >>>>>> nitrogenweb+unsubscribe@googlegroups.com.
>> >>>>>> For more options, visit this group at
>> >>>>>> http://groups.google.com/group/nitrogenweb?hl=en.
>> >>>>> --
>> >>>>> Jesse Gumm
>> >>>>> Owner, Sigma Star Systems
