The version 2 of Digi is going to be all about simplification and the productivity of code-creation. Personally, I think, we have achieved quite rich feature-support in version 1 and left place for bigger enhancements to be possible. What we have come short (and I am not surprised or disappointed as it\’s just version 1) is the ease-of-development. So, now it\’s time to Simplify.\r
\r
As the simplifications go, there are two obvious things, in my mind:\r
\r
1) Struts coding is too verbous. I would like to see more defaults implemented in Digi, so that if you follow naming conventions (roughly: your view file has the same name as your action class and form bean etc.), in 80% of standard cases you would not need to write anything in a struts-config.xml. For the rest 20% (or a large part of it) it would be nice to have something simpler than a bloated XML config. For example, Apache Beehive looks quite interesting for this task.\r
\r
2) JSP is a pain. We\‘ve had enough of it. I like Tapestry UI approach much more. Let\’s see if we can painlessly swap it in.\r
\r
and I, also, want:\r
3) Simplified module customization capabilities. Let\’s prove Oracle dudes, that modules can be customized beyond the UI layer, and it is not such a rocket-science.* The Proof of Concept code, we have, makes me quite optimistic. Let\’s see…\r
\r
——————–\r
*This is in regard with an Oracle session, held in Wash, DC, where Thomas Kurian, the SVP of Development, Oracle, told me that when they talk about flexible customization features in Oracle portal suite, they just mean the UI layer, by far, and beyond that - it is too complicated. This reply has disappointed me as much as he seemed to have hated my question :-)