I'm more and more interested in web components as a technology. Apparently out there there are two ways to do components:
On one hand there are implementations like Bosonic, Polymer or X-Tag, where you can define new components that extend the HTML vocabulary, and they seem to search some common ground. The big thing that concerns me is actually shared behavior, since no one uses raw JS contexts anymore. Can you truly do that, without reinventing the wheel, without a new framework? Is integration with existing frameworks easily done for non-trivial components? (e.g. a calendar component might need data validation, that is offered by the framework, like YUI3 for example).
Another approach is to create a widget system, like GWT composites, or YUI widgets, and the idea is that you can have widgets reusing widgets, and generally build really powerful abstractions on top of that, sticking for the most part to HTML (eventually with extensions - GWT works with XHTML and different namespaces). There are other variations in using different templating engines (e.g. handlebars), different UI class hierarchies, but the general idea is the same. You have widgets that are pure JS objects from the framework, tied to some visual representation, with composition part of the API either declaratively (by templates) either imperatively (e.g. a calendar widget manually creates the input widgets, spans and divs it needs for its visual representation, and keeps references to them).
The difference that I see is that extending the HTML vocabulary in theory could provide a unifying common platform, allowing me (allegedly) to reuse the components across frameworks and also get a far more clean markup, since now the markup describes real components (instead of a bunch of divs that are bounded by some voodoo JS behind the curtains pulling all the logic strings).
But I have a feeling the real challenge is framework integration, and that's why Angular didn't jumped into the Polymer bandwagon even if they are made both by people from the same company.
I have this idea, where we should by convention name all the iterables P or D.
So iterating over a list would become:
Obviously cryptic as hell, but the code will smile back at you.
Who said dynamic languages can't be fun to debug?
So here's the problem.
You have a webapp that packs two jars A.jar, and B.jar. A depends on C.v1.jar, but B depends on C.v2.jar. Both C jars include the same class with different signatures, because they are different, incompatible, versions.
I can hear you sighing from here.
There are actually a few solutions:
1. OSGI. If you can figure it out, it can actually do the classloader magic for you.
2. If you're like me you can use the WEB-INF/classes, since these classes are loaded in a classloader that has priority over WEB-INF/lib classes, and attempt to do via sources, or a decompiler (JD-GUI) a conflicting class that is compatible with both A and B. But that's error prone, and is a LOT of work, for more complex changes in API.
3. JarJar. With JarJar you can rename a package to another package, and it will also rename all the references in the classes. So you can just pick for example B and C.v2.jar, and rename the conflicting packages or classes (directly inside the jar themselves).
4. Project JigSaw, seems to be adressing just that, but this appears to be available only with Java 8 unfortunately.
Personally I used JarJar. Seemed by far the easiest to use, and worked flawlessly.
Turns out to be BZIP2.
Considering that most of it is actually already compressed ZIP data (the JRE), it's an outstanding performance.
The one to rule them all. The browsers that is.
SharpKnight is an Android chess game.
MagicGroup is an eclipse plugin.