- based on GenericPortlet, can be deployed into any available JSR-168 portal server
- simple and easy to develop with the framework
- MVC model similar to Struts (command, action, validator, etc)
- easy upload file from portlet
- no additional configuration
Simflet is an open source simple framework for portlet development. The reason it's been written? Because there is no proper MVC model in the Portlet API. As a result, portlet development is like servlet development: complex applications aren't easy, because of the infrastructure issues. There are many well-known frameworks such as JSF, Struts, Spring, etc., for portlet development, but they require something like portlet-bridge and they are not always successful in different portal servers, or they require some extra configuration or setting during the development. This increases development time. Features of Simflet:
- Posted by: Eric Chow
- Posted on: July 05 2006 06:55 EDT
- Great, more web frameworks... by Erik van Oosten on July 05 2006 07:17 EDT
- What for? by Andreas Schmitz on July 05 2006 07:17 EDT
- Re: Simflet: Another open source simple MVC framework for portle by Fredrik Borgh on July 05 2006 08:57 EDT
- Use JSF instead by Stan Silvert on July 05 2006 09:57 EDT
- Re: Use JSF instead by Oliver Wehrens on July 05 2006 11:23 EDT
- Re: Use JSF instead by Eric Chow on July 05 2006 12:21 EDT
- Re: Use JSF instead by Dean Schulze on July 05 2006 14:28 EDT
- no more frameworks. just do your own thinking. by Pieter Hertogh on July 06 2006 05:09 EDT
- Re: Simflet: Another open source simple MVC framework for portle by Andriy Tsykholyas on July 06 2006 05:15 EDT
I'll value the day when TSS opens with 'No new web framework published this month' ;^) I hope Simflet will get the success they deserve, but I'll stick with Spring Portlet MVC for now. Initial setup is indeed inconvenient, but after that progress is quick.
I think that opensource framework development is just like crossing a river by stepping on randomly positioned rocks. You need to make a lot of steps but as long we head forward it's just fine. I think that there will not be any end-of-the-road web framework that will make us happy until the end of time. Some frameworks solve problems others do not. And more than that, it keeps the nigth-time researching alive. If we move forward depends on how much we think about it. If we'll Sun to think for us it might take to much loong...
There's a Struts and a JSF Portlet framework. http://publib.boulder.ibm.com/infocenter/wpdoc/v510/topic/com.ibm.wp.ent.doc/wps/wpsstruts.html http://portals.apache.org/bridges/
I'm just waiting for "Pamflet - a MVC framework for the missionary who wants a clear separation between model ('facts') and view (interpretation)" ;-)
The reason it's been written? Because there is no proper MVC model in the Portlet API. As a result, portlet development is like servlet development: complex applications aren't easy, because of the infrastructure issues.This is incorrect. JSF was designed with portlets in mind. Why would you use some new MVC framework for portlets? JSF is loaded with features, components, and tool support. It's just as easy to create portlets with JSF as it is to create servlet-based apps. In fact, its pretty easy to create a JSF app that works as a portlet or as a servlet. Stan Silvert JBoss, a division of RedHat
Well according to the JSR 286 Expert Group (have a look at Stefan Heppers Slides from JavaOne) and some discussion I had with some of the members, in the next spec we all want to see better support of web frameworks (like JSF, Struts, Spring). Why is that? Because JSR 168 & e.g. JSF don't play too well together. I do not say it is impossible but it is still not mainstream, I wonder why, both specs are out for some time now. Oliver
<blockquoteIn fact, its pretty easy to create a JSF app that works as a portlet or as a servlet.</blockquote> You are right. It is easy to create JSF application but as I know and tried to create a JSF with Sun RI cannot be deployed in JBossPortal 2.2. I also had some experience that need to modify some code to adapt to the specific portal server. Maybe JSF will be comfortable adapt to any portal server when JSR-286 spec release. We can imagine that why J2EE grows up so slow in the past years. It is because people scare of it and think it is very difficult to learn. After some MVC framework out of the world, developers eager to use it. Anyway, Simflet just another choice for portlet developer fell more easy to begin their portlet application development. None of the framework can handle all the real world cases. Helpful and simple are all we wish. Eric
So, Stan, what is the status of JBoss Portal's support for JSF portlets? I was working with Oracle's Portal earlier this year and was surprised that I couldn't use their ADF to create Portlets. Here's a posting from January detailing their plans to add ADF support to their Portlets - at some point in the future.
So, Stan, what is the status of JBoss Portal's support for JSF portlets?I can't speak for Oracle or ADF, but JBoss Portal does support JSF portlets and has done so for over a year now. We are using the JBoss JSF Portal approach for most of our in house development. There is some confusion from the poster above who was trying to use the Sun JSF implementation. You can use any JSF implementation you want if you remove the JSF impl that ships with the App Server. But there is little or no technical reason to do this. JSF is a standard, so just use the impl that ships with the app server. This becomes even more compelling in JSF 1.2/JEE 5 where the app server adds dependency injection for managed beans. Stan Silvert JBoss, a division of RedHat
I was working with Oracle's Portal earlier this year and was surprised that I couldn't use their ADF to create Portlets. Here's a posting from January detailing their plans to add ADF support to their Portlets - at some point in the future.
Sounds great. Are there any docs on writing JSF Portlets for JBoss?
Clearly, some form of MVC portlet is desirable, JSF or otherwise-- however, I really see no point in a framework that is GPL'ed-- why should I be forced to make my portlets GPL as well?
portlet development is like servlet development: complex applications aren't easy, because of the infrastructure issues.It is such a relieve to develop portlets without yet another framework. Sure... you are not going to put all business logic in one portlet class. That would be clumsy for an app that holds more than one state/jsp. But there are great alternatives. Even without struts or JSF. Just look at this excellent developer works article: http://www-128.ibm.com/developerworks/websphere/library/techarticles/0312_hanis/hanis1.html I know this article is written for the IBM API but it is just as valid for the jsr168 API. We use this State Pattern a lot, and even have a few helper classes and custom tag’s to speed up development. But I’m not saying this approach is slow though! It’s fast and simple! A framework always adds restrictions (I had this a lot with Struts and JSF, especially within the Portal) and they really do not add much over just implementing your state pattern. The big gain of using the state pattern over any framework is you are back in control.
There are many well-known frameworks such as JSF, Struts, Spring, etc., for portlet development, but they require something like portlet-bridge and they are not always successful in different portal servers, or they require some extra configuration or setting during the development. This increases development time.Tapestry framework allows development of portlet application like servlet application. No bridge is required. You can also develop and test your application as a servlet application (which is much faster) and only on final stage switch to portlet.