One of the hardest things I did in JSF was to integrate a dynamic URL parameter which is forms based into an applet with JSF. Specifically, use ImageJ's applet.
Has this been made easier? John -----Original Message----- From: Leonardo Uribe [mailto:lu4...@gmail.com] Sent: Wednesday, September 07, 2011 3:04 PM To: MyFaces Discussion Cc: Carlson, John W.; Java Programmers List Subject: Re: Include Form into existing JSP Hi Interesting points. I can answer some of them quickly: JC >> Try developing a mostly read-only/downloads application...JSF is overkill for that. With JSF 2.0 you have a template framework to build views easily, just writing html and use a couple of components for the most complex task (facelets templating and composite component features are highly productive creating html/css/javascript mashups). Additionally you can provide a custom ResourceHandler to deal with special resources for your download files. There is a proposal for JSF 2.2 to include viewActions, like in some other web frameworks like struts. See: http://seamframework.org/Documentation/JSFEnhancementViewActions It is a work in progress, so let's see what happen. JC >> I've been thinking about using Opa http://opalang.org/ Interesting idea. Really it is difficult to compare both of them, because JSF is a web framework built on top of Java Servlet technology, and the other is a complete new language. I can't help in that because I don't really know how that framework works. JC >> Also, caching is a nightmare with JSF. .... A good application framework JC >> would support both w/o the application developer having to build their own JC >> cache and refresh technology. JSF provide some interfaces to deal with data sources. Really this problem is more related to the technology you use to get the data (JPA, JDBC) than from the web framework. Usually these type of problems can be solved with good design practices. The "refresh" problem is a complete different problem. What do you need for that is have some kind of "window" scope. MyFaces CODI provide a solution for that one. This is another proposal target for JSF 2.2. Let's see what happen. It is not an easy topic after all. JC >> The amount of overhead and memory required to run JSF is a concern. With JSF 2.0 a new method to save the state of each view on the server was developed (PSS). In few words it just save the "delta" or changes on the state of the view, reducing the memory required. Other improvements has been done in MyFaces to reduce the amount of memory used and increase performance. Really a lot of effort has been done to detect memory leaks and other issues, so the latest code looks very good. In practice, other things in your application can become a big problem from memory, but usually the impact of the web framework used is not a concern. regards, Leonardo Uribe 2011/9/7 Carlson, John W. <carlso...@llnl.gov>: > Small typo, meant w/o instead of w/ > > -----Original Message----- > From: owner-j...@lists.llnl.gov [mailto:owner-j...@lists.llnl.gov] On Behalf > Of Carlson, John W. > Sent: Wednesday, September 07, 2011 1:28 PM > To: Leonardo Uribe > Cc: MyFaces Discussion; Java Programmers List > Subject: [java] RE: Include Form into existing JSP > > @John: it could be good to know if your reasons to object JSF. In my > understanding JSF 2 solved many of the problems, and it have some very > useful features. Maybe if some idea is enough useful, myfaces > community can push to include it on next JSF 2.2 spec. Suggestions, > critics and tomatoes are most welcome ;-). That's how innovation > works, right? > > Try developing a mostly read-only/downloads application...JSF is overkill for > that. > State your reason for using JSF for a read-only/downloads application. > > I've been thinking about using Opa http://opalang.org/ Compiles to exe. > Please study Opa make Java/JSF as easy to use as that. It would be good to > see a head to head comparison (same apps) to see which one is easier to read, > quicker to build etc. > > Also, caching is a nightmare with JSF. You can cache in application scope, > but then you have to provide a refresh button. JSF needs a way to provide > caching so that the application programmers don't need or care to know how > many times the getters are called. A correct caching scheme will avoid > referencing the database too many times. I realize we should use JPA instead > of JDBC. There needs to be a refresh button (or flush cache) with JPA, and > the application and session scope caches (they should work in concert with > the refresh button on the browser). Can one tell if the refresh button has > been pressed by looking at HTTP? I don't know. Maybe we need an extension > to HTTP, so we don't get those stupid popups anymore (do you want to resend?) > There's a requirement to both fetch new data, and a requirement to cache data > for speed. A good application framework would support both w/o the > application developer having to build their own cache and refresh technology. > There's a requirement to cache across multiple users, and many "experiments" > or main objects of concern selected from a list (although the most recent is > the highest priority). > > The amount of overhead and memory required to run JSF is a concern. It > seems like Oracle just wants to sell servers instead of making a good > technology. > > John > >
