Is XMLC a dead project? Is anyone using it?
From an e-mail I received a while back:
I'm interested in hearing your opinion of XMLC? And when will we see it in AppFuse? ;-) Seems to me that with it's base in xml and all the ajax and SOA hubub that it could be primed for a resurgence. And what about BarracudaMVC as an AppFuse option?
My response:
I've seen XMLC come up every so often, but it seems to be a dead project. Is it still being developed? There don't seem to be a whole lot of people using it.
His reponse:
It's not dead yet. It's still a big part of Enhydra and BarracudaMVC
both of which have quite a bit of ongoing development but XMLC it's self
is mostly one guy, Jacob Kjome. He does put in a lot of work and still
actively releases updates, just recently a Xerces2 compatible version
with full DOM3 capabilities and lots of bug fixes and such.
Actually, the Enhydra framework now comes with an alternative to XMLC
called Jivan - I haven't used it yet but they
claim significantly better performance than XMLC.
I used Enhydra/XMLC for my first 6 years as a java web developer. Then I
got a new job and for the last 3 years have been working on a
home-brewed jsp/servlet nightmare of a presentation framework for a
high-volume production system. It's absolutely painful. I would take a
pay cut to be able to use XMLC again ;-)
Honestly, I still don't understand why XMLC hasn't become more popular.
The pure Java nature of programming with XMLC is really nice.
What do you think? Is XMLC a dead project? Is anyone using it? I'm interested in both positive and negative opinions.
I would say the positives of xmlc is multiplied if you use eclipse or any other ide that does background compiling and error highlighting. If you change html code by removing form fields or something then you end up with broken code which is sort of like a free unit test.
One thing that I really don't like about it is that it doesn't seem to integrate into our build too well. We wrote an ant task to compile it but you have to run it after you make any significant changes to the xml. Another thing that bothers me is that it seems difficult to create nested structures, and dynamically created lists using xmlc. We also end up outputting invalid xml since we use the element id's to reference the objects in the document and they get duplicated when manipulating the pages.
All in all, I feel like it's a pretty reliable tool that gets the job done for us. We probably should invest some time in into figuring out how to use it better but you know how that goes...
Posted by Paul Oswald on November 15, 2006 at 11:59 PM MST #
What I've also found is that XMLC does a better job of separating presentation (HTML) development from logic (Java) development than virtually anything else out there, because it provides two key features that no other templating language does (at least not together):
- templates are pure HTML - no custom tags, no weirdo tag attributes, no scriptlets, no funky custom namespaces - this allows the HTML developer to fully utilise the HTML authoring tools they know and love
- templates can contain embedded mockup data that gets stripped automatically by XMLC at build time (so no runtime performance hit)
The combination of these two features is very compelling - it allows XMLC to come very close to realising the dream of cleanly separating presentation development from logic development. In contrast most other templating systems end up requiring one of two things:- the presentation developer prepares mockups which are then painstakingly translated into templates by a logic developer (which introduces the risk of copy 'n' paste errors)
- the presentation developer has to learn some of the vagaries of the templating environment (custom tags, weird tag structures, etc. etc.)
IMVHO this is probably the single biggest advantage XMLC has over anything else out there.On the downside, because XMLC effectively compiles the templates into your Java code (which is nice from a performance perspective, but makes templates build-dependent), it's not really suitable for systems where templates change with greater frequency than the application itself.
Posted by Peter Monks on November 16, 2006 at 11:50 AM MST #
XMLC offers the cleanest separation of view layout and view logic available. This is especially beneficial in cases where the developer is not the graphic designer. It allows them both to fulfill their specialized roles without adversely impacting the other person.
I'm also a big fan of the compile time checking. If there's one thing I hate it's having to start the application and manually check that something works at run-time when you could catch it earlier in the build process. Catching errors at compile time makes my program more robust and makes me more productive.
I somewhat agree with the first 2 posters about the level of inconvenience when creating nested and list structures. However, after doing this a few times, it's not terribly difficult to develop some utilities that make the task less painful.
Removing the id's is also a bit tedious but only necessary if you need a valid DOM. Again, this problem can be addressed easily enough as you do this more and more and extract the painful parts of the process into utility classes.
I don't know why some higher level utilities have not been rolled into XMLC. I suspect they're trying to keep it simple and focused and let people build on top of it instead of rolling it all in.
Posted by Jeremy Ferry on November 17, 2006 at 01:35 PM MST #
However, ever since the rise of CSS layouts I've been moving toward the viewpoint that HTML actually is married to the code. Changing how it's laid out on the page is done in CSS but determining what data goes on the page is more a function of your business objects. Currently my XMLC templates are a bare skeleton of what the page will finally look like when rendered and I almost never bother to look at them in their pre-xmlc form. If I wanted to keep it all in Java, I would actually prefer a framework that let me build the output page from scratch. The templates are just a formality for me now. Something like _why's markaby library in ruby would do.
We've since dropped one of our "themes" and now are styling code with CSS more and more. We build a web application where each developer works on a vertical section of code and the CSS ties it all together. If I were starting a web application from scratch, instead of a programmer and a web developer, I would hire an interface designer who has a good understanding of information design, xhtml and CSS and can lay out the business objects in a sensible manner and a programmer who has a good understanding of Java, the w3c and xhtml.
Posted by Paul Oswald on November 18, 2006 at 04:08 PM MST #
Posted by Petr Stehlik on November 20, 2006 at 02:46 AM MST #
We are now even using XMLC together with XForms implementations (Chiba + Formfaces) which can (as in the case of Chiba) again use AJAX of course !
Alfred Madl
Posted by Alfred Madl on November 20, 2006 at 03:36 AM MST #
XMLC is great. it's the only product that allows to have a very clean separation of development between the developer and the designer. I love accessing the DOM via Java.
The drawback to XMLC is that the ID/classes can sometimes conflict with our CSS use. Also, the Enhyrda framework can be a bit too much overhead for smaller projects, and the upgrade path for it has become a pain (compared to in the past, when it was run by Lutris).
For smaller/quicker projects, Ruby on Rails makes a lot more sense. It's built in structure for business layer code, and automated database development/test/production upgrades are simply AMAZING to work with.
We still use XMLC, but we rarely start any new projects with it. The problem is Enhydra. The overhead is too large, it lacks many of the newer niceties of projects like Ruby On Rails, the upgrade path always causes us trouble (each new release of Enhydra seems to require coding changes in our 40+ enhydra project environment, which is NOT fun), and usually, with very large projects where Enhydra is well-suited, the client is often demanding ASP.NET.
Posted by Joe Osburn on November 20, 2006 at 11:47 AM MST #
And yes unfortunately there is a learning curve with XMLC. Concerning IDE integration, there is an old project on SourceForge xmlceclipse. Unfortunately it's not being maintained, and I haven't had the time to work on it. It's an XMLC plugin, but it stopped working around Eclipse 3.0 because of the new Plugin API changes. It builds the code in the background as you save the files in Eclipse, immediately flagging HTML errors, or other problems, with indicators next to the lines with problems. No seperate ant builds, wizards etc. are required when using the plugin. Someday if I get time I'd like to try to convert it.
All in all, I think the benefits of XMLC out-weigh the perception that it's too hard to use.
Mike Warne
Posted by Mike Warne on November 20, 2006 at 12:59 PM MST #
Posted by Justin Akehurst on November 20, 2006 at 01:08 PM MST #
XMLC also enables you to do some things very easily, like for security, to remove page elements from the page at page rendering time that the user is not authorized to view
Posted by Robert Blumen on November 20, 2006 at 01:10 PM MST #
I am now at a new position would consider XMLC again, although we do the majority of our rendering in AJAX so the server side rendering framework is less important now. I am also evaluating Spring, and might explore using XMLC as the Spring view.
Posted by david michaels on December 09, 2006 at 03:14 AM MST #
Posted by Russell Scheerer on June 27, 2008 at 08:12 AM MDT #
Posted by Justin Akehurst on June 27, 2008 at 08:57 AM MDT #
Posted by david michaels on June 27, 2008 at 02:09 PM MDT #