 |
Pre-JCP-filed draft for JavaServer Faces 2.0 JSR
Posted by edburns on March 30, 2007 at 08:27 AM | Comments (53)
It's about time we get moving on JSF 2.0, so Sun's JSF team decided
to go public with a pre-JCP-filing of the JSR for JavaServer Faces 2.0.
The draft of the document at <https://javaserverfaces-spec-public.dev.java.net/proposals/JSF-2_0-draft.html>
has been through several rounds of Sun internal review and also was
reviewed by the JSF 1.2 Expert Group. Please review the draft and post
comments here on this blog.
If you want to go even deeper into shaping JSF 2.0 and the JSR
submission, you can view and edit the wiki for a JSF
2.0 Requirements Scratchpad document. When the JSR gets rolling,
the requirements in that document will be turned into issues in the JavaServer
Faces Specification Issue Tracker.
Finally, I'd like to take this opportunity to extend an invitation to
several individuals outside of the JSF community to join us in
developing the next version of the Java standard web application
framework. Specifically, I call upon Howard Lewis-Ship, Geert Bevin,
Eelco Hillenius, and Tim Fennell to consider Joining the
JCP so they can join the Expert Group when it forms. Of course,
there are many other folks whose expertise would be appreciated on the
Expert Group, but Howard, Geert, Eelco and Tim come to mind because each
of them has their own web framework outside of JSF.
Please let us know what you think about starting JSF 2.0!
Bookmark blog post:  del.icio.us  Digg  DZone  Furl  Reddit
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
-
Very glad to see this.
One thing seemed strange about the JSR proposal though. As I read the list of new features, all but two of them were things Seam either has or, in the case of REST, will have shortly. But I didn't even see Seam on the list of relevant projects. Is this intentional or an oversight?
Posted by: trauts2 on March 30, 2007 at 10:28 AM
-
Very glad to see this.
One thing seemed strange about the JSR proposal though. As I read the list of new features, all but two of them were things Seam either has or, in the case of REST, will have shortly. But I didn't even see Seam on the list of relevant projects. Is this intentional or an oversight?
Posted by: trauts2 on March 30, 2007 at 11:02 AM
-
Very glad to see this.
One thing seemed strange about the JSR proposal though. As I read the list of new features, all but two of them were things Seam either has or, in the case of REST, will have shortly. But I didn't even see Seam on the list of relevant projects. Is this intentional or an oversight?
Posted by: trauts2 on March 30, 2007 at 11:05 AM
-
trauts2, there's a separate JSR 299 that is currently running which is based on JBoss Seam with suggestions from Google's Guice and others. This JSR will consume much of the managed bean facility on a more general level for the JEE stack which at that point, JSF 2.0 will attempt to simply delegate those facets to the products of JSR 299.
Posted by: jhook on March 30, 2007 at 11:05 AM
-
Wow, so sorry about multiple posts! I'm having network issues here and didn't realize any packets left the building...
Thx for the response. That makes sense.
Posted by: trauts2 on March 30, 2007 at 11:06 AM
-
Eelco does a huge amount of work on Wicket (as do several other people on our dev team of more than a dozen developers) and he is a thoughtful and vocal public figure, however Eelco would be the first to say (and actually did on our IRC channel) that Wicket was actually created and architected by me.
I find it sort of ironically amusing to be passed over for this (not that I could actually find the time for it anyway...) because (a) I used to be a Sun employee and (b) I hated JSP and JSF 10 years ago when I proposed that Sun do something like Wicket. I was ignored just as I was ignored when I said Sun should do something like SWT. In fact, I tried to start a skunkworks project to solve some of the problems in AWT by creating a better model for UI devices and it was actively killed once discovered.
I find it really sad that Sun is such a great company in many respects but is really actively reluctant to take real risks in software at the same time. I was commenting to someone on IRC this morning that the very culture that makes Sun so strong at hardware (wild risk taking with a manufacturing run would be idiotic) makes it weak at creating monetizable software. The brightest thing that ever happened to Sun was shut down and never repeated: the JavaSoft operating company. That was a culture of vibrant risk-taking creativity that never in a million years should have been folded back into Sun. That experiment was working. In fact, do it again and it will work again.
Posted by: jonathanlocke on March 30, 2007 at 04:39 PM
-
The suggested EG members have previously expressed some interest in JSF/standardization or contributing to JSF and fixing the problems the original spec posed. Additionally, these folks are fairly vocal and have contributed as a representative of the associated frameworks-- so please don't fault Ed on this.
Posted by: jhook on March 30, 2007 at 05:06 PM
-
Just few ideas from top of my head. I hope that will be better than start any politically charged discussions there. Some of that staff is already in proposal, I appreciate that fact.
Validator contract may include portion that belong to Client using appropriate language (Java Script?).
Component contract may include standard Client-side API (Java Script?). Example – any Input may have 'validate' call that will perform Client or Ajax-style validation. Same for 'update' function that will perform validation and update Model on Server using Ajax call.
Validation Messages must have Client-side API to allow seamless Client and Ajax style validations.
Navigation API may support more complex cases, like partial updates. That way you may have Ajax action performed on server and signal to framework what to do: update that portion of View, full View or redirect to some other View.
JSF internals must become less visible to developers. For example Restore View phase shouldn't be visible in a form of getters called to “restore” model state. Fix dataTable!
Stateless Faces.
More specific Component API, standard Resources Framework, Scripting API – all this making less possible to produce incompatible components. In addition to this special TCK to validate/certificate Component Libraries for compatibility.
Client-side events. In general we need standard Client-side API and I don't care about client with disabled Java Script.
Skinability Framework, that includes Skin parameters API, dynamically generated CSS and Images using Skin parameters (related to Resource Framework), easy use of Skin parameters from pages and Components.
Posted by: ishabalov on March 30, 2007 at 05:40 PM
-
From what I can see after reading all presented materials I like approach taken by Ed and his team. Good start, Ed!
Posted by: ishabalov on March 30, 2007 at 05:43 PM
-
as a side note, and not many people know this, but i wrote the lego company when i was 9, suggesting that they come out with dinosaur legos (apologies, I no longer have the original schematics available). But what irks me is that I didn't get any recognition when legos came out with this.
Posted by: jhook on March 30, 2007 at 05:55 PM
-
Here is my wish list:
1. Integrate something like facelets into spec
2. Cover client side validation
3. Allow better interoperability with Seam eg scoping
4. Cover generation of XML/PDF/Excel/Emails/SVG
5. More support for Ajax
6. Better performance
7. Allow easier development of custom components (This one I think is very important). Allow developing of custom components with little or no Java coding. ZK on sorceforge has some interesting ideas.
8.Allow storing result of rendering into a file (might be with something
like enhanced t:buffer tag from Tomahawk) Ex: for sending an email or generating report for subsequent download
9. Simplify configuration
10. Enhance EL functions library
Thanks
Posted by: mgrouch on March 30, 2007 at 06:27 PM
-
I'm glad that ideas enhancing the validation are finally exposed. I'd really like to see a built-in client side validation, partial validation, validation groups and etc. In myfaces we've implemented client validation by making the standart converters/validators implement ClientValidator/ClientConverter and provide the script. (http://example.irian.at/example-sandbox-20070331/clientValidationWithStandardForm.jsf) Another important thing I'd like to see is improving the IOC container, I think adding construction injection() and adding some AOP features will make JSF IOC what people expect from an IOC container.
Posted by: cagatay_civici on March 31, 2007 at 02:36 AM
-
Looking good - I blogged about my thoughts on the new spec.
Posted by: pmuir on March 31, 2007 at 03:31 AM
-
As an ex ASP.NET user one thing that JSF would benefit is adding an attribute like "causesValidation" to UICommand components to skip validation. Also conversion/validation happens in processValidations phase which I think should be seperated to processConversions and processValidations. By this way skipping validation will be much easier for users than using hacs like "immediate" attribute(which is hard to understand for starters).
Posted by: cagatay_civici on March 31, 2007 at 08:37 AM
-
Hi Ed,
It's great that you invite members of competing frameworks to take part in the JSR. Would this have been a couple of years ago, I would gladly have joined. Now I'm very much in doubt (inclined towards not joining tbh) as I would be afraid to only contribute to a design by comittee process. I have some strong ideas about what a web framework should look like, and due to my involvement in Wicket - and sharing ideas with Jonathan, Igor, Matej and the others - they only got stronger. Some of those, like a rigid separation of presentation and logic and providing an unmanaged (simply Java) programming model are incompatible with the history and most likely the future of JSF, so I'd either be compromising my own convictions or be a pita for the rest of the EG.
What I would love is to have an honest, non-public brainstorm session with some of the people of the competing frameworks and discuss the things we like and don't like about the various frameworks. I'd be available for something like that at all times.
Posted by: eelco12 on March 31, 2007 at 10:16 PM
-
Hi Ed,
it's very encouraging that you're seeking input from members of other frameworks. However, I join the feelings that Eelco has. RIFE is fundamentally different from any of the other frameworks out there, and JSF is a whole different beast. I can't see how I could be of any significant influence in the midst of a large group of other spec members that have essentially different goals and ideals. I would be spending a lot of time on this, with little gain to either projects, and like for anyone here, time is what I'm lacking the most ;-)
Again, as Eelco says, I think that everyone would benefit though from a collaborative discussion about what's useful, unique and cool in the frameworks we love. I think it's best to focus on the good sides and the strengths here, and maybe create a wiki that can eventually evolve into a feature matrix with use-cases for the individual features. I'm sure we'll all learn a lot about what else is out there, since it's virtually impossible to correctly try out other frameworks while one's working on his own. This would then also help Java developers to make an educated choice about the frameworks that they want to adopt for their projects.
Posted by: gbevin on April 01, 2007 at 01:02 AM
-
will a simple h:inputFile be ignored again? No, no ajax hacks, if i want ajax i'd like to do it myself. I mean input type="file" and faces that doesn't think that all multipart requests are postbacks (and hence never get passed RESTORE_VIEW phase).
I know that handling multipart requests presents problems, but its part of http and html. If this existed it would provide a solid base for any html based applications. The problem is clearly in the problem domain of jsf, so will 2.0 ignore it, like 1.2 and 1.1?
Posted by: melowe on April 01, 2007 at 01:11 AM
-
Hi Ed,
This looks really good. FWIW I've posted some of my ideas for JSF 2.0 to my blog at http://www.ninthavenue.com.au/blog/jsf_2.0_ideas. It looks like most of them are already covered in the draft though.
Jacob, I was really touched by your story about the Lego dinosaurs. I too, have been victim to this sort of terrible injustice, never having received credit for the whole tabbed browsing phenomon. (sigh) ;)
Posted by: rogerkeays on April 01, 2007 at 03:24 AM
-
Starting JSF 2.0 is a great thing to do - and I have a long wish list.
Let me post this wish list for JSF 2.0 - not ranked by priority:
1) a way to visit the full tree of JSF components and do whatever you want on them (that's currently not possible, with invokeOnComponent it's possible for one component - I want the same possibility for all the components)
2) rewrite all phase processing logic to use suggestion 1 - with hooks for individual components to take part in the processing if necessary - this would make the JSF components a lot better structured and a lot leaner
so out of:
processDecodes(), processUpdates(); ...
we make one invokeOn() - and the lifecycle-implementation does the rest. The component can intervene with filters then, to make sure it can specifically decide about inclusion/exclusion of children in the phase processing.
3) solving the problem with AJAX-integration once and for all - jsf-extensions has some great ideas, but there are still some workarounds in there that need to be taken into consideration
4) solving the form - link - button issues - once and for all. Find a way to do a form-submission client-side independent of the concrete implementation.
5) providing at least some bookmarking support out of the box - not saving the full state, but at least part of it
6) think about performance more - doing something like trinidad does with delta-state saving
7) integrating some ideas of facelets in the spec - I believe most of the components facelets has can be backported to JSP as well and can now get to be standard components compatible to both JSP and facelets!
more to come when we discuss later on!
regards,
Martin
Posted by: mmarinschek on April 01, 2007 at 08:04 AM
-
I've tried editing the wiki for the JSF 2.0 Requirements Scratchpad document, but the Edit link took me into an endless loop of redirects. I wanted to add a of couple points:
1) Regarding HTTP GET support, external systems should be able to do an HTTP GET request to a JSF form that executes the action. For example, an external system wanting to pass in data for two fields of a search form and execute the search action.
2) Make sure that developers targeting mobile devices aren't forced into downloading tons of JavaScript and CSS for every page the way Visual Web Pack theme files do. Mobile web apps need very small HTML output, and there is very limited CSS and JavaScript support.
3) Examine Oracle JDeveloper's JSF support for mobile devices. It appears that for each page being developed you can create a view for desktop computers and a view for mobile devices. They might even provide browser detection for displaying the correct view. Building this into JSF 2.0 would be great for mobile web developers.
Posted by: rdelaplante on April 01, 2007 at 08:45 AM
-
In terms of looking at JSP alternative templating solutions, we should think in terms of an API and not just focus on a single XML solution (facelets). I believe the better way to consider building alternatives is to think of templates as metadata use to build the component tree versus focusing on a markup syntax. This metadata provides a layer of indirection that the component tree is built from. Within this layer we can add reuse and other true OO principles not possible or overlooked in a simple templating approach. In terms of reuse, I'm talking about inheritance in addition to composition. By focusing on an API, it could allow for template metatdata to be stored in a variety of forms, XML, HTML, Java Annotations, JCR (aka Jackrabbit) or RDBMS. This approach could also benefit JSP built view besides other types of page entry points.
Posted by: gvanmatre on April 01, 2007 at 08:51 AM
-
Note: I posted earlier saying that I could not edit the wiki for the JSF 2.0 Requirements Scratchpad document. It works now and I was able to add my comments.
Posted by: rdelaplante on April 01, 2007 at 09:19 AM
-
some folks complain that the servlet spec isn't providing enough of a foundation for proper application development-- hence zero re-use/compatability between the various MVC stacks (Action vs. Component, GET vs. POST, Stateful vs. Stateless-- no one best fit). JSR 299 (WebBeans) is hopefully able to maintain that state/injection piece for application Models. What I'd like to see JSF do better at handling the 'stateless' usecase to provide a better separation between the Controller and View such that you aren't locked into a single mode of handling the presentation and hopefully filling in a better platform on top of the servlet spec. that's always been the goal, but the current solution is not ideal for everyone.
Posted by: jhook on April 01, 2007 at 01:34 PM
-
Hi Ed,
I remember that I ever read your post on ICEfaces home page, on which you said you would consider ICEfaces in JSF2.0, but you did not mention ICEfaces in the draft JSF 2.0 JSR.
Posted by: gus315 on April 03, 2007 at 03:01 PM
-
Here's what I think to get rid of immediate: http://people.apache.org/~cagatay/lifecycle2_proposal.jpg
Posted by: cagatay_civici on April 06, 2007 at 02:50 PM
-
BTW, even though I've been grumbling about Sun software for a while, I didn't want to give anyone the impression that I dislike Sun or something. It's one of the best companies in the world and Sun's hardware REALLY seems to be back in style. We investigated all the competitors here for web node hardware and Sun came out on top big time in terms of price and features.
Posted by: jonathanlocke on April 06, 2007 at 04:17 PM
-
* Force implementations to make ALL attributes of the html elements stuff is rendered to accessible!
E.g. the size attribute of selectManyMenu (who the f*** thought it would be good to render a menu supposed for selecting more than 1 entry at time with a fixed size of 1 ???) .
* Make the html output xhtml 1.1 strict compatible - currently there are problems with the ids & client side state saving.
* Don't use javascript if it isn't absolute necessary (e.g. for posting forms)!
Posted by: vajav on April 08, 2007 at 07:47 AM
-
JL> Eelco does a huge amount of work on Wicket (as do several other
JL> people on our dev team of more than a dozen developers) and he is
JL> a thoughtful and vocal public figure, however Eelco would be the
JL> first to say (and actually did on our IRC channel) that Wicket
JL> was actually created and architected by me. I find it sort of
JL> ironically amusing to be passed over for this (not that I could
JL> actually find the time for it anyway...) because (a) I used to be
JL> a Sun employee and (b) I hated JSP and JSF 10 years ago when I
JL> proposed that Sun do something like Wicket. I was ignored just as
JL> I was ignored when I said Sun should do something like SWT. In
Hi Jonathan, I meant no slight. It's just that I met and worked with
Eelco when doing the Web Framework Smackdown at JavaOne a few years ago.
I liked him and thought his agreeable character would work well in the
community of experts.
JL> fact, I tried to start a skunkworks project to solve some of the
JL> problems in AWT by creating a better model for UI devices and it
JL> was actively killed once discovered. I find it really sad that
JL> Sun is such a great company in many respects but is really
JL> actively reluctant to take real risks in software at the same
JL> time. I was commenting to someone on IRC this morning that the
JL> very culture that makes Sun so strong at hardware (wild risk
JL> taking with a manufacturing run would be idiotic) makes it weak
JL> at creating monetizable software. The brightest thing that ever
JL> happened to Sun was shut down and never repeated: the JavaSoft
JL> operating company. That was a culture of vibrant risk-taking
JL> creativity that never in a million years should have been folded
JL> back into Sun. That experiment was working. In fact, do it again
JL> and it will work again.
As someone who came into Sun via Lighthouse
Design, I know all about JavaSoft. Personally, I think you're
seeing JavaSoft through rose colored glasses.
mgrouch> 1. Integrate something like facelets into spec
mgrouch> 2. Cover client side validation
mgrouch> 3. Allow better interoperability with Seam eg scoping
In there already.
mgrouch> 4. Cover generation of XML/PDF/Excel/Emails/SVG
Are you talking about different device types? I'm not sure this can be
covered in the Spec in any more detail than we already do. I'd like to
see more implementation on this though.
mgrouch> 5. More support for Ajax
mgrouch> 6. Better performance
In there already
mgrouch> 7. Allow easier development of custom components (This one I
mgrouch> think is very important). Allow developing of custom
mgrouch> components with little or no Java coding. ZK on sorceforge
mgrouch> has some interesting ideas.
Added to JSR.
mgrouch> 8.Allow storing result of rendering into a file (might be
mgrouch> with something like enhanced t:buffer tag from Tomahawk) Ex:
mgrouch> for sending an email or generating report for subsequent
mgrouch> download
Added to Wiki.
mgrouch> 9. Simplify configuration
In there already.
mgrouch> 10. Enhance EL functions library
In wiki already
civici> I'm glad that ideas enhancing the validation are finally
civici> exposed. I'd really like to see a built-in client side
civici> validation, partial validation, validation groups and etc. In
civici> myfaces we've implemented client validation by making the
civici> standart converters/validators implement
civici> ClientValidator/ClientConverter and provide the
civici> script. (http://example.irian.at/example-sandbox-20070331/clientValidationWithStandardForm.jsf)
Already in the JSR. Since we'll have a myfaces rep on the EG, most
likely Martin, I'm hoping he can bring that in.
civici> Another important thing I'd like to see is improving the IOC
civici> container, I think adding construction injection() and adding
civici> some AOP features will make JSF IOC what people expect from
civici> an IOC container.
This is a good one. Added to the Wiki. We need to be careful here
because these features might be core Java EE 6 features. We can move
things around.
PeteMuir> The ball has started rolling for JSF 2.0 - and it looks
PeteMuir> like there are going to be some big changes!
Well, as I said in the JSR:
Not all of these ideas will be in the final
specification. Some of these requirements may be met in
the Servlet specification (or other Java EE specification) but
they are stated here because they are critical to the success of
JavaServer Faces.
Posted by: edburns on April 10, 2007 at 01:17 PM
-
More comments on comments.
PeteMuir> One of the big issues currently is that it needs soooo much
PeteMuir> wiring - to write a tag you write the component class, add
PeteMuir> it to faces-config.xml (with all its properties), add it to
PeteMuir> your.taglib.xml, write a Tag class (with all it's
PeteMuir> properties) and add it to your tld (with all its
PeteMuir> properties),. You then have to write your state saving
PeteMuir> manually, and make each property read both a static and EL
PeteMuir> resolvable variable. Tools like Ajax4jsf's CDK take some of
PeteMuir> the pain out of this, but annotations would be much neater
PeteMuir> :)
This is a very good characterization of the pain. I've added it straight to the scratchpad wiki.
PeteMuir> JSF is currently missing navigation controls - you want to
PeteMuir> call an action or navigate to an outcome BUT you don't need
PeteMuir> to submit a form, and should be restful! Lots of toolkits
PeteMuir> have implemented these (e.g. Trinidad, Seam UI)
Added to Wiki.
PeteMuir> JSF should look at providing restful access to dynamic
PeteMuir> resources (e.g. images stored in databases) -
Already in the JSR.
PeteMuir> strong support for annotations for defining a component and
PeteMuir> building the necessary wiring e.g. so you can just do
PeteMuir> @Property(el=true, saveState=true), or @Validator...
Added to Wiki.
PeteMuir> Use generics in validators and converters - very minor, but
PeteMuir> would save a few casts!
Added to Wiki.
PeteMuir> CRUD - Field decoration, validation and conversion - easy
PeteMuir> CRUD is certainly good, field decoration - like Trinidad's
PeteMuir> label, help and message placement BUT it should templatable
PeteMuir> (for example, Facelets ui:decorate) so that you can easily
PeteMuir> change the layout of the decoration.
Added to Wiki.
PeteMuir> Ajax validation
Already suggested and added.
PeteMuir> Exception handling
Added to Wiki.
PeteMuir> JAR Layout - the idea of a location convention (i.e. all
PeteMuir> converters in in war/converters/seam-converters.jar) is
PeteMuir> interesting - but surely if all you need to do to make a
PeteMuir> class a converter is do @Converter, @ConvertToString,
PeteMuir> @ConvertToObject (or something)... or have I missed a point
PeteMuir> here?
Added to Wiki. Yes, but having these things implementable in script
requires a directory based approach.
PeteMuir> concurrent/lost submit problem - any solution MUST be
PeteMuir> pluggable.
Added to JSR.
Eelco> What I would love is to have an honest, non-public brainstorm
Eelco> session with some of the people of the competing frameworks
Eelco> and discuss the things we like and don't like about the
Eelco> various frameworks. I'd be available for something like that
Eelco> at all times.
Geert> Again, as Eelco says, I think that everyone would benefit
Geert> though from a collaborative discussion about what's useful,
Geert> unique and cool in the frameworks we love.
Ok. I think the best we can hope for then is continued good faith
between you two and me personally. I'll try to seek your input as
leaders of your respective communities in the form of one-on-one
conversations at various conferences we inevitably (and fortunately) all
attend. See you at JavaOne!
melowe> Will a simple h:inputFile be ignored again?
No, it will not. It's already in the JSR.
rogerkeays> Jacob, I was really touched by your story about the Lego
rogerkeays> dinosaurs. I too, have been victim to this sort of
rogerkeays> terrible injustice, never having received credit for the
rogerkeays> whole tabbed browsing phenomon. (sigh) ;)
Hey, I coined the term "webcast" in 1995, but did I get credit? Nooooo.
rogerkeays> Templating
Already in JSR.
rogerkeays> JSF First class JSP
Already in JSR.
rogerkeays> Separate build and render phases
It's interesting you say that. We spent a lot of time in JSF 1.2 on
this, but as you point out, the two are still in the same phase. Why
not add another phase? Good idea. I've added it to the JSR.
rogerkeays> Invoke lifecycle on first request
I've added it to the wiki.
rogerkeays> Page lifecycle
Already on the Wiki.
rogerkeays> Deferred ValueChangeListeners
This seems like solving a symptom, not the cause. You want to be able
to add listeners for various kinds of lifecycle application events.
Maybe, "call this each time something validates," or "call this after
everything successfully validates. Sounds a bit like AOP. I've added
it to the Wiki.
rogerkeays> FacesContext available to filters and other servlets
Added to Wiki as Servlet requirement.
rogerkeays> ${bean} as an lvalue
I'm just gonna flat out say no on this one.
rogerkeays> Reuse component state available from templates
Added to Wiki.
rogerkeays> Standard way of packaging, resolving and serving static
rogerkeays> resources
Already in JSR.
rogerkeays> Miscellaneous component improvements
Added to Wiki.
Posted by: edburns on April 10, 2007 at 07:00 PM
-
I would like to see a FacesEvent.get/setParent() that must be used when wrapping an event, usually in queueEvent(). For example UIData in the RI wraps up events from children in it's own event class so it can set it's own index when the event gets broadcast. Ancestors of the UIData cannot then "see" the original event.
Implementation would just add a getParent() to FacesEvent and then setting either with a setter or a constructor overload. Components can then walk the entire event stack to look for the real event of interest.
Posted by: quilleashm on April 11, 2007 at 05:55 AM
-
Martin> Starting JSF 2.0 is a great thing to do - and I have a long
Martin> wish list. Let me post this wish list for JSF 2.0 - not
Martin> ranked by priority:
Martin> 1) a way to visit the full tree of JSF components and do
Martin> whatever you want on them (that's currently not possible,
Martin> with invokeOnComponent it's possible for one component - I
Martin> want the same possibility for all the components)
Already in the Wiki. I remember Munich!.
Martin> 2) rewrite all phase processing logic to use suggestion 1 -
Martin> with hooks for individual components to take part in the
Martin> processing if necessary - this would make the JSF components
Martin> a lot better structured and a lot leaner so out of:
Martin> processDecodes(), processUpdates(); ... we make one
Martin> invokeOn() - and the lifecycle-implementation does the
Martin> rest. The component can intervene with filters then, to make
Martin> sure it can specifically decide about inclusion/exclusion of
Martin> children in the phase processing.
Already in the Wiki, but I've added your above content because it is
Martin> more specific than what I had before.
Martin> 3) solving the problem with AJAX-integration once and for all
Martin> - jsf-extensions has some great ideas, but there are still
Martin> some workarounds in there that need to be taken into
Martin> consideration
Already in the JSR.
Martin> 4) solving the form - link - button issues - once and for
Martin> all. Find a way to do a form-submission client-side
Martin> independent of the concrete implementation.
Added to Wiki.
Martin> 5) providing at least some bookmarking support out of the box
Martin> - not saving the full state, but at least part of it
Already in the JSR.
Martin> 6) think about performance more - doing something like
Martin> trinidad does with delta-state saving
Already in the JSR.
Martin> 7) integrating some ideas of facelets in the spec - I believe
Martin> most of the components facelets has can be backported to JSP
Martin> as well and can now get to be standard components compatible
Martin> to both JSP and facelets! more to come when we discuss later
Martin> on! regards, Martin
Already in the JSR.
rdelaplante> 1) Regarding HTTP GET support, external systems should
rdelaplante> be able to do an HTTP GET request to a JSF form that
rdelaplante> executes the action. For example, an external system
rdelaplante> wanting to pass in data for two fields of a search form
rdelaplante> and execute the search action.
Already in the JSR and I see you succeeded in adding it to the Wiki.
Thanks!
rdelaplante> 2) Make sure that developers targeting mobile devices
rdelaplante> aren't forced into downloading tons of JavaScript and
rdelaplante> CSS for every page the way Visual Web Pack theme files
rdelaplante> do. Mobile web apps need very small HTML output, and
rdelaplante> there is very limited CSS and JavaScript support.
Thanks for adding this to the wiki.
rdelaplante> 3) Examine Oracle JDeveloper's JSF support for mobile
rdelaplante> devices. It appears that for each page being developed
rdelaplante> you can create a view for desktop computers and a view
rdelaplante> for mobile devices. They might even provide browser
rdelaplante> detection for displaying the correct view. Building this
rdelaplante> into JSF 2.0 would be great for mobile web developers.
Thanks for adding this too!
gvanmatre> In terms of looking at JSP alternative templating
gvanmatre> solutions, we should think in terms of an API and not just
gvanmatre> focus on a single XML solution (facelets). I believe the
gvanmatre> better way to consider building alternatives is to think
gvanmatre> of templates as metadata use to build the component tree
gvanmatre> versus focusing on a markup syntax.
I agree. That's why I call the JSF role filled by facelets or JSP (or
XUL, whatever) is the View Description Language. That's how I think
about it. That's what it is.
gvanmatre> This metadata provides a layer of indirection that the
gvanmatre> component tree is built from. Within this layer we can add
gvanmatre> reuse and other true OO principles not possible or
gvanmatre> overlooked in a simple templating approach. In terms of
gvanmatre> reuse, I'm talking about inheritance in addition to
gvanmatre> composition. By focusing on an API, it could allow for
gvanmatre> template metatdata to be stored in a variety of forms,
gvanmatre> XML, HTML, Java Annotations, JCR (aka Jackrabbit) or
gvanmatre> RDBMS. This approach could also benefit JSP built view
gvanmatre> besides other types of page entry points.
Yes, I like this idea and have added it to the Wiki.
gus315> Hi Ed, I remember that I ever read your post on ICEfaces home
gus315> page, on which you said you would consider ICEfaces in
gus315> JSF2.0, but you did not mention ICEfaces in the draft JSF 2.0
gus315> JSR.
I've added it to Section 3. Thanks.
civici> Here's what I think to get rid of immediate:
civici> http://people.apache.org/~cagatay/lifecycle2_proposal.jpg
Thanks for the additional diagram. As I stated above, I've added it to
the Wiki.
vajav> * Force implementations to make ALL attributes of the html
vajav> elements stuff is rendered to accessible! E.g. the size
vajav> attribute of selectManyMenu (who the f*** thought it would be
vajav> good to render a menu supposed for selecting more than 1 entry
vajav> at time with a fixed size of 1 ???) .
Good catch. Added to Wiki.
vajav> * Make the html output xhtml 1.1 strict compatible - currently
vajav> there are problems with the ids & client side state saving.
vajav>* Don't use javascript if it isn't absolute necessary (e.g. for
vajav> posting forms)!
Added to wiki.
quilleashm> I would like to see a FacesEvent.get/setParent() that
quilleashm> must be used when wrapping an event, usually in
quilleashm> queueEvent(). For example UIData in the RI wraps up
quilleashm> events from children in it's own event class so it can
quilleashm> set it's own index when the event gets
quilleashm> broadcast. Ancestors of the UIData cannot then "see" the
quilleashm> original event. Implementation would just add a
quilleashm> getParent() to FacesEvent and then setting either with a
quilleashm> setter or a constructor overload. Components can then
quilleashm> walk the entire event stack to look for the real event of
quilleashm> interest.
Nice idea. Added to Wiki.
Posted by: edburns on April 13, 2007 at 07:23 AM
-
Currently there is no easy place to put generic JSF exception handling. A Filter is too high as by that point the FacesContext has been destroyed and with it JSF specific information.
Add an exception handler hook somewhere in the JSF lifecycle. My best guess is probably in the FacesServlet. Any exception that falls out of the JSF lifecycle would be passed to the Exception handlers which could choose to handle them or not.
Would probably need to be flexible enough to allow multiple exception handlers to be used in order and each one decide whether the exception should now be swallowed or propogated to the next handler. Perhaps similar to how the Servlet Filter works with a FilterChain.
Posted by: quilleashm on April 17, 2007 at 07:31 AM
-
Already added to scratchpad but as you're screening these comments...
Add getPhaseId() to FacesContext for accessing the current JSF lifecycle phase of the current request.
Posted by: quilleashm on April 17, 2007 at 08:06 AM
-
I'd like to see improvements to UIComponent.findComponent. I had made a request that involves this with A4J:
http://jira.jboss.com/jira/browse/AJSF-46
The gist of it being that a developer has no way to find a component, using "UIComponent.findComponent", above its current naming container with a relative component ID/path. It would be great to have a parent syntax. For example:
..:componentId
The ".." would tell findComponent that it should find the naming container of the current component and go up one naming container above that. So a client ID of "A:B:C:D" the component could find "B" by using "..:.." instead of having to give a full path of ":A:B".
Posted by: arobinson74 on April 20, 2007 at 06:06 PM
-
Don Brown has some nice comments:
http://jroller.com/page/mrdon?entry=jsf_rough_spots
And I hope that your Ajax-Support aligns with Ajax-Support in the Portlet 2.0-Specification..
Posted by: affenschlaffe on April 21, 2007 at 12:13 PM
-
1. Allow specify scope of managed-bean to portlet-scope session or application-scope session in portlet environment.
2. Support portlet IPC.
Posted by: leewas on April 23, 2007 at 01:15 AM
-
Hi Ed,
I would appreciate some of the shale logic (view-controller and dialog/context concepts) the testing is done nicely in shale as well.
The one thing I'm missing is security in JSF. Myfaces addressed this in their components. I find the jsf-security way (http://jsf-security.sourceforge.net/) a good start, providing a securityScope an EL expressions like userInRole ...etc.
And of course facelets rule for bringing the DRY principle to JSF-pages.
Thx,
Mike
Posted by: suckerd on April 25, 2007 at 02:04 AM
-
quilleashm> Currently there is no easy place to put generic JSF
quilleashm> exception handling. A Filter is too high as by that point
quilleashm> the FacesContext has been destroyed and with it JSF
quilleashm> specific information. Add an exception handler hook
quilleashm> somewhere in the JSF lifecycle. My best guess is probably
quilleashm> in the FacesServlet. Any exception that falls out of the
quilleashm> JSF lifecycle would be passed to the Exception handlers
quilleashm> which could choose to handle them or not. Would probably
quilleashm> need to be flexible enough to allow multiple exception
quilleashm> handlers to be used in order and each one decide whether
quilleashm> the exception should now be swallowed or propogated to
quilleashm> the next handler. Perhaps similar to how the Servlet
quilleashm> Filter works with a FilterChain.
Already in the JSR.
quilleashm> Already added to scratchpad but as you're screening these
quilleashm> comments... Add getPhaseId() to FacesContext for
quilleashm> accessing the current JSF lifecycle phase of the current
quilleashm> request.
Good idea. I've wanted this myself.
arobinson74> I'd like to see improvements to
arobinson74> UIComponent.findComponent. I had made a request that
arobinson74> involves this with A4J:
arobinson74> http://jira.jboss.com/jira/browse/AJSF-46 The gist of it
arobinson74> being that a developer has no way to find a component,
arobinson74> using "UIComponent.findComponent", above its current
arobinson74> naming container with a relative component ID/path. It
arobinson74> would be great to have a parent syntax. For example:
arobinson74> ..:componentId
arobinson74> The ".." would tell findComponent that it should find
arobinson74> the naming container of the current component and go up
arobinson74> one naming container above that. So a client ID of
arobinson74> "A:B:C:D" the component could find "B" by using "..:.."
arobinson74> instead of having to give a full path of ":A:B".
Added to wiki.
affenschlaffe> Don Brown has some nice comments:
affenschlaffe> http://jroller.com/page/mrdon?entry=jsf_rough_spots
affenschlaffe> And I hope that your Ajax-Support aligns with
affenschlaffe> Ajax-Support in the Portlet 2.0-Specification..
Yes, we will. And as for Mr. Brown:
DonBrown> The dataGrid tag can't take a Collection as its model, but
DonBrown> instead requires a List. This I don't understand because a
DonBrown> Collection can just as easily be iterated over. Many times,
DonBrown> your DAO's return a Collection, which may just be the
DonBrown> result of Map.values(), a Set.
Added to Wiki.
DonBrown> selectItems tag is way too unflexible - it only takes a
DonBrown> Map. You'd think you should be able to show a simple String
DonBrown> array or a List of Strings, but no.
It's not true that it only takes a map.
Look at the
tlddoc for the "value" attribute. "Value binding expression
pointing at a List or array of SelectItem instances containing the
information for these options."
DonBrown> On the applyRequestValues phase, the EL should support lazy
DonBrown> object creation. In order to set nested properties, I had
DonBrown> to create empty objects in my constructor. The EL should be
DonBrown> able to, as in OGNL, create objects has it comes across the
DonBrown> need to.
The EL does support lazy object creation. That's how managed beans
work. For example, if I have a request scoped managed bean named
"bean", an instance of this bean will be created the first time an el
expression starting with "#{bean" is evaluated.
DonBrown> The tags needed for a form are verbose, especially compared
DonBrown> to SAF2 tags. Here is the form using JSF tags:
Not much we can do there, it's in the spec, we can't change something so
fundamental. Note that you can easily work around this using facelets.
Sure, you have a "textfield" tag, which is a composition of a label and
an input field. In JSF 2.0, with component aggregation, you could
create such a component. Perhaps we can define a standard set of
aggregations? I've added it to the JSR.
DonBrown> Every JSF page must define and load its resource
DonBrown> bundle. I'm probably getting this wrong, but AFAICT, this
DonBrown> is required. If true, this seems redundant and inefficient.
This was fixed in JSF 1.2.
DonBrown> JSF exception messages weren't very helpful. The messages
DonBrown> generally through out some field names with little verbiage
DonBrown> to explain what really went wrong. Furthermore, they rarely
DonBrown> had line numbers, which is a big no-no in my book and
DonBrown> something SAF2 is working hard on.
Already covered in the JSR.
leewas> 1. Allow specify scope of managed-bean to portlet-scope
leewas> session or application-scope session in portlet environment.
leewas> 2. Support portlet IPC.
Good ideas. Added to wiki. Also, Roger is on the JSF Portlet Bridge
JSR 301.
suckerd> Hi Ed, I would appreciate some of the shale logic
suckerd> (view-controller and dialog/context concepts) the testing is
suckerd> done nicely in shale as well.
ViewController and dialog are already in the wiki. As for testing, I'm
not sure what the spec impact should be there.
suckerd> The one thing I'm missing is
suckerd> security in JSF. Myfaces addressed this in their
suckerd> components. I find the jsf-security way
suckerd> (http://jsf-security.sourceforge.net/) a good start,
suckerd> providing a securityScope an EL expressions like userInRole
suckerd> ...etc. And of course facelets rule for bringing the DRY
suckerd> principle to JSF-pages. Thx, Mike
Added to wiki.
Posted by: edburns on April 26, 2007 at 01:41 PM
-
Hello, can anyone tell me how can I programm a javascript which will moderate my pictures randomly? My homepage is:E-Pedia
Posted by: angelas on June 26, 2007 at 08:06 AM
-
What I would like is to just program in Java like Swing or SWT but it would actually show up as a web page. Like if the browser were some kind of vitual machine. Why should I have to do anything with stuff like HTML and JavaScript. I don't have to write any byte code to use java. I progressed to the point of being somewhat an Object-Oriented Programmer and HTML and JavaScript seem to go way backwards from that. Is it just too hard to make something like I am talking about or maybe it already exists and I just don't know about it.
Posted by: mikeprice on July 05, 2007 at 10:54 AM
-
Have a hook (maybe annotation) on a UIComponent method to allow first-construction setup to be done. Currently if you place init logic in the constructor it gets called on the initial creation of the component AND when the component is restored.
My particular case is I have some components that add validators to themselves which I do in the constructor but after a few invalid form submits I have several copies of the validators.
Maybe something like:
// part of UIComponent, override as required
@Override
public void initialise()
{
...
}
OR
// new annotation, Seam-esque
@Create
public void initialise()
{
}
Posted by: quilleashm on July 10, 2007 at 03:40 AM
-
JSF jars depending to application not to container.
Running several application of differnt customers on the same ISP server, i had to update/test all at once to switch to a new JSF version.
Doublicate submitts by user should return the result of the first request, which could run successfull or into an error.
Only store compos/tree if its really necessary
Rendering data from model only for the initial request, on an postback this should be done from tree/compo.
I fetch objects only once from database for a page (never in postbacks).
But currently i have to put objects to session scope instead desired request scope, otherwise values of outputText are not displayed anymore, if an postback run into validation/conversion errors.
HtmlUtils should not write html entities only xml enities when encoding is UTF8
If i want to use validation/conversion/action in an AJAX postback i have to send all the inputs of the form back to the server. Should also work if i only send the AJAX depending inputs.
Posted by: hammoud on July 24, 2007 at 08:49 PM
-
Hello Hammoud, thanks for your feedback!
H> JSF jars depending to application not to container. Running several
H> application of differnt customers on the same ISP server, i had to
H> update/test all at once to switch to a new JSF version.
As you know, JSF is a core part of Java EE. Would you try doing the
same thing when upgrading the JSP version? That said, most app servers,
including Sun Java System Application Server, have container specific
ways to override the JSF impl provided. Therefore, I am not considering
this specific request for JSF 2.0.
H> Doublicate submitts by user should return the result of the first
H> request, which could run successfull or into an error.
Already on the list.
H> Only store compos/tree if its really necessary
Already on the list.
H> Rendering data from model only for the initial request, on an
H> postback this should be done from tree/compo. I fetch objects only
H> once from database for a page (never in postbacks). But currently i
H> have to put objects to session scope instead desired request scope,
H> otherwise values of outputText are not displayed anymore, if an
H> postback run into validation/conversion errors.
But how do you know when the data in the tree/compo is stale with
respect to the database? This seems like a persistence issue, have you
tried talking to the WebBeans JSR?
H> HtmlUtils should not write html entities only xml enities when
H> encoding is UTF8
This is an implementation specific issue. And, is it not possible that
anyone would want to write HTML using UTF8?
H> If i want to use validation/conversion/action in an AJAX postback i
H> have to send all the inputs of the form back to the server. Should
H> also work if i only send the AJAX depending inputs.
Sure, this is already in there.
Posted by: edburns on July 25, 2007 at 03:09 PM
-
> have container specific ways to override the JSF impl provided
I use SJSAS PE 9.0 - is it possible to do this different for every application?
Perhaps i should ask in GlassFish Forum
>> Doublicate submitts ...
> Already on the list
Yes i read this, but want to extend with "return result of the first submit".
Think otherwise some UUID-Session-Token solution will be build, which I already used an own one the last years and is not perfect
Would prefere an solution like this one from BasheerShaik we disussed here: JSF-Forum
> But how do you know when the data in the tree/compo is stale with respect to the database?
Does no matter if data in tree/compo or view-model is not synchron to database, just should be synchron to currently displayed data.
If an user opens an page, every data for this page should be loaded in one transactional snapshot (RepeatableRead).
If the model would synchronize on the postback, user suddenly gets displayed data from an different snapshot in output compos, when validation errors occur.
And what to do whith input values?
Which should be shown to user the new or the submitted value?
In my apps it runs like that:
1. User submits page
2. If Validation-Error return same page, show error message, submitted values and same data in output compos
3. Otherwise Read and Lock database row in action phase
4. Check hidden-concurrency-counter of page against database-concurrency-counter readed in 3
5. If different reeturn same page and data like in 2 and an message "object has been changed meanwhile by employee Mike at 07:00"
6. Otherwise change object in database and display result page
> This seems like a persistence issue, have you tried talking to the WebBeans JSR?
Sorry just a small programmer, dont no WebBeans
> This is an implementation specific issue.
Yes thats right, i should file implementation issue.
HTML-Entities just cause unnecessary traffic and erros in IE-AJAX-Response
> Sure, this is already in there.
Its some time ago, but if i have a form with several required inputs/selects and 2 command buttons.
First button is normal postback to save, second button hidden by CSS used for AJAX.
If i want to validation/convert and update only one input, for example on an JS-keydown event, it did not work because JSF missed other fields.
Posted by: hammoud on July 25, 2007 at 06:26 PM
-
Allow the NamingContainer.SEPARATOR_CHAR used in client ids to be set to something else. There are a fair few javascript libraries out there that don't support colon in HTML ids despite the HTML spec saying they are valid. You can manually override getClientId() for the troublesome components but then things like UIData with it's client id parsing stop working.
Posted by: quilleashm on July 27, 2007 at 05:38 PM
-
Since it's virtually impossible to correctly try out other frameworks while one's working on his own. This would then also help Java developers to make an educated choice about the frameworks that they want to adopt for their projects. Kyosho-Fingerprint-Garment
Posted by: winrelocation on October 30, 2007 at 01:37 AM
-
Adding value expression to validators & converters (http://issues.apache.org/jira/browse/MYFACES-189). Would help creating converters like this one http://www.jboss.com/index.html?module=bb&op=viewtopic&t=122694.
But perhaps this will bring inconsistency in the jsf lifecycle ?
Posted by: gonzalad on October 31, 2007 at 03:53 PM
-
having paginator included in the Standard HTML RenderKit and Allow lazyloading of data since datatable is always(mostly) used with them.
Posted by: davidbrainard on November 10, 2007 at 01:11 PM
-
JSF 2.0 needs to be best in the world, but still time to market in something which we should keep in mind.
Wood Stock 4.3 and Jboss Rich faces 3.2, Seam, Facelets are step in the right direction.
Skinning part should also be standardized.
Charting components are missing, I feel they should be added with high priority.
More complex layout manager are needed even something simillar to html table will be the best gift.
More focus on client side functionality and Rich Internet Applications(RIA) is very critical moving ahead as lot of competition is on way. Please add rich work somewhere in JSF 2.0 release, this is the buzz word these days .
I am sure JSF is the future and need to be kept in focus as JSP has limited life left.
Also please don't think of reinventing wheel in all areas, leverage whatever is already existing and reuse (remember time to market is the key).
Leverage the ide full power to avoid XML hell, create plugins for Netbeans 6.x to create components etc. This is the best way out and the best way to market. Adobe comes with builder and Microsoft with their Studio. JSF team should also focus on reusing the power of Netbeans 6.x and avoid developers from internal complexities and other trivial things while focusing on writing simple API(I will suggest to use more annotations).
Architecturally I am confident this is the future, it just need right focus and positive energy
Investment in JSF is the key for SUN to be in web framework space.
Posted by: rahul_maha on May 30, 2008 at 10:29 AM
-
I have no idea when JSF 2.0 will be released but frequent majorra releases is something best SUN team is doing.
When can we expect 1st formal draft.?
Posted by: rahul_maha on May 30, 2008 at 10:32 AM
-
JSF 2.0 1st Public draft is out and it talks about Facelets offically inclusion. AJAX support .
Messages have not been made as client side component. Valdiations if done using AJAX can not refresh standard JSF messages, but this is possible in JBoss Ricg Faces.
JSFTemplating is no where mentioned.
Bu this good to start and I am happy to see progress in JSF 2.0.
Posted by: rahul_maha on June 03, 2008 at 11:31 PM
-
Hi, JSF 2.0 specs should try to focus on component JSON objects binding. Developers should work on JSON Proxy and framework injecting values into JSON proxies at run-time.
Component authors can write custom function in JSON binded beans and minimize the server calls.
This all thinking is key to making JSF 2.0 to be next generation specs and applications becoming more rich.
If JSF does not focus on this some other framework will do and surely it will be adopted by community.
All components should be light weight can be controlled client-side and server-side.
Everything has to be annotations based ( class-byte code instrumentation), no more XMLs and base classes please!!.
Charting support is nowhere ?? What kind of enterprise application are we thinking of in 2008.
I hope Java team plans to be very active in JSF 2.0 specs.
Posted by: rahul_maha on June 11, 2008 at 09:11 PM
-
I'm so grateful for all that you've done. Thanks again for that nice essay and I would be most grateful if you would send me the latter ones....
mirc
mırc
mirç
mırç
mirc indir
chat yap
islami sohbet
dini sohbet
kelebek
kelebek sohbet
kelebek mirc
kameralı mirc
kameralı sohbet
chat yap
çet
çet odaları
sohbet kanalları
sohbet odaları
yarışma
sevgili
arkadaş
arkadaş ara
arkadaşlık
Posted by: jklmno on June 19, 2008 at 09:07 AM
|
java.net RSS Feeds
