Adding id to html elements

[Mattias Holmlund]

I have started looking at integrating nitrogen with jquery mobile. As a part of that work, I need to generate a label element and an input element, where the label element has a for-property that matches the id of the input element. E.g.

<label for="slider2">My input</label> 

<input type="range" name="slider" id="slider2" value="0" min="0" max="100"/> 

I have added code to generate the for-property, but I now need to add a known id to the input element. If I set the id-field of the input-element in nitrogen, that value ends up as a class on the input element, so I can't use that. My next idea is to add a new field called "htmlid" to the input element and set the id of the input element from that. Does that sound like a good idea, or does anyone have any other suggestions?

https://github.com/mattiash/nitrogen_core

/Mattias

--
Mattias Holmlund
http://www.holmlund.se/mattias/

[Jesse Gumm]

I think that's probably a good idea.

Perhaps we could change it so that the id of the element gets emitted as the actual html ID, while also adding an htmlid attribute that, if specified, would overwrite the emitted id.

I'm undecided at the moment, but I agree it would be convenient to be able to emit an actual HTML ID.

-Jesse

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

--
Jesse Gumm
Sigma Star Systems
414.940.4866
gu...@sigma-star.com
http://www.sigma-star.com

[Andrew Cantos]

I just mentioned jquery mobile in a separate post, crazy coincidence. Will be tracking this closely, great idea Mattias.

--

[Mattias Holmlund]

On Sat, Sep 24, 2011 at 1:34 AM, Jesse Gumm <gu...@sigma-star.com> wrote:

I think that's probably a good idea.

Perhaps we could change it so that the id of the element gets emitted as the actual html ID, while also adding an htmlid attribute that, if specified, would overwrite the emitted id.

If the actual html id is set from the erlang records id, then I don't see the need for an html id attribute.

My initial idea was to use the id field to generate both an id attribute and a wfid_ class. I tried this, but unfortunately in element_dropdown:render_element, the id attribute has been mangled (prepended with wfid_) so I cannot use it to set the id.

The htmlid solution is not very elegant, but I will start with that since I have more interesting challenges ahead with jquery mobile.

/Mattias

[Jeno I. Hajdu]

Hi,

this is a rather old thread to resurrect, but have you decided how to handle the html id attribute? (I guess the question is mainly meant for Jesse.) I've run into a similar problem when I tried to integrate jqplot and my workaround was the same, adding an extra record field which got emitted as the id attribute in the html. I think emitting the id field also as the id attribute without the wfid_ prefix would create a more cleaner situation and would make 3rd party js integration easier. What is the current stance on this? I assume there was a reason why ids were added to class instead setting the id attribute. Does anyone know what was that reason?

BR,
Jeno

[Jesse Gumm]

My goal (and I'll probably just sit down one day and grind it out for
all existing elements) is to add an html_id field to the base element,
that way if you *really* need the HTML id of an element, you can avoid
the duplicate emitted field, then I just need to edit every
element_X.erl file to emit the html_id.

Emitting the wfid as the HTML id might lead to problems as nitrogen
elements can have more than one wfid, usually the named wfid, and the
wfid_temp, which is why I'm probably leaning toward adding just an
html_id field to the base element to simplify it.

Perhaps for a long-term goal it might be worthwhile to emit the htmlid
as the id, but the complications may arise with compound elements such
as #bind.

In any case, if anyone wants to save me the work and add html_id to
the base element and modify all elements to emit it, I wouldn't save
no :)

-Jesse

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

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

[Mattias Holmlund]

On Tue, Mar 20, 2012 at 5:05 PM, Jesse Gumm <gu...@sigma-star.com> wrote:

In any case, if anyone wants to save me the work and add html_id to
the base element and modify all elements to emit it, I wouldn't save
no :)

I have done this for textbox, textarea and dropdown in nitrogen_core, but with the html_id in the record for each element. Might be useful as a starting point for someone.

/Mattias

[Jeno I. Hajdu]

On Tue, Mar 20, 2012 at 9:30 PM, Mattias Holmlund <mattias....@gmail.com> wrote:

On Tue, Mar 20, 2012 at 5:05 PM, Jesse Gumm <gu...@sigma-star.com> wrote:

In any case, if anyone wants to save me the work and add html_id to
the base element and modify all elements to emit it, I wouldn't save
no :)

I have done this for textbox, textarea and dropdown in nitrogen_core, but with the html_id in the record for each element. Might be useful as a starting point for someone.

Thanks, I have checked it. I am wondering whether it would be better to have the html_id as part of the ELEMENT_BASE macro instead of adding it separately for each element. I have looked through the elements which don't have a direct wf_tags:emit_tag() call and only for a bunch it would make no sense to have an html_id (for example flash, bind, template or function), roughly 6-7, so ~10% of all the element types. Unfortunately the rendering part still has to be repeated. If we can decide which would be better from the above two options, I'll go through the elements and make the modification.

BR,
Jeno

[Jesse Gumm]

Yes, having it in ELEMENT_BASE is the right way to go, but Mattias's
version works if you're cherry picking which elements will support the
html_id (and it certainly saved him a handful of work while
accomplishing his goal of incorporating jquery mobile).

-Jesse

[Sébastien Saint-Sevin]

Hi list,

Just to add some confusion to that subject. I did it the other way (for the same need of Jquery
mobile integration).

I created JQM elements that matches base elements for those that needs Jquery mobile attributes such
as :

- element_jqm_panel
- element_jqm_link,
etc....

And I duplicated some rendering code (to avoid touching current nitrogen structure) as :

-module(element_jqm_panel).
-compile(export_all).
-include_lib("nitrogen_core/include/wf.hrl").
-include("records.hrl").

reflect() -> record_info(fields, jqm_panel).

render_element(Record) ->
wf_tags:emit_tag('div', Record#jqm_panel.body, [
{class, ["panel", Record#jqm_panel.class]},
{style, Record#jqm_panel.style},
{id, Record#jqm_panel.id -- ".wfid_"},
{'data-role', Record#jqm_panel.data_role},
{'data-theme', Record#jqm_panel.data_theme},
{'data-collapsed', Record#jqm_panel.data_collapsed}
]).

Have a look at the ID line where I removed the ".wfid_" prefix. At least the record ID field
generates an ID html attribute ! (otherwise ID generates a class attribute, and html_id an ID attribute)

I think I would prefer that the nitrogen framework keep closer to the generated HTML instead of
creating new attributes.

My 2 cents,
Cheers,

S�bastien

Le 20/03/2012 23:36, Jesse Gumm a �crit :

[Jeno I. Hajdu]

Hi,

I think most of us would prefer this, but the problem is what Jesse wrote previously, there can be cases when a single
element has multiple wfids and then you can have problems.
Anyway I have modified the elements to use a new html_id field, I plan to push it to github tonight.
Alternatively we could figure out how to handle properly the case of multiple wfids in general from the id attribute's
point of view.

BR,
Jeno

2012/3/22 Sébastien Saint-Sevin <seb-g...@matchix.com>

Sébastien

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 nitro...@googlegroups.com.

To unsubscribe from this group, send email to nitrogenweb+unsubscribe@googlegroups.com.

[Sébastien Saint-Sevin]

Hi,

Yep, there could be multiple wfids, but I think they are added to the class field, not to the ID
field, so what I did seems to work (at least I'm running it on a full web site and I didn't hit the
wall right now :-)).

The appending is done in wf_render_elements.erl

Cheers,
S�bastien.

Le 22/03/2012 21:27, Jeno I. Hajdu a �crit :

> Hi,
>
> I think most of us would prefer this, but the problem is what Jesse wrote previously, there can be
> cases when a single
> element has multiple wfids and then you can have problems.
> Anyway I have modified the elements to use a new html_id field, I plan to push it to github tonight.
> Alternatively we could figure out how to handle properly the case of multiple wfids in general from
> the id attribute's
> point of view.
>
> BR,
> Jeno
>

> 2012/3/22 S�bastien Saint-Sevin <seb-g...@matchix.com <mailto:seb-g...@matchix.com>>

>
> Hi list,
>
> Just to add some confusion to that subject. I did it the other way (for the same need of Jquery
> mobile integration).
>
> I created JQM elements that matches base elements for those that needs Jquery mobile attributes
> such as :
>
> - element_jqm_panel
> - element_jqm_link,
> etc....
>
> And I duplicated some rendering code (to avoid touching current nitrogen structure) as :
>
> -module(element_jqm_panel).
> -compile(export_all).

> -include_lib("nitrogen_core/__include/wf.hrl").

> -include("records.hrl").
>
> reflect() -> record_info(fields, jqm_panel).
>
> render_element(Record) ->
> wf_tags:emit_tag('div', Record#jqm_panel.body, [
> {class, ["panel", Record#jqm_panel.class]},
> {style, Record#jqm_panel.style},

> {id, Record#jqm_panel.id <http://jqm_panel.id> -- ".wfid_"},

> {'data-role', Record#jqm_panel.data_role},
> {'data-theme', Record#jqm_panel.data_theme},

> {'data-collapsed', Record#jqm_panel.data___collapsed}

> ]).
>
>
> Have a look at the ID line where I removed the ".wfid_" prefix. At least the record ID field
> generates an ID html attribute ! (otherwise ID generates a class attribute, and html_id an ID
> attribute)
>
> I think I would prefer that the nitrogen framework keep closer to the generated HTML instead of
> creating new attributes.
>
> My 2 cents,
> Cheers,
>

> S�bastien
>
> Le 20/03/2012 23:36, Jesse Gumm a �crit :

> <mailto:nitro...@googlegroups.com>.

> To unsubscribe from this group, send email to

> nitrogenweb+unsubscribe@__googlegroups.com
> <mailto:nitrogenweb%2Bunsu...@googlegroups.com>.

> For more options, visit this group at

> http://groups.google.com/__group/nitrogenweb?hl=en
> <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 nitro...@googlegroups.com

> <mailto:nitro...@googlegroups.com>.
> To unsubscribe from this group, send email to nitrogenweb+unsubscribe@__googlegroups.com
> <mailto:nitrogenweb%2Bunsu...@googlegroups.com>.
> For more options, visit this group at http://groups.google.com/__group/nitrogenweb?hl=en
> <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 nitro...@googlegroups.com.

> To unsubscribe from this group, send email to nitrogenweb...@googlegroups.com.