On 10/21/07, Kito D. Mann wrote:
Hi!
I'm not on the PMC, but I wanted to state +1 for the record. From dealingHi!
I sent out an e-mail to the Shale mailing list a week or so ago about the
possibility of merging Shale with MyFaces. Development of Shale has become
somewhat stale, and I'd rather see MyFaces pickup the pieces than have the
code base atrophy The overwhelming consensus for the Shale list is "yes"
(and Craig is no exception). What does the MyFaces PMC think?
I am +1.possibility of merging Shale with MyFaces. Development of Shale has become
somewhat stale, and I'd rather see MyFaces pickup the pieces than have the
code base atrophy The overwhelming consensus for the Shale list is "yes"
(and Craig is no exception). What does the MyFaces PMC think?
with students and clients, I think this would be a good thing for JSF.
I think we just have to define which modules we would like to take
over:
(BTW, this list is not to offend anyone, if this might happen, then
sorry in advance - it might be just due to not sensitively enough
choosen english wording.)
* Application Controller
Don't know. I thought action oriented frameworks are outdated, though,
Seam seems to introduce this paradigm again too.
over:
(BTW, this list is not to offend anyone, if this might happen, then
sorry in advance - it might be just due to not sensitively enough
choosen english wording.)
* Application Controller
Don't know. I thought action oriented frameworks are outdated, though,
Seam seems to introduce this paradigm again too.
platform pre servlet Filters, although filters tend to be a pretty
clumsy way to assemble chain of responsibility workflows. I like the
way Struts2/WW do this a lot better, but even that would be more
elegant if you could use managed beans to load the executing logic,
and bind it together with EL expressions.
-1. It's probably better to integrate any sort of direct request processing
into the Remoting support (I know it's currently implemented using the
Application Controller, but that's an implementation detail). Also, I don't
know if anyone actually uses this.
going to affect JSF 2.0 the most. I'd love to see some of the Clay people
help out with Facelets, actually.
That's the same conclusion about the future that I've been coming to.into the Remoting support (I know it's currently implemented using the
Application Controller, but that's an implementation detail). Also, I don't
know if anyone actually uses this.
* Clay
Don't know. I am happy that we (I) moved away from html to components.
-1. Although I know Clay has some supporters, Facelets and JSFTemplating areDon't know. I am happy that we (I) moved away from html to components.
going to affect JSF 2.0 the most. I'd love to see some of the Clay people
help out with Facelets, actually.
* Core Library
Might be a must have
+1Might be a must have
it is *independent* of component libraries. Maybe it could be a
jumpstart for the long-rumored Myfaces shared library that could be
used by all the component libraries for the boring utility stuff?
* Dialog Manager
* Dialog Manager (Basic Implementation)
* Dialog Manager (SCXML Implementation)
The Dialog Manager might be a next step for MyFaces Orchestra. Anyway,
I
hope that one of the original developers is still there to help out
with
things.
+0 I like the idea of integrating this with Orchestra, although I'm not* Dialog Manager (Basic Implementation)
* Dialog Manager (SCXML Implementation)
The Dialog Manager might be a next step for MyFaces Orchestra. Anyway,
I
hope that one of the original developers is still there to help out
with
things.
convinced that Spring should be a requirement to use this feature. If that's
the case, you might as well use Spring Web Flow.
abstract a significant amount of detail behind a common dialog
interface, and then pick a back end implementation with varying sets
of capabilities (and dependencies). Early on in Orchestra's life, I
had suggested to Mario that it would be cool to have an adapter so you
could Orchestra as your dialog implementation :-).
Longer term, this territory is going to get addressed by Web Beans
(JSR-299), which is likely to include all the scope stuff (and more
than Dialog has), coupled with annotation based dependency injection.
But I've always felt that support for scopes other than
request/session/application *really* belongs in the servlet spec so
all Java web technologies can use it ...
* Remoting
Unsure, as most of this can be done with PPR too.
+1 This is pretty useful and easy to use, and will affect JSF 2.0.Unsure, as most of this can be done with PPR too.
to worry about the performance overhead of recreating and updating the
JSF component tree on every Ajax request. Examples would be an
autocomplete component itself, doing async callbacks simply to get the
data it needs to offer as suggestions, with no impact on the component
tree. If you do need to manipulate the component tree, do what
Trinidad or Tobago do with their own components, or use something like
Ajax4JSF or Dynamic Faces instead.
A secondary benefit is near-zero config for resource access,
particularly for resources provided in a jar file instead of as
exploded files in a WAR. Until JSF 2 comes along, that's pretty
useful all by itself.
* Spring Integration
Unsure, I didn't get whats the advantage to the intregration with
Spring
Unsure, I didn't get whats the advantage to the intregration with
Spring
easier on the developer to configure their managed beans there as
well, and this module let you do that with Spring 1. For Spring 2 it
is not relevant, because Spring did it's own integration to let you
create JSF managed beans in whatever scope you want.
-1 This is pretty useless now as far as I can tell.
IIRC, this is already being used in various parts of the MyFaces source tree.* Test Framework
Must have I think
+1Must have I think
* Tiger Extensions
Interesting, however, I'd like to tell everyone to use Spring as MB
facility. And then Spring needs to provide such annotations (which are
already existent I think)
+1 This will serve as a blueprint for JSF 2.0, and it's quite useful.Interesting, however, I'd like to tell everyone to use Spring as MB
facility. And then Spring needs to provide such annotations (which are
already existent I think)
Although it's nice to use Spring, not everybody does, and we shouldn't force
people to do so.
* Tiles Integration
See Clay.
+0 I'll abstain here and since I don't know much about the Tiles side ofSee Clay.
things. Let's just say that I think Tiles integration should "just work" in
MyFaces and Shale.
JSP as their view technology. Not relevant at all for Facelets or
Clay based views.
* Validator Support
A generic client/server validation library for JSF would be REALLY
nice.
Just, I don't like the idea just having a single component for this
(val:commonsValidator), at least, this one needs to be extended.
-1 I haven't heard of too many people using this these days, since Ajax isA generic client/server validation library for JSF would be REALLY
nice.
Just, I don't like the idea just having a single component for this
(val:commonsValidator), at least, this one needs to be extended.
usually easier to do these days. If this is a big desire by the community,
it'd make more sense to integrate it as a proper set of validators or
components.
for server side validation (with a little help for client side
validation as well). The latter is a big missing link in standard JSF
input components, and it would be nice to see a Commons Validator
evolution to provide client side validators too, and some library like
this to wrap them for the JSF use case.
* View Controller
This needs to be reviewed and merged with the Orchestra one if possible
+1 This is a requirement, I think.This needs to be reviewed and merged with the Orchestra one if possible
request, instead of the one you normally get in action frameworks (and
even JSF out of the box). Without this, you're basically thrust into
assembling workflows with filters or Struts2/WW handlers to deal with
some very common use cases.
Craig