Digi v2 - Simplify!
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
:-)