new elements

[Allan Streib]

Hi all,

What is your normal approach when you want to use an element that isn't defined? For example I am working on a page where I want to use HTML description lists and Nitrogen are no #dl{}, #dt{}, or $dd{} elements.

My workaround was to use #template{} with bindings, which works conceptually but breaks from how other elements are handled, and I'm going to need to pass about 25 bind values which is a bit tedious. I have these values in a record, but the record definition doesn't seem to be visible to the template callouts.

I also thought about just looking at the element_span module or other similar and follow along to create element_dl, element_dt, and element_dd modules.

I am still very much a beginner at Nitrogen and fairly new to Erlang as well, so I may be missing something more idiomatic?

Thanks,

Allan

[braun...@gmail.com]

I never used that <dl> labels. Personally I think these cases to be overkill to implement in a module. Just look the  #list and #listitem elements

to understand what I mean (or maybe take some ideas...). I would just spit the html with a oneliner:

 %%  make_list([{"item1", "definition1"},  {"item2", "definition2"}, ...]).

make_list(List) ->

  [ "<dl>",     [ ["<dt>", DT, "</dt><dd>", DD, "</dd>"] || {DT, DD} <- List]],   "</dl>"].

There is nothing wrong making them elements, thats the Nitrogen way..., but then you would be creating 3 modules just to emit

the same html as that oneliner.

[Jesse Gumm]

Hey Allan,

This is a situation where I probably would create new elements, however you can use some trickery to minimize the number of copied modules.

The #h1, #h2, etc elements all use the element_h.erl module:

https://github.com/nitrogen/nitrogen_core/blob/master/src/elements/layout/element_h.erl

If you're interested in adding this elements as built-in nitrogen elements, I'm comfortable merging in a PR that defines that.

Does that point you in a workable direction? 

-Jesse

--
You received this message because you are subscribed to the Google Groups "Nitrogen Project / The Nitrogen Web Framework for Erlang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nitrogenweb...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/nitrogenweb/ce872491-92f6-46b8-bf0c-4f57d14abdb4%40www.fastmail.com.

[Allan Streib]

I did go ahead and implement elements before I saw this, I basically copied list/listitem and created #dlist{} and #dlistitem{}.

Since dl elements can contain both dt and dd elements, I added an attribute 'type' to the dlistitem element. So an example would be:

#dlist{ body=[

    #dlistitem{ type=term, text="Term" },

    #dlistitem{ type=definition, body=DefinitionBody }

]}

Does that seem acceptable? If so I'll put a PR together. If not, I am certainly open to a better approach.

Allan

On Wed, Jun 2, 2021, at 3:48 PM, Jesse Gumm wrote:

Hey Allan,

This is a situation where I probably would create new elements, however you can use some trickery to minimize the number of copied modules.

The #h1, #h2, etc elements all use the element_h.erl module:

https://github.com/nitrogen/nitrogen_core/blob/master/src/elements/layout/element_h.erl

If you're interested in adding this elements as built-in nitrogen elements, I'm comfortable merging in a PR that defines that.

Does that point you in a workable direction? 

-Jesse

On Mon, May 31, 2021, 1:20 PM Allan Streib <ast...@fastmail.fm> wrote:

[Jesse Gumm]

Hey Allan,

Excellent!

My only real concern for prime-time is: Is that level of verbosity acceptable?

<DD> is a *lot* shorter than #dlistitem{type=definition}

What if it was something like:

#dlist{body=[

    #dterm{...},

    #ddesc{...}

]}.

Or, it could very well be this:

#dlist{body=[

    #dlistitem{term="Some Term", description="some Description"}

]}.

Leaving either term or description out would simply not render the respective dd or dt tag, but provide a simple mechanism to do the dt, dd pair together in a logical way.

As I'd expect most situations to have a pair of <DT> and <DD> together, I'd probably lean toward the latter approach myself.

What do you think?

-Jesse

Also, from what I've read, it looks like the term "definition" was replaced with "description" in the standard (or maybe I'm misremembering).

--
You received this message because you are subscribed to the Google Groups "Nitrogen Project / The Nitrogen Web Framework for Erlang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nitrogenweb...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/nitrogenweb/a8656339-25da-4cee-9253-aa6a95b21d2d%40www.fastmail.com.

--

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

[Allan Streib]

I like the combined dlistitem, in fact I had already written a little helper function to create the term and description pairs. I'll put some more work into it.

And I think you're right, it's "description" not "definition". MDN says:

"The <dt> HTML element specifies a term in a description or definition list," 

So I think I just locked in on "definition" for some reason. But the container <dl> is "Description List"

Allan

On Thu, Jun 3, 2021, at 7:17 PM, Jesse Gumm wrote:

Hey Allan,

Excellent!

My only real concern for prime-time is: Is that level of verbosity acceptable?

<DD> is a *lot* shorter than #dlistitem{type=definition}

What if it was something like:

#dlist{body=[

    #dterm{...},

    #ddesc{...}

]}.

Or, it could very well be this:

#dlist{body=[

    #dlistitem{term="Some Term", description="some Description"}

]}.

Leaving either term or description out would simply not render the respective dd or dt tag, but provide a simple mechanism to do the dt, dd pair together in a logical way.

As I'd expect most situations to have a pair of <DT> and <DD> together, I'd probably lean toward the latter approach myself.

What do you think?

-Jesse

Also, from what I've read, it looks like the term "definition" was replaced with "description" in the standard (or maybe I'm misremembering).