Html should be immutable

[GoogleCodeExporter]

If Html was an immutable object it would be much easier to do composition, in 
particular with frameworks like functional java.

Original issue reported on code.google.com by tryg...@gmail.com on 13 Jan 2011 at 1:35

[GoogleCodeExporter]

Hey man thanks for your comment.

You are correct that it would be nicer if the "Builders" were immutable like 
Lisp Cons cells or Haskell Monads. 

The library is more of a Stream Writer than a element builder (builder was a 
bad choice of naming on my part). Thus the library is stateful and does have 
side effects.

This was a conscience decision motivated by speed and memory footprint. Java is 
just not an ideal language for creating Immutable data types because other than 
java.lang.* types it does not know how optimize memory like Lisp does for 
Con-cells.

I will say the libraries I was inspired by (JQuery and Groovy's builders) also 
have these problems. 

Original comment by adam.g...@evocatus.com on 27 Jan 2011 at 3:49

[GoogleCodeExporter]

It's your call, but I think you are really underestimating the performance of 
the JVM with its escape analysis and all.

As it is now the library is just too hard to use when I have to manage the 
state, and I find it very hard to actually do composition as you have to pass 
the reference in all over the place, testing is becoming even more verbose.

Original comment by tryg...@gmail.com on 27 Jan 2011 at 8:39

[GoogleCodeExporter]

The idea for handling composition is by adding methods to your own builder kind 
of like JQuery plugins. I usually make one Custom Builder class for a project 
and add all my composition methods there for simplicities sake. 

If you want to spread your composition logic out you could use AspectJ ITDs 
(which scare people for some reason) to achieve Scala like traits.

Here is an example custom builder:

    /**
     * My own custom HTML Builder.
     * This is akin to making a JQuery plugin
     * except that Java does not have mixins (Traits).
     * 
     * @author agent
     *
     */
    public abstract static class CustomBuilder<T> extends HtmlBuilder<T> {
        /*
         * Put Custom methods here.
         * This where you can do composition.
         * A slight annoyance is that you cannot do dotted notation.
         */

        public T list(String ... ss) {
            ul();
            for (String s : ss) {
                li(); text(s);
            }
            end();
            return getSelf();
        }
    }

    public static class Custom extends CustomBuilder<Custom> {

        @Override
        protected Custom getSelf() {
            return this;
        }

    }

Original comment by adam.g...@evocatus.com on 28 Jan 2011 at 3:40

[GoogleCodeExporter]

Your probably right about the JVM but thats not the issue really. If you wanted 
to write out a 100 MB HTML file (a html table with 1000s of rows) you would 
have lots of objects in memory if your library consistently used composition of 
objects.

This library is a stream based so it only uses the amount of memory that you 
buffer. If you look at some of the more modern functional languages like 
Clojure they have take a stream approach (Sequences) instead of a composition 
approach (Lists).

If you post some code I might be able to help :)

Original comment by adam.g...@evocatus.com on 28 Jan 2011 at 3:48

[GoogleCodeExporter]

This actually a request for enhancement that will unlikely not be done.

Original comment by adam.g...@evocatus.com on 31 Mar 2011 at 3:44

• Added labels: Priority-Low, Type-Enhancement
• Removed labels: Priority-Medium, Type-Defect