Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #34691 > unrolled thread

A simpler DOM in JS

Back to article view | Back to comp.lang.javascript

Contents

  A simpler DOM in JS "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2018-02-03 14:24 -0800
    Re: A simpler DOM in JS Martin Honnen <martin.honnen@gmx.de> - 2018-02-04 14:26 +0100
      Re: A simpler DOM in JS Julio Di Egidio <julio@diegidio.name> - 2018-02-04 06:18 -0800
        Re: A simpler DOM in JS Ken Tilton <kentilton@gmail.com> - 2018-03-05 08:14 -0800
          Re: A simpler DOM in JS Julio Di Egidio <julio@diegidio.name> - 2018-03-08 00:43 -0800
            Re: A simpler DOM in JS Ken Tilton <kentilton@gmail.com> - 2018-03-08 05:57 -0800
              Re: A simpler DOM in JS Julio Di Egidio <julio@diegidio.name> - 2018-03-08 07:56 -0800
      Re: A simpler DOM in JS Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-02-05 06:15 +0100
        Re: A simpler DOM in JS "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2018-02-04 23:15 -0800
      Re: A simpler DOM in JS "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2018-02-04 23:06 -0800
    Re: A simpler DOM in JS Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-02-05 05:50 +0100
      Re: A simpler DOM in JS Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-02-05 06:26 +0100
        Re: A simpler DOM in JS "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2018-02-04 23:33 -0800
          Re: A simpler DOM in JS Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-02-05 11:19 +0100
            Re: A simpler DOM in JS Julio Di Egidio <julio@diegidio.name> - 2018-02-05 04:16 -0800
            Re: A simpler DOM in JS "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2018-02-05 10:23 -0800
              Re: A simpler DOM in JS Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-02-05 19:42 +0100
                Re: A simpler DOM in JS Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-02-08 01:46 +0100
                Re: A simpler DOM in JS Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-02-08 01:47 +0100
                  Re: A simpler DOM in JS "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2018-02-11 10:27 -0800
                    Re: A simpler DOM in JS Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-02-12 04:38 +0100
                      Re: A simpler DOM in JS "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2018-02-15 12:19 -0800
                        Re: A simpler DOM in JS Julio Di Egidio <julio@diegidio.name> - 2018-02-15 12:43 -0800
                        Re: A simpler DOM in JS Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-02-25 19:22 +0100
                Re: A simpler DOM in JS "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2018-02-07 12:51 -0800
                  Re: A simpler DOM in JS Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-02-08 02:27 +0100
                    Re: A simpler DOM in JS John G Harris <niam@jghnorth.org.uk.invalid> - 2018-02-08 19:21 +0000
              Re: A simpler DOM in JS Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-02-05 19:58 +0100
      Re: A simpler DOM in JS "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2018-02-04 23:30 -0800
        Re: A simpler DOM in JS Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-02-05 19:11 +0100
          Re: A simpler DOM in JS "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2018-02-11 10:16 -0800
            Re: A simpler DOM in JS Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-02-12 04:48 +0100
    Re: A simpler DOM in JS Ken Tilton <kentilton@gmail.com> - 2018-03-05 08:07 -0800
      Re: A simpler DOM in JS "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2018-03-06 17:40 -0800
        Re: A simpler DOM in JS Ken Tilton <kentilton@gmail.com> - 2018-03-07 12:09 -0800

Page 1 of 2  [1] 2  Next page →

#34691 — A simpler DOM in JS

I'm not a fan of JSX, nor was I a fan of E4X before it. Embedded DSLs require code-switching [1] for understanding, or require the DSL to be a black box to the host language in the case of template strings [2].

Dealing with the DOM APIs directly are terribly verbose though as we know. Should we not do better? 

In System.XML.LINQ [3] the approach is to construct XML elements and their contents by nested constructors:

<script type="C#">
  var root = new XElement("Root",
    new XElement("Child1", 1),
    new XElement("Child2", 2),
    new XElement("Child3", 3),
    new XElement("Child4", 4),
    new XElement("Child5", 5),
    new XElement("Child6", 6)
  );

  Console.WriteLine(root);

  /*
  <Root>
    <Child1>1</Child1>
    <Child2>2</Child2>
    <Child3>3</Child3>
    <Child4>4</Child4>
    <Child5>5</Child5>
    <Child6>6</Child6>
  </Root>
  */
</script>

Should we not do similar for the dirty DOM we have to deal with? Here's what we have to contend with for the equivalent:

<script type="JavaScript">
  var root = document.createElement("root")

  for(var i = 1; i <= 6; i++) {
    var child = document.createElement("child" + i)
    child.textContent = i
    root.appendChild(child)
  }

  console.log(root.outerHTML)
</script>

And that is for a very trivial use-case.

My proposal is that a library be created to promote the approach of System.XML.LINQ to the HTML DOM. The result being not simply the emulation of the C# example but additionally the ability to warn of deprecated attribute usage and illegal compositions such as placing a button element inside of an option element.

I am curious to the community's thoughts on the topic.


[1] <https://en.wikipedia.org/wiki/Code-switching>
[2] <http://2ality.com/2015/01/template-strings-html.html>
[3] <https://msdn.microsoft.com/en-us/library/system.xml.linq.xelement(v=vs.110).aspx>

[toc] | [next] | [standalone]

#34693

On 03.02.2018 23:24, Michael Haufe (TNO) wrote:

> Dealing with the DOM APIs directly are terribly verbose though as we know. Should we not do better?
> 
> In System.XML.LINQ [3] the approach is to construct XML elements and their contents by nested constructors:
> 
> <script type="C#">
>    var root = new XElement("Root",
>      new XElement("Child1", 1),
>      new XElement("Child2", 2),
>      new XElement("Child3", 3),
>      new XElement("Child4", 4),
>      new XElement("Child5", 5),
>      new XElement("Child6", 6)
>    );
> 
>    Console.WriteLine(root);
> 
>    /*
>    <Root>
>      <Child1>1</Child1>
>      <Child2>2</Child2>
>      <Child3>3</Child3>
>      <Child4>4</Child4>
>      <Child5>5</Child5>
>      <Child6>6</Child6>
>    </Root>
>    */
> </script>
> 
> Should we not do similar for the dirty DOM we have to deal with? Here's what we have to contend with for the equivalent:
> 
> <script type="JavaScript">
>    var root = document.createElement("root")
> 
>    for(var i = 1; i <= 6; i++) {
>      var child = document.createElement("child" + i)
>      child.textContent = i
>      root.appendChild(child)
>    }
> 
>    console.log(root.outerHTML)
> </script>
> 
> And that is for a very trivial use-case.
> 
> My proposal is that a library be created to promote the approach of System.XML.LINQ to the HTML DOM. The result being not simply the emulation of the C# example but additionally the ability to warn of deprecated attribute usage and illegal compositions such as placing a button element inside of an option element.

But why whould a HTML DOM allow you to create elements named "Root" or 
"Child1" at all? An odd example at least.

And the LINQ object model has at least one flaw with its lack of 
representation of prefixes in XName that makes lexical representations 
of trees dependent on the implementation strategy to choose prefixes e.g.

             XNamespace xhtml = "http://www.w3.org/1999/xhtml";

             XElement html = new XElement(xhtml + "html",
                 new XElement(xhtml + "body",
                    new XElement(xhtml + "p", "This is a test.")));

             Console.WriteLine(html);

outputs

<html xmlns="http://www.w3.org/1999/xhtml">
   <body>
     <p>This is a test.</p>
   </body>
</html>

and if we add a namespace declaration attribute and output the tree again

            html.Add(new XAttribute(XNamespace.Xmlns + "xhtml", xhtml));

            Console.WriteLine(html);

we now get

<xhtml:html xmlns:xhtml="http://www.w3.org/1999/xhtml">
   <xhtml:body>
     <xhtml:p>This is a test.</xhtml:p>
   </xhtml:body>
</xhtml:html>

so suddenly all the generated qualified names of the elements have that 
prefix.

I agree the W3C DOM is ugly, in particular with all those different 
levels it has and the whole factory based approach and I am glad to have 
class based alternatives like XOM or JDOM in the Java world or XLINQ in 
the .NET world.

But part of the power of XLINQ (both for composition (your initial 
example could be shortened to

   var root = new XElement("Root",
     from i in Enumerable.Range(1, 6) select new XElement("Child" + i, i)
   );

) and for querying of trees) is due to the integration with LINQ and not 
solely based on its node creation API using constructors instead of 
factory methods.

I liked E4X and I think it would have worked had there been a DOM 
integration but as far as I remember that never happened.

Whether browser-side JS needs another library based API for node 
creation I am not sure, it looks like most people are happy with 
throwing there string fragments into JQuery.

[toc] | [prev] | [next] | [standalone]

#34694

On Sunday, 4 February 2018 14:26:59 UTC+1, Martin Honnen  wrote:
> On 03.02.2018 23:24, Michael Haufe (TNO) wrote:
> 
> > Dealing with the DOM APIs directly are terribly verbose though as we know. Should we not do better?
> > 
> > In System.XML.LINQ [3] the approach is to construct XML elements and their contents by nested constructors:
> > 
> > <script type="C#">
> >    var root = new XElement("Root",
> >      new XElement("Child1", 1),
<snip>
> Whether browser-side JS needs another library based API for node 
> creation I am not sure, it looks like most people are happy with 
> throwing there string fragments into JQuery.

Or use something like React, the accomplished apotheosis of the layering fuck
up...

Julio

[toc] | [prev] | [next] | [standalone]

#34759

On Sunday, February 4, 2018 at 9:18:23 AM UTC-5, Julio Di Egidio wrote:
> On Sunday, 4 February 2018 14:26:59 UTC+1, Martin Honnen  wrote:
> > On 03.02.2018 23:24, Michael Haufe (TNO) wrote:
> > 
> > > Dealing with the DOM APIs directly are terribly verbose though as we know. Should we not do better?
> > > 
> > > In System.XML.LINQ [3] the approach is to construct XML elements and their contents by nested constructors:
> > > 
> > > <script type="C#">
> > >    var root = new XElement("Root",
> > >      new XElement("Child1", 1),
> <snip>
> > Whether browser-side JS needs another library based API for node 
> > creation I am not sure, it looks like most people are happy with 
> > throwing there string fragments into JQuery.
> 
> Or use something like React, the accomplished apotheosis of the layering fuck
> up...
> 
> Julio

Had to look up apotheosis, but OMG, yes.

[toc] | [prev] | [next] | [standalone]

#34765

On Monday, 5 March 2018 17:14:27 UTC+1, Ken Tilton  wrote:
> On Sunday, February 4, 2018 at 9:18:23 AM UTC-5, Julio Di Egidio wrote:

> > Or use something like React, the accomplished apotheosis of the layering fuck
> > up...
> 
> Had to look up apotheosis, but OMG, yes.

You too are proposing the approach that I am (strongly) advising against:
so, either I am misunderstanding you, or you should look up "yes" as well.

Julio

[toc] | [prev] | [next] | [standalone]

#34766

On Thursday, March 8, 2018 at 3:43:13 AM UTC-5, Julio Di Egidio wrote:
> On Monday, 5 March 2018 17:14:27 UTC+1, Ken Tilton  wrote:
> > On Sunday, February 4, 2018 at 9:18:23 AM UTC-5, Julio Di Egidio wrote:
> 
> > > Or use something like React, the accomplished apotheosis of the layering fuck
> > > up...
> > 
> > Had to look up apotheosis, but OMG, yes.
> 
> You too are proposing the approach that I am (strongly) advising against:
> so, either I am misunderstanding you, or you should look up "yes" as well.
> 
> Julio

I was agreeing that React, while well-meaning, introduced in effect a completely new language (the layering fuck).

You may be midunderstanding me. My goal is to deliver the benefits of React, and more, with a JS HTML API that works so much like HTML a strong graphic designer could handle it. I like to call it an un-framework.

kt

[toc] | [prev] | [next] | [standalone]

#34767

On Thursday, 8 March 2018 14:57:48 UTC+1, Ken Tilton  wrote:
> On Thursday, March 8, 2018 at 3:43:13 AM UTC-5, Julio Di Egidio wrote:
> > On Monday, 5 March 2018 17:14:27 UTC+1, Ken Tilton  wrote:
> > > On Sunday, February 4, 2018 at 9:18:23 AM UTC-5, Julio Di Egidio wrote:
> > <snip>
> > > > Or use something like React, the accomplished apotheosis of the
> > > > layering fuck up...
> > > 
> > > Had to look up apotheosis, but OMG, yes.
> > 
> > You too are proposing the approach that I am (strongly) advising against:
> > so, either I am misunderstanding you, or you should look up "yes" as well.
> 
> I was agreeing that React, while well-meaning, introduced in effect a
> completely new language (the layering fuck).
> 
> You may be midunderstanding me. My goal is to deliver the benefits of React,
> and more, with a JS HTML API that works so much like HTML a strong graphic
> designer could handle it. I like to call it an un-framework.

No, it's you misunderstanding me: the "layering fuckup" has to do with the
*inversion* of layers and responsibilities, not with how the single layers
are realized.  IOW, it's a point of architecture and logic, not to mention
of allocation of team resources: you guys are reinventing the wheel and are
reinventing it wrong.

Beginners can't layer code and end up with e.g. client-side code generated
from the server, but just the same happens within the client now, between
structure, presentation and logic of pages: while HTML(5)+CSS+JS is already
the wanted solution.  And layering is of course everywhere in software and
not only, so the same problem occurs in many places.  React is a case in point
of a very clever though utterly wrong solution to a problem that does not even
exist.

Julio

[toc] | [prev] | [next] | [standalone]

#34696

Martin Honnen wrote:

> I liked E4X and I think it would have worked

ACK.

> had there been a DOM integration but as far as I remember that never
> happened.

According to the ECMAScript Support Matrix, Firefox 1.6 to 20 had E4X 
support, i.e. before that died the Mozilla.com death.  It is a guess,
but the argument was probably the same old fallacy: “Nobody uses it.”
 
> Whether browser-side JS needs another library based API for node
> creation I am not sure, it looks like most people are happy with
> throwing there string fragments into JQuery.

Implementing Emmet would be a good idea, too, but given support in Atom 
(currently, emmet 2.4.3), somebody probably has already done it in/for 
Google V8 JavaScript.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#34699

Thomas 'PointedEars' Lahn wrote:
> Martin Honnen wrote:
> 
> > I liked E4X and I think it would have worked
> 
> ACK.

Besides the SpiderMonkey Engine, I think ActionScript was the only other implementation of it. I don't know what the state is of it there.

> > had there been a DOM integration but as far as I remember that never
> > happened.
> 
> According to the ECMAScript Support Matrix, Firefox 1.6 to 20 had E4X 
> support, i.e. before that died the Mozilla.com death.  It is a guess,
> but the argument was probably the same old fallacy: “Nobody uses it.”

The issue was security primarily [1][2]

[1] <https://bugzilla.mozilla.org/show_bug.cgi?id=788293> 
[2] <https://bugzilla.mozilla.org/show_bug.cgi?id=695577>

[toc] | [prev] | [next] | [standalone]

#34698

Martin Honnen wrote:
> Michael Haufe (TNO) wrote:
> 
> But why whould a HTML DOM allow you to create elements named "Root" or 
> "Child1" at all? An odd example at least.

Odd yes, but legal [1]

> And the LINQ object model has at least one flaw with its lack of 
> representation of prefixes in XName that makes lexical representations 
> of trees dependent on the implementation strategy to choose prefixes e.g.
>
> [...]

I agree, the overloading and side effects there are a strange choice. 

> I agree the W3C DOM is ugly, in particular with all those different 
> levels it has and the whole factory based approach and I am glad to have 
> class based alternatives like XOM or JDOM in the Java world or XLINQ in 
> the .NET world.
 
> But part of the power of XLINQ (both for composition (your initial 
> example could be shortened to
 
>    var root = new XElement("Root",
>      from i in Enumerable.Range(1, 6) select new XElement("Child" + i, i)
>    );
> 
> ) and for querying of trees) is due to the integration with LINQ and not 
> solely based on its node creation API using constructors instead of 
> factory methods.

Which we know can be emulated analogously with the new spread operator and Array.from(), and other iterable constructs
 
> I liked E4X and I think it would have worked had there been a DOM 
> integration but as far as I remember that never happened.

Removed primarily due to security and compatibility issues if you recall [2]

> Whether browser-side JS needs another library based API for node 
> creation I am not sure, it looks like most people are happy with 
> throwing there string fragments into JQuery.

Are you?

[1] <https://html.spec.whatwg.org/multipage/dom.html#htmlunknownelement>
[2] <https://bugzilla.mozilla.org/show_bug.cgi?id=788293>

[toc] | [prev] | [next] | [standalone]

#34695

Michael Haufe (TNO) wrote:

> I'm not a fan of JSX, nor was I a fan of E4X before it.

E4X would have made building trees a lot easier, but it had flaws.

> […]
> Dealing with the DOM APIs directly are terribly verbose though as we know.
> Should we not do better?
> 
> In System.XML.LINQ [3] the approach is to construct XML elements and their
> contents by nested constructors:
> 
> <script type="C#">
>   var root = new XElement("Root",
>     new XElement("Child1", 1),
>     new XElement("Child2", 2),
>     new XElement("Child3", 3),
>     new XElement("Child4", 4),
>     new XElement("Child5", 5),
>     new XElement("Child6", 6)
>   );
> 
>   Console.WriteLine(root);
> 
>   /*
>   <Root>
>     <Child1>1</Child1>
>     <Child2>2</Child2>
>     <Child3>3</Child3>
>     <Child4>4</Child4>
>     <Child5>5</Child5>
>     <Child6>6</Child6>
>   </Root>
>   */
> </script>
> 
> Should we not do similar for the dirty DOM we have to deal with?

<https://github.com/PointedEars/JSX/blob/27be459b2da4d2b8052c293d6930d0c020821de4/dom.js#L504-L663>

(The name “JSX” is coincidental; I used it first, but only the people in 
Usenet, SELFHTML.DE, and maybe Twitter, knew about it.)

> Here's what we have to contend with for the equivalent:
> 
> <script type="JavaScript">

Not Valid.

>   var root = document.createElement("root")
> 
>   for(var i = 1; i <= 6; i++) {
>     var child = document.createElement("child" + i)
>     child.textContent = i
>     root.appendChild(child)
>   }

    var root = jsx.dom.createNodeFromObj({
      type: "root",
      childNodes: Array.apply(null, {length: 6}).map(
        (e, i) => {
          return {
            type: "child" + i,
            properties: {textContent: i}
          };
        })
    });

>   console.log(root.outerHTML)

Tested on <http://PointedEars.de/>, which uses JSX:dom.js.

    [<child$i>…</…> is insane markup.]

> [tl;dr]

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#34697

Thomas 'PointedEars' Lahn wrote:

> Michael Haufe (TNO) wrote:
>>   var root = document.createElement("root")
>> 
>>   for(var i = 1; i <= 6; i++) {
>>     var child = document.createElement("child" + i)
>>     child.textContent = i
>>     root.appendChild(child)
>>   }
> 
>     var root = jsx.dom.createNodeFromObj({
>       type: "root",
>       childNodes: Array.apply(null, {length: 6}).map(
>         (e, i) => {
>           return {
>             type: "child" + i,
>             properties: {textContent: i}
>           };
>         })
>     });

Supplemental:

  1. Add 1 for equivalence :)

  2. Learning Android app development recently (again) has reminded me of
     a complementary approach: the possibility to maintain pure layout (XML)
     markup and create (widget) object( tree)s from it.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#34701

Thomas 'PointedEars' Lahn wrote:

> [...]

> Supplemental:
> 
>   1. Add 1 for equivalence :)
> 
>   2. Learning Android app development recently (again) has reminded me of
>      a complementary approach: the possibility to maintain pure layout (XML)
>      markup and create (widget) object( tree)s from it.

The ghost of XSLT+XML come back to haunt us?

[toc] | [prev] | [next] | [standalone]

#34703

Michael Haufe (TNO) wrote:

> Thomas 'PointedEars' Lahn wrote:
>> [...]
>> Supplemental:
>> 
>>   1. Add 1 for equivalence :)
>> 
>>   2. Learning Android app development recently (again) has reminded me of
>>      a complementary approach: the possibility to maintain pure layout
>>      (XML) markup and create (widget) object( tree)s from it.
> 
> The ghost of XSLT+XML come back to haunt us?

You do not know what you are talking about.  XSLT rulez (see the FAQ).

But I was not referring to that.  Rather, in Android app development, XML 
layouts are “inflated” into widget object hierarchies.  For example:

    @Override
    public ArticleViewHolder onCreateViewHolder(ViewGroup viewGroup,
      int viewType) {
        Context context = viewGroup.getContext();
        int layoutIdForListItem = R.layout.selector_list_item;

        LayoutInflater inflater = LayoutInflater.from(context);
        boolean shouldAttachToParentImmediately = false;

        View view = inflater.inflate(layoutIdForListItem, viewGroup, 
          shouldAttachToParentImmediately);
        ArticleViewHolder viewHolder = new ArticleViewHolder(view);

        return viewHolder;
    }

Then there is a file res/layout/selector_list_item.xml that contains the 
layout for a list item.  It looks like this:

--------------------------------------------------------------------------
<?xml version="1.0" encoding="utf-8"?>

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:orientation="vertical"
    android:layout_width="match_parent"
    android:layout_height="wrap_content">

    <!-- Horizontal linear layout to create a contacts list item -->
    <LinearLayout android:orientation="horizontal"
        android:layout_width="match_parent"
        android:layout_height="80dp"
        android:paddingTop="4dp"
        android:paddingBottom="4dp"
        android:gravity="center_vertical">

        <!-- Person icon -->
        <ImageView
            android:id="@+id/personIcon"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:src="@drawable/ic_person"
            android:paddingRight="4dp"
            android:paddingLeft="4dp"
            android:contentDescription="@string/person_icon"/>

        <!-- Text views for a person's first and last name -->
        <TextView
            android:id="@+id/firstName"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:textStyle="bold"
            android:textSize="24sp"
            android:textColor="@android:color/black"
            android:text="@string/first"
            android:paddingRight="4dp"
            android:paddingLeft ="4dp"/>
        […]
    </LinearLayout>

    <View
        android:layout_width="match_parent"
        android:layout_height="1dp"
        android:background="@android:color/darker_gray"/>

</LinearLayout>
--------------------------------------------------------------------------

IMHO, that approach produces very clean code¹.  It could be used in 
ECMAScript-based Web applications as well.  That is, the *validateable* 
markup defines the layout, script code reads the markup and converts it to 
description objects, and other script code produces a document fragmnt with 
elements having specific behaviors (widgets).  The layout in XML allows to 
design it with a graphical editor as well (indeed, XSLT could be used to 
make SVG out of it) almost independent of the final presentation.  The 
intermediary step would allow to adapt or entirely build the layout in 
script code without having to deal with the details of the DOM.

______
¹  The above can still be improved; it is exercise code where the student
   is supposed to replace all hard-coded values with resource references for
   achieving a unified layout throughout all “activities” of the app.
-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#34708

On Monday, 5 February 2018 11:19:26 UTC+1, Thomas 'PointedEars' Lahn  wrote:
> Michael Haufe (TNO) wrote:
<snip>
> > The ghost of XSLT+XML come back to haunt us?
> 
> You do not know what you are talking about.  XSLT rulez (see the FAQ).

Your utter bullshit isn't any better.

> script code without having to deal with the details of the DOM.

Rather learn and use *Knockout.js*: it's not just a fantastic little tool, it's
(along the lines of) the right architectural approach, indeed the exact opposite
of your upside down fuck ups.

HTH,

Julio

[toc] | [prev] | [next] | [standalone]

#34713

Thomas 'PointedEars' Lahn wrote:
> Michael Haufe (TNO) wrote:

> > The ghost of XSLT+XML come back to haunt us?
> 
> You do not know what you are talking about.  XSLT rulez (see the FAQ).

Ha, you don't need to convince me. I've commited XSLT sins in the past for the hell of it: <view-source:http://ht2012.org/index.xml>

> But I was not referring to that.  Rather, in Android app development, XML 
> layouts are “inflated” into widget object hierarchies.  For example:
> 
>     @Override
>     public ArticleViewHolder onCreateViewHolder(ViewGroup viewGroup,
>       int viewType) {
>         Context context = viewGroup.getContext();
>         int layoutIdForListItem = R.layout.selector_list_item;
> 
>         LayoutInflater inflater = LayoutInflater.from(context);
>         boolean shouldAttachToParentImmediately = false;
> 
>         View view = inflater.inflate(layoutIdForListItem, viewGroup, 
>           shouldAttachToParentImmediately);
>         ArticleViewHolder viewHolder = new ArticleViewHolder(view);
> 
>         return viewHolder;
>     }
> 
> Then there is a file res/layout/selector_list_item.xml that contains the 
> layout for a list item.  It looks like this:
> 
> --------------------------------------------------------------------------
> <?xml version="1.0" encoding="utf-8"?>
> 
> <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
>     android:orientation="vertical"
>     android:layout_width="match_parent"
>     android:layout_height="wrap_content">
> 
>     <!-- Horizontal linear layout to create a contacts list item -->
>     <LinearLayout android:orientation="horizontal"
>         android:layout_width="match_parent"
>         android:layout_height="80dp"
>         android:paddingTop="4dp"
>         android:paddingBottom="4dp"
>         android:gravity="center_vertical">
> 
>         <!-- Person icon -->
>         <ImageView
>             android:id="@+id/personIcon"
>             android:layout_width="wrap_content"
>             android:layout_height="wrap_content"
>             android:src="@drawable/ic_person"
>             android:paddingRight="4dp"
>             android:paddingLeft="4dp"
>             android:contentDescription="@string/person_icon"/>
> 
>         <!-- Text views for a person's first and last name -->
>         <TextView
>             android:id="@+id/firstName"
>             android:layout_width="wrap_content"
>             android:layout_height="wrap_content"
>             android:textStyle="bold"
>             android:textSize="24sp"
>             android:textColor="@android:color/black"
>             android:text="@string/first"
>             android:paddingRight="4dp"
>             android:paddingLeft ="4dp"/>
>         […]
>     </LinearLayout>
> 
>     <View
>         android:layout_width="match_parent"
>         android:layout_height="1dp"
>         android:background="@android:color/darker_gray"/>
> 
> </LinearLayout>
> --------------------------------------------------------------------------

While I like the declarative nature, the use of layout containers I find iffy. How you do manage dynamic layouts? 

> IMHO, that approach produces very clean code¹.  It could be used in 
> ECMAScript-based Web applications as well.  That is, the *validateable* 
> markup defines the layout, script code reads the markup and converts it to 
> description objects, and other script code produces a document fragmnt with 
> elements having specific behaviors (widgets).  The layout in XML allows to 
> design it with a graphical editor as well (indeed, XSLT could be used to 
> make SVG out of it) almost independent of the final presentation.  The 
> intermediary step would allow to adapt or entirely build the layout in 
> script code without having to deal with the details of the DOM.

Validation the most important aspect IMO. It's a damned shame this was thrown away in HTML5 in preference for hand-wavery: 

<https://github.com/validator/validator/issues/251#issuecomment-192209209>

[toc] | [prev] | [next] | [standalone]

#34715

Michael Haufe (TNO) wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Michael Haufe (TNO) wrote:
>> > The ghost of XSLT+XML come back to haunt us?
>> You do not know what you are talking about.  XSLT rulez (see the FAQ).
> 
> Ha, you don't need to convince me. I've commited XSLT sins in the past for
> the hell of it: <view-source:http://ht2012.org/index.xml>

:)
 
>> [Android layout XML] 
> 
> While I like the declarative nature, the use of layout containers I find
> iffy. How you do manage dynamic layouts?

Depends.  “Dynamic” as in…?

> Validation the most important aspect IMO. It's a damned shame this was
> thrown away in HTML5 in preference for hand-wavery:
> 
> <https://github.com/validator/validator/issues/251#issuecomment-192209209>

Hmmm.  HTML5 validation is actually more strict than HTML < 5 validation, 
enabled by a grammar that is algorithmic instead of declarative.  But this 
also makes it more difficult to implement.

XHTML5 is only XML in name as HTML5 is by design and specification the 
antithesis to XHTML (unspecified elements and attributes are allowed, the 
latter are even encouraged with “data-…” attributes, SVG and MathML can be 
embedded without declaration), so I can understand the lack of desire to 
specify a schema for it.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#34720

Stefan Ram wrote:

> "Michael Haufe (TNO)" <tno@thenewobjective.com> writes:
>>As in, if I rotate the screen and I want LinearLayout to
>>become RelativeLayout, what do I do?
> 
>   One can save XML files into one's project folder like
> 
> res/
>     layout/
>         main.xml (Default layout)
>     layout-port/
>         main.xml (Specific layout for portrait mode)
>     layout-land/
>         main.xml (Specific layout for landscape mode)
> 
>   This will become packed into a kind of archive file, and the
>   system will choose the most appropriate layout at runtime.
>   When a device is rotated, the whole "Activity" is being
>   rebuilt from scratch, so it then can have a new layout.
> 
>   Of course, you also can achieve similar results with Java alone.

If you want to create a maintenance nightmare, and a slow application that 
nobody will like.  There is *much* *more* to suffixed resource directories 
than screen mode.

RTFM!

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#34721

Michael Haufe (TNO) wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Michael Haufe (TNO) wrote:
>> > Thomas 'PointedEars' Lahn wrote:
>> >> [...]
>> >> [Android layout XML]
>> > 
>> > While I like the declarative nature, the use of layout containers I
>> > find iffy. How you do manage dynamic layouts?
>> Depends.  “Dynamic” as in…?
> 
> As in, if I rotate the screen and I want LinearLayout to become
> RelativeLayout, what do I do?

Suppose you have res/layout/activity_main.xml that uses LinearLayout, then 
create res/layout-land/, copy the XML file there (keep the filename), and in 
the copy change LinearLayout to RelativeLayout (but see also 
RecyclerView.LayoutManager subclasses, which work better with listings). 
Now, that does _not_ mean that you have to maintain all the *content* twice 
(or more): you can use *fragments* to include the same content in different 
view groups.  (In the course we learned to use fragments precisely for 
handling landscape mode.)

See also:
<https://developer.android.com/training/basics/supporting-devices/screens.html>
<https://developer.android.com/training/basics/fragments/index.html>

And that is only one of many specializations that you can implement this way 
(which I called “suffixed resource directories” before).

    [One of them that ought also be mentioned is internationalization, which 
     (AISB) would be a PITA if you did in in Java code: just create e.g.
     res/values-fr/strings.xml for the text that should be displayed when
     the user uses the French locale.  If you refer to “@string/…” in your
     layouts, or use getString(R.string.…) throughout your Java code, then
     you may not have to customize anything else (of course, French words
     tend to be longer, so maybe it needs layout tweaking, too).  You can
     give that XML file to your translators, and its structure is very
     simple so they do not have to be coders also, as with GNU gettext. 
     Compare that to language switches in Java code.

     <https://developer.android.com/training/basics/supporting-devices/languages.html>]

This also has to do with what I alluded to earlier: As *you* know, if you 
have XML, you can easily convert it to *anything* using XSLT (even on the 
fly), for example SVG.  I do not know how Android Studio 3.0.1 does the 
visualization, but it also contains a visual layout editor.  If you select 
there that you want a specific landscape layout, for example, then it does 
what I described above (except the last step), and opens the copy.

    [However, if you know in advance that you want displayed properly in 
     both modes, you should first consider using a layout manager that does
     it automatically, such as a ConstraintLayout that uses resources for
     the spacing.]

If you are seriously interested in learning Android development, I can 
highly recommend taking part in the Google Android Dev Challenge:

<https://eu.udacity.com/course/android-developer-nanodegree-by-google--nd801>

The next Challenge should start in November, but you can start the 
nanodegree at any time.  If the Challenge is on, and you submit a convincing 
rationale (like I did), you might even win the scholarship and do not have 
to pay anything for the course and the optional follow-up training that 
Google offers exclusively.

>> Hmmm.  HTML5 validation is actually more strict than HTML < 5 validation,
>> enabled by a grammar that is algorithmic instead of declarative.  But
>> this also makes it more difficult to implement.
> 
> s/algorithmic/procedural

To me, procedural includes the concept of subroutines, which need not be the 
case with parser algorithms like those for HTML5.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#34726

Thomas 'PointedEars' Lahn wrote:
> Michael Haufe (TNO) wrote:

> > As in, if I rotate the screen and I want LinearLayout to become
> > RelativeLayout, what do I do?
> 
> Suppose you have res/layout/activity_main.xml that uses LinearLayout, then 
> create res/layout-land/, copy the XML file there (keep the filename), and in 
> the copy change LinearLayout to RelativeLayout (but see also 
> RecyclerView.LayoutManager subclasses, which work better with listings). 
> Now, that does _not_ mean that you have to maintain all the *content* twice 
> (or more): you can use *fragments* to include the same content in different 
> view groups.  (In the course we learned to use fragments precisely for 
> handling landscape mode.)

Sounds far worse than what CSS+HTML provides (flex and grid). I know JavaFX supports CSS for layouts, but I can only imagine what a combination of "hbox" and "flex-direction: row" would do...

> [...]

> If you are seriously interested in learning Android development, I can 
> highly recommend taking part in the Google Android Dev Challenge:

Afraid not, after building a Scala compiler + implementing 0CFA and friends on top of it, I've been holding off having to touch the environment again for a significant time. Let's call it another form of PTSD...

<https://gist.github.com/mlhaufe/c5cbe38f35c2a7238bd797eebec06418>

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.javascript

csiph-web