This is a task for a parser - and the parser can be type safe -but the
constraints for something as complex as html aren’t typically expressed in
types but rather bnf or similar.
You can look at the Java html renderer/parser and it uses type safe nodes but
it still has a resilient parser laye
Thanks, Axel & Robert. As I said in the first post, the package already
works well for my purposes (and apparently for the few others who use it).
It allows defining web content more concisely than raw HTML and makes the
full power of Go available for composing repetitive page structures.
I w
Oh, forgot the footnote:
[1] Note that even that doesn't *actually* work, as `*HtmlNode` would
become a parametric type, so it would have to be instantiated to be used in
the constraint - you'd have to write `type HtmlNode[T string |
*HtmlNode[Something]]`. And the fact that there is no actual ans
On Mon, Dec 20, 2021 at 7:07 PM Michael Ellis
wrote:
> >Just to be clear, the way I understood you is that you want HtmlTree.C to
> be a slice which has elements which can each either be a string or an
> *HtmlTree - i.e. you want these to be mixed in a single slice. Correct?
>
> Actually, no. An
You create structs like StringNode and HtmlNode that implement the common
needed operations.
Imagine a Render() method for a string you convert to html, for an html node
you render recursively.
Or similar. If an HtmlNode is not a leaf node it needs recursive operations.
> On Dec 20, 2021, a
On Monday, December 20, 2021 at 1:33:49 PM UTC-5 ren...@ix.netcom.com wrote:
> You should use interfaces and a “node” type.
>
Hmm, I tried
type Node interface {
string | []*HtmlTree
}
type HtmlTree struct {
T string // html tagname, e.g. 'head'
A string // zer
You should use interfaces and a “node” type.
> On Dec 20, 2021, at 12:07 PM, Michael Ellis wrote:
>
> >Just to be clear, the way I understood you is that you want HtmlTree.C to
> be a slice which has elements which can each either be a string or an
> *HtmlTree - i.e. you want these to be mix
>Just to be clear, the way I understood you is that you want HtmlTree.C to
be a slice which has elements which can each either be a string or an
*HtmlTree - i.e. you want these to be mixed in a single slice. Correct?
Actually, no. An HtmlTree instance whose content is a string is a terminal
no
Just to be clear, the way I understood you is that you want HtmlTree.C to
be a slice which has elements which can each either be a string or an
*HtmlTree - i.e. you wan these to be mixed in a single slice. Correct?
Because that is not a use case for generics, it's a use case for sum types
(which Go
> They can't, sorry.
Ok. Thanks, Axel.
Saves me wasting more time. In the past 3 years of using Go, this is the
only use case where I've really wanted generics (other cases I've
encountered so far are easily handled with code generation).
--
You received this message because you are subscri
On Mon, Dec 20, 2021 at 3:20 PM Michael Ellis
wrote:
> I've got a package, github.com/Michael-F-Ellis/goht, that supports
> creating HTML docs in Go. It works well, for my purposes at least, but
> I've always been bothered by having to use []interface{} to define the
> struct member, C, that sup
I've got a package, github.com/Michael-F-Ellis/goht, that supports creating
HTML docs in Go. It works well, for my purposes at least, but I've always
been bothered by having to use []interface{} to define the struct member,
C, that supports recursion.
type HtmlTree struct {
T strin
12 matches
Mail list logo
