Subject: I agree completely!
-
I have (hopefully) only ever said (in this thread) that XPages are a complete no-go for migrating complex legacy applications, implying retention of legacy code. I’ve indicated they could be the cat’s meow for new development, which would include (perhaps incorrectly) a complete rewrite of a legacy application to use the XPages model.
-
I know XPages are the future. I didn’t know, when I started, that XPages were a complete disconnect from the past, because every single blog, forum post, and wiki I could find indicated how XPages work so well with legacy code. Bull. XPages suck with legacy code in a way that makes a daily enema look pleasant.
-
I also have stressed complexity many times. My code is 25,000 lines of OO class hierarchy that I wanted to keep, rather than rewrite. With all the time I’ve wasted on the non-compatibility with legacy code, I could have rewritten all that code. But I was led to believe XPages work, and I can keep my code, so I went down that path. Now it’s so late in the game I can’t turn around. I don’t want someone else to get stuck. I want them to avoid XPages, or rewrite their legacy application from scratch. Those are the only viable options.
That is all I am and hopefully all I ever have said in this thread, which was started by someone asking why use XPages for legacy migration. The answer is don’t.
But yeah, I hear where you’re coming from. I guess they can co-exist well with legacy code, but they certainly don’t leverage it well. As far as I’m concerned the only legacy code they do connect to well is ACL settings, views, docs, and (to a very minor extent) forms.