• Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

Comments (2)

1 localhost commented Permalink

I am in charge of setting the direction for developement at a large company. With previous portal programming, it seemed that everyone used a different framework, usually something they cooked up or worse, to program portlets. With the new RAD/Portal5.1/JSR168 environment we are using, I am going in the direction of using Struts as a basic framework. I have coded two portlets in it already and think it's great. It usually takes care of the render phase for you, which I think simplifies programming and eliminates many "if" statements there and in the action phase.The biggest reason for this move, however, is that I feel most of our programmers already know Struts! It seems that your article says that it is another layer of complexity, however, it seems to me that it is a layer of abstraction that reduces the complexity. I do understand that with layers of abstraction you loose funcionality.Do you have any thoughts on all this? What do you mean by your statement, "This will be more of a problem if you want to take advantage of specific portal functionality within your code." Is there a lot of funcionality that is lost with Struts. Is IBM dedicated to supporting this in the future?Thanks for your time!

2 localhost commented Permalink

These are great questions. My intention was not to scare anyone off of using a framework, just to use it for the right reasons. Since most of your developers are already experience in Struts, it probably makes good sense not to stray from this approach and take advantage of the experience within your team. Your comment that Struts provides a good layer of abstraction is correct, however the developer still needs to learn a lot about the things that a portal framework provides and how to take advantage of portlet modes, and services such as portlet communication. As far as I know you don loose any functionality with the Struts Portal Framework, but in the past it has been tricky to implement some portlets that were simpler with just the portlet API. For folks that don know Struts this can be a bit daunting, whereas for your team it could be looked at as an extension of their current knowledge base.I seriously can make any official statements about support for Struts going forward. I fairly confident that the Struts Portal Framework is used by many of our customers. It has been extended to support JSR 168 portlets as well as we continue to grow the portals capability.

Add a Comment Add a Comment