You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shale.apache.org by "Kito D. Mann" <km...@virtua.com> on 2007/10/21 02:18:48 UTC
Merging Shale into MyFaces
Hello everyone,
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?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kito D. Mann - Author, JavaServer Faces in Action
<http://www.virtua.com/> http://www.virtua.com - JSF/Java EE consulting,
training, and mentoring
<http://www.jsfcentral.com/> http://www.JSFCentral.com - JavaServer Faces
FAQ, news, and info
RE: Merging Shale into MyFaces
Posted by "Kito D. Mann" <km...@virtua.com>.
Right now, you should continue to use the Shale user's mailing list. The
MyFaces merger hasn't happened yet.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kito D. Mann - Author, JavaServer Faces in Action
http://www.virtua.com - JSF/Java EE consulting, training, and mentoring
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
> -----Original Message-----
> From: samju [mailto:julsamusa@netscape.net]
> Sent: Monday, October 29, 2007 3:54 AM
> To: dev@shale.apache.org
> Subject: Re: Merging Shale into MyFaces
>
>
> Hello!!
>
> Where do we can get support for Shale?? MyFaces forum?
>
> thx, Sam
>
> Rahul Akolkar wrote:
> >
> > On 10/21/07, Craig McClanahan <cr...@apache.org> wrote:
> > <big-snip/>
> >>
> >> >
> >> > > * 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
> >> > convinced that Spring should be a requirement to use this feature.
> If
> >> that's
> >> > the case, you might as well use Spring Web Flow.
> >>
> >> The thing I like most about Shale Dialogs is that you really can
> >> 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 :-).
> >>
> > <snap/>
> >
> > While I'm on neither of the PMCs, I continue to be interested in
> Shale
> > dialogs. And as long as I'm around, someone will try to answer user
> > queries etc.
> >
> > -Rahul
> >
> >
> >
> >> 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 ...
> > <snip/>
> >
> >
>
> --
> View this message in context: http://www.nabble.com/Merging-Shale-into-
> MyFaces-tf4664431.html#a13462830
> Sent from the Shale - Dev mailing list archive at Nabble.com.
Re: Merging Shale into MyFaces
Posted by samju <ju...@netscape.net>.
Hello!!
Where do we can get support for Shale?? MyFaces forum?
thx, Sam
Rahul Akolkar wrote:
>
> On 10/21/07, Craig McClanahan <cr...@apache.org> wrote:
> <big-snip/>
>>
>> >
>> > > * 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
>> > convinced that Spring should be a requirement to use this feature. If
>> that's
>> > the case, you might as well use Spring Web Flow.
>>
>> The thing I like most about Shale Dialogs is that you really can
>> 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 :-).
>>
> <snap/>
>
> While I'm on neither of the PMCs, I continue to be interested in Shale
> dialogs. And as long as I'm around, someone will try to answer user
> queries etc.
>
> -Rahul
>
>
>
>> 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 ...
> <snip/>
>
>
--
View this message in context: http://www.nabble.com/Merging-Shale-into-MyFaces-tf4664431.html#a13462830
Sent from the Shale - Dev mailing list archive at Nabble.com.
Re: Merging Shale into MyFaces
Posted by Rahul Akolkar <ra...@gmail.com>.
On 10/21/07, Craig McClanahan <cr...@apache.org> wrote:
<big-snip/>
>
> >
> > > * 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
> > convinced that Spring should be a requirement to use this feature. If that's
> > the case, you might as well use Spring Web Flow.
>
> The thing I like most about Shale Dialogs is that you really can
> 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 :-).
>
<snap/>
While I'm on neither of the PMCs, I continue to be interested in Shale
dialogs. And as long as I'm around, someone will try to answer user
queries etc.
-Rahul
> 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 ...
<snip/>
Re: Merging Shale into MyFaces
Posted by Greg Reddin <gr...@gmail.com>.
On 10/21/07, Craig McClanahan <cr...@apache.org> wrote:
>
> > > * Tiles Integration
> > > See Clay.
> >
> > +0 I'll abstain here and since I don't know much about the Tiles side of
> > things. Let's just say that I think Tiles integration should "just work"
> in
> > MyFaces and Shale.
>
> Likely relevant for historical Struts1 users who want to stick with
> JSP as their view technology.
I'm not sure how relevant even this is presently. Tiles 2 is so far removed
from Struts-Tiles that there would still be a significant learning
curve/porting effort. We support the idea of a Struts-Tiles compatibility
layer, but to my knowledge, no work has been done to that end.
Greg
RE: Merging Shale into MyFaces
Posted by "Kito D. Mann" <km...@virtua.com>.
For the record, Tiles does come up in conversation with shops that require
use of JSP.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kito D. Mann - Author, JavaServer Faces in Action
http://www.virtua.com - JSF/Java EE consulting, training, and mentoring
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
> -----Original Message-----
> From: Greg Reddin [mailto:gredbug@gmail.com]
> Sent: Monday, October 22, 2007 11:47 AM
> To: dev@shale.apache.org
> Subject: Re: Merging Shale into MyFaces
>
> On 10/22/07, Antonio Petrelli <an...@gmail.com> wrote:
> >
> >
> > Tiles works with FreeMarker and Struts 2 too. And sincerely I think
> that
> > it
> > could be used for JSF users, if it only gets more support (don't look
> at
> > me,
> > I don't know anything about JSF :-) ).
>
>
> It could be used, but I'm not sure how practical it is. We've seen
> several
> users express interest, but I'm having a hard time seeing benefits over
> Facelets and Clay. I guess if you're employer-constrained into using
> JSP
> then Tiles might be a good option.
>
> Greg
RE: Merging Shale into MyFaces
Posted by "Kito D. Mann" <km...@virtua.com>.
For the record, Tiles does come up in conversation with shops that require
use of JSP.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kito D. Mann - Author, JavaServer Faces in Action
http://www.virtua.com - JSF/Java EE consulting, training, and mentoring
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
> -----Original Message-----
> From: Greg Reddin [mailto:gredbug@gmail.com]
> Sent: Monday, October 22, 2007 11:47 AM
> To: dev@shale.apache.org
> Subject: Re: Merging Shale into MyFaces
>
> On 10/22/07, Antonio Petrelli <an...@gmail.com> wrote:
> >
> >
> > Tiles works with FreeMarker and Struts 2 too. And sincerely I think
> that
> > it
> > could be used for JSF users, if it only gets more support (don't look
> at
> > me,
> > I don't know anything about JSF :-) ).
>
>
> It could be used, but I'm not sure how practical it is. We've seen
> several
> users express interest, but I'm having a hard time seeing benefits over
> Facelets and Clay. I guess if you're employer-constrained into using
> JSP
> then Tiles might be a good option.
>
> Greg
Re: Merging Shale into MyFaces
Posted by Greg Reddin <gr...@gmail.com>.
On 10/22/07, Antonio Petrelli <an...@gmail.com> wrote:
>
>
> Tiles works with FreeMarker and Struts 2 too. And sincerely I think that
> it
> could be used for JSF users, if it only gets more support (don't look at
> me,
> I don't know anything about JSF :-) ).
It could be used, but I'm not sure how practical it is. We've seen several
users express interest, but I'm having a hard time seeing benefits over
Facelets and Clay. I guess if you're employer-constrained into using JSP
then Tiles might be a good option.
Greg
Re: Merging Shale into MyFaces
Posted by Antonio Petrelli <an...@gmail.com>.
2007/10/22, Craig McClanahan <cr...@apache.org>:
>
> >
> > > * Tiles Integration
> > > See Clay.
> >
> > +0 I'll abstain here and since I don't know much about the Tiles side of
> > things. Let's just say that I think Tiles integration should "just work"
> in
> > MyFaces and Shale.
>
> Likely relevant for historical Struts1 users who want to stick with
> JSP as their view technology. Not relevant at all for Facelets or
> Clay based views.
Tiles works with FreeMarker and Struts 2 too. And sincerely I think that it
could be used for JSF users, if it only gets more support (don't look at me,
I don't know anything about JSF :-) ).
Antonio
Re: Merging Shale into MyFaces
Posted by Rahul Akolkar <ra...@gmail.com>.
On 10/21/07, Craig McClanahan <cr...@apache.org> wrote:
<big-snip/>
>
> >
> > > * 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
> > convinced that Spring should be a requirement to use this feature. If that's
> > the case, you might as well use Spring Web Flow.
>
> The thing I like most about Shale Dialogs is that you really can
> 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 :-).
>
<snap/>
While I'm on neither of the PMCs, I continue to be interested in Shale
dialogs. And as long as I'm around, someone will try to answer user
queries etc.
-Rahul
> 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 ...
<snip/>
Re: Merging Shale into MyFaces
Posted by Greg Reddin <gr...@gmail.com>.
On 10/21/07, Craig McClanahan <cr...@apache.org> wrote:
>
> > > * Tiles Integration
> > > See Clay.
> >
> > +0 I'll abstain here and since I don't know much about the Tiles side of
> > things. Let's just say that I think Tiles integration should "just work"
> in
> > MyFaces and Shale.
>
> Likely relevant for historical Struts1 users who want to stick with
> JSP as their view technology.
I'm not sure how relevant even this is presently. Tiles 2 is so far removed
from Struts-Tiles that there would still be a significant learning
curve/porting effort. We support the idea of a Struts-Tiles compatibility
layer, but to my knowledge, no work has been done to that end.
Greg
Re: Merging Shale into MyFaces
Posted by Craig McClanahan <cr...@apache.org>.
A couple of notes embedded below.
On 10/21/07, Kito D. Mann <km...@virtua.com> wrote:
> > Hi!
> > > 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.
>
> I'm not on the PMC, but I wanted to state +1 for the record. From dealing
> 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.
A lot of the reason you need an API for this is the original target
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.
>
> >
> > * 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 are
> 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.
> > * Core Library
> > Might be a must have
>
> +1
Its a pretty small set of utility classes, but the important point is
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
> convinced that Spring should be a requirement to use this feature. If that's
> the case, you might as well use Spring Web Flow.
The thing I like most about Shale Dialogs is that you really can
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.
The original sweet spot for Shale Remoting was where you do *not* want
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
If you had all your business logic beans configured via Spring, it was
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.
>
> > * Test Framework
> > Must have I think
>
> +1
IIRC, this is already being used in various parts of the MyFaces source tree.
>
> > * 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.
> Although it's nice to use Spring, not everybody does, and we shouldn't force
> people to do so.
Not having to put *anything* in a faces-config.xml file is pretty nice :-).
>
> > * Tiles Integration
> > See Clay.
>
> +0 I'll abstain here and since I don't know much about the Tiles side of
> things. Let's just say that I think Tiles integration should "just work" in
> MyFaces and Shale.
Likely relevant for historical Struts1 users who want to stick with
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 is
> 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.
>
The current code primarily adapts Commons Validator to JSF 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.
Think ov View Controller as providing *four* possible callbacks per
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
Re: Merging Shale into MyFaces
Posted by Craig McClanahan <cr...@apache.org>.
A couple of notes embedded below.
On 10/21/07, Kito D. Mann <km...@virtua.com> wrote:
> > Hi!
> > > 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.
>
> I'm not on the PMC, but I wanted to state +1 for the record. From dealing
> 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.
A lot of the reason you need an API for this is the original target
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.
>
> >
> > * 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 are
> 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.
> > * Core Library
> > Might be a must have
>
> +1
Its a pretty small set of utility classes, but the important point is
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
> convinced that Spring should be a requirement to use this feature. If that's
> the case, you might as well use Spring Web Flow.
The thing I like most about Shale Dialogs is that you really can
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.
The original sweet spot for Shale Remoting was where you do *not* want
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
If you had all your business logic beans configured via Spring, it was
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.
>
> > * Test Framework
> > Must have I think
>
> +1
IIRC, this is already being used in various parts of the MyFaces source tree.
>
> > * 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.
> Although it's nice to use Spring, not everybody does, and we shouldn't force
> people to do so.
Not having to put *anything* in a faces-config.xml file is pretty nice :-).
>
> > * Tiles Integration
> > See Clay.
>
> +0 I'll abstain here and since I don't know much about the Tiles side of
> things. Let's just say that I think Tiles integration should "just work" in
> MyFaces and Shale.
Likely relevant for historical Struts1 users who want to stick with
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 is
> 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.
>
The current code primarily adapts Commons Validator to JSF 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.
Think ov View Controller as providing *four* possible callbacks per
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
RE: Merging Shale into MyFaces
Posted by "Kito D. Mann" <km...@virtua.com>.
> Hi!
> > 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.
I'm not on the PMC, but I wanted to state +1 for the record. From dealing
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.
-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.
>
> * 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 are
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
+1
> * 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
convinced that Spring should be a requirement to use this feature. If that's
the case, you might as well use Spring Web Flow.
> * 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.
> * Spring Integration
> Unsure, I didn't get whats the advantage to the intregration with
> Spring
-1 This is pretty useless now as far as I can tell.
> * Test Framework
> Must have I think
+1
> * 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.
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 of
things. Let's just say that I think Tiles integration should "just work" in
MyFaces and Shale.
> * 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 is
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.
> * View Controller
> This needs to be reviewed and merged with the Orchestra one if possible
+1 This is a requirement, I think.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kito D. Mann - Author, JavaServer Faces in Action
http://www.virtua.com - JSF/Java EE consulting, training, and mentoring
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
Re: Merging Shale into MyFaces
Posted by Mario Ivankovits <ma...@ops.co.at>.
Mario Ivankovits wrote:
> Hi!
>> 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.
>
> 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.
>
> * Clay
> Don't know. I am happy that we (I) moved away from html to components.
>
> * Core Library
> Might be a must have
>
> * 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.
>
> * Remoting
> Unsure, as most of this can be done with PPR too.
>
> * Spring Integration
> Unsure, I didn't get whats the advantage to the intregration with Spring
>
> * Test Framework
> Must 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)
>
> * Tiles Integration
> See Clay.
>
> * 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.
>
> * View Controller
> This needs to be reviewed and merged with the Orchestra one if possible
>
>
> I am not going to vote an any of these components yet, first, I'd like
> to see a discussion about them.
> The reason is simple, even MyFaces has some "man/women power" problems
> currently I think. If no one is willing to pick up one of these
> modules they are dead in MyFaces land too.
> Point is, that too many dormand modules in MyFaces might harm the
> MyFaces community. We might create a dormand section where we move
> those modules then to express that we are waiting for someone with
> some urge to pick them up again.
>
> Ciao,
> Mario
>
RE: Merging Shale into MyFaces
Posted by "Kito D. Mann" <km...@virtua.com>.
That's a very good idea..
> -----Original Message-----
> From: Paul Spencer [mailto:paulsp@apache.org]
> Sent: Friday, October 26, 2007 10:27 AM
> To: dev@shale.apache.org
> Subject: Re: Merging Shale into MyFaces
>
> I use the Testing framework. So does Tomahawk.
>
> I suggest creating a release based on the latest snapshot for Shale
> before it goes dormant or is moved to MyFaces. That way projects that
> are using snapshots will have a release.
>
> Paul Spencer
>
>
>
> Mario Ivankovits wrote:
> > Hi!
> >> 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.
> >
> > 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.
> >
> > * Clay
> > Don't know. I am happy that we (I) moved away from html to
> components.
> >
> > * Core Library
> > Might be a must have
> >
> > * 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.
> >
> > * Remoting
> > Unsure, as most of this can be done with PPR too.
> >
> > * Spring Integration
> > Unsure, I didn't get whats the advantage to the intregration with
> Spring
> >
> > * Test Framework
> > Must 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)
> >
> > * Tiles Integration
> > See Clay.
> >
> > * 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.
> >
> > * View Controller
> > This needs to be reviewed and merged with the Orchestra one if
> possible
> >
> >
> > I am not going to vote an any of these components yet, first, I'd
> like
> > to see a discussion about them.
> > The reason is simple, even MyFaces has some "man/women power"
> problems
> > currently I think. If no one is willing to pick up one of these
> modules
> > they are dead in MyFaces land too.
> > Point is, that too many dormand modules in MyFaces might harm the
> > MyFaces community. We might create a dormand section where we move
> those
> > modules then to express that we are waiting for someone with some
> urge
> > to pick them up again.
> >
> > Ciao,
> > Mario
> >
> >
RE: Merging Shale into MyFaces
Posted by "Kito D. Mann" <km...@virtua.com>.
That's a very good idea..
> -----Original Message-----
> From: Paul Spencer [mailto:paulsp@apache.org]
> Sent: Friday, October 26, 2007 10:27 AM
> To: dev@shale.apache.org
> Subject: Re: Merging Shale into MyFaces
>
> I use the Testing framework. So does Tomahawk.
>
> I suggest creating a release based on the latest snapshot for Shale
> before it goes dormant or is moved to MyFaces. That way projects that
> are using snapshots will have a release.
>
> Paul Spencer
>
>
>
> Mario Ivankovits wrote:
> > Hi!
> >> 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.
> >
> > 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.
> >
> > * Clay
> > Don't know. I am happy that we (I) moved away from html to
> components.
> >
> > * Core Library
> > Might be a must have
> >
> > * 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.
> >
> > * Remoting
> > Unsure, as most of this can be done with PPR too.
> >
> > * Spring Integration
> > Unsure, I didn't get whats the advantage to the intregration with
> Spring
> >
> > * Test Framework
> > Must 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)
> >
> > * Tiles Integration
> > See Clay.
> >
> > * 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.
> >
> > * View Controller
> > This needs to be reviewed and merged with the Orchestra one if
> possible
> >
> >
> > I am not going to vote an any of these components yet, first, I'd
> like
> > to see a discussion about them.
> > The reason is simple, even MyFaces has some "man/women power"
> problems
> > currently I think. If no one is willing to pick up one of these
> modules
> > they are dead in MyFaces land too.
> > Point is, that too many dormand modules in MyFaces might harm the
> > MyFaces community. We might create a dormand section where we move
> those
> > modules then to express that we are waiting for someone with some
> urge
> > to pick them up again.
> >
> > Ciao,
> > Mario
> >
> >
Re: Merging Shale into MyFaces
Posted by Paul Spencer <pa...@apache.org>.
I use the Testing framework. So does Tomahawk.
I suggest creating a release based on the latest snapshot for Shale
before it goes dormant or is moved to MyFaces. That way projects that
are using snapshots will have a release.
Paul Spencer
Mario Ivankovits wrote:
> Hi!
>> 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.
>
> 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.
>
> * Clay
> Don't know. I am happy that we (I) moved away from html to components.
>
> * Core Library
> Might be a must have
>
> * 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.
>
> * Remoting
> Unsure, as most of this can be done with PPR too.
>
> * Spring Integration
> Unsure, I didn't get whats the advantage to the intregration with Spring
>
> * Test Framework
> Must 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)
>
> * Tiles Integration
> See Clay.
>
> * 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.
>
> * View Controller
> This needs to be reviewed and merged with the Orchestra one if possible
>
>
> I am not going to vote an any of these components yet, first, I'd like
> to see a discussion about them.
> The reason is simple, even MyFaces has some "man/women power" problems
> currently I think. If no one is willing to pick up one of these modules
> they are dead in MyFaces land too.
> Point is, that too many dormand modules in MyFaces might harm the
> MyFaces community. We might create a dormand section where we move those
> modules then to express that we are waiting for someone with some urge
> to pick them up again.
>
> Ciao,
> Mario
>
>
Re: Merging Shale into MyFaces
Posted by Greg Reddin <gr...@gmail.com>.
On 10/21/07, Niall Pemberton <ni...@gmail.com> wrote:
>
> This is one class[1] and despite what the shale-tiles pom[2] declares,
> it doesn't relate to/depend on any other parts of shale - just JSF and
> Tiles. So it could just as easily be moved to the tiles TLP. Having
> said that, I suggested this a while ago and it was rejected then[3]
I think we were opposed to the idea of providing integration support for
every framework imaginable in the Tiles project. We might be open to rethink
some of that, at least providing some support in subprojects, etc. My
objection was that I didn't want to have to include dependencies to umpteen
frameworks just to implement an integration class. I would be open to the
idea of providing optional (Tiles) subprojects, etc. that "self-contained"
the dependencies, testing, etc. I'm starting to see that such support could
fall under the purview of the Tiles project.
Greg
Re: Merging Shale into MyFaces
Posted by Niall Pemberton <ni...@gmail.com>.
On 10/21/07, Mario Ivankovits <ma...@ops.co.at> wrote:
> Hi!
> > 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.
>
> 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.
>
> * Clay
> Don't know. I am happy that we (I) moved away from html to components.
>
> * Core Library
> Might be a must have
>
> * 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.
>
> * Remoting
> Unsure, as most of this can be done with PPR too.
>
> * Spring Integration
> Unsure, I didn't get whats the advantage to the intregration with Spring
>
> * Test Framework
> Must 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)
>
> * Tiles Integration
This is one class[1] and despite what the shale-tiles pom[2] declares,
it doesn't relate to/depend on any other parts of shale - just JSF and
Tiles. So it could just as easily be moved to the tiles TLP. Having
said that, I suggested this a while ago and it was rejected then[3]
Niall
[1] http://tinyurl.com/2ekcr6
[2] http://tinyurl.com/ytg7q2
[3] http://tinyurl.com/2y6ull
> * 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.
>
> * View Controller
> This needs to be reviewed and merged with the Orchestra one if possible
>
>
> I am not going to vote an any of these components yet, first, I'd like
> to see a discussion about them.
> The reason is simple, even MyFaces has some "man/women power" problems
> currently I think. If no one is willing to pick up one of these modules
> they are dead in MyFaces land too.
> Point is, that too many dormand modules in MyFaces might harm the
> MyFaces community. We might create a dormand section where we move those
> modules then to express that we are waiting for someone with some urge
> to pick them up again.
>
> Ciao,
> Mario
>
>
RE: Merging Shale into MyFaces
Posted by "Kito D. Mann" <km...@virtua.com>.
> Hi!
> > 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.
I'm not on the PMC, but I wanted to state +1 for the record. From dealing
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.
-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.
>
> * 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 are
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
+1
> * 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
convinced that Spring should be a requirement to use this feature. If that's
the case, you might as well use Spring Web Flow.
> * 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.
> * Spring Integration
> Unsure, I didn't get whats the advantage to the intregration with
> Spring
-1 This is pretty useless now as far as I can tell.
> * Test Framework
> Must have I think
+1
> * 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.
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 of
things. Let's just say that I think Tiles integration should "just work" in
MyFaces and Shale.
> * 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 is
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.
> * View Controller
> This needs to be reviewed and merged with the Orchestra one if possible
+1 This is a requirement, I think.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kito D. Mann - Author, JavaServer Faces in Action
http://www.virtua.com - JSF/Java EE consulting, training, and mentoring
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
Re: Merging Shale into MyFaces
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
> 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.
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.
* Clay
Don't know. I am happy that we (I) moved away from html to components.
* Core Library
Might be a must have
* 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.
* Remoting
Unsure, as most of this can be done with PPR too.
* Spring Integration
Unsure, I didn't get whats the advantage to the intregration with Spring
* Test Framework
Must 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)
* Tiles Integration
See Clay.
* 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.
* View Controller
This needs to be reviewed and merged with the Orchestra one if possible
I am not going to vote an any of these components yet, first, I'd like
to see a discussion about them.
The reason is simple, even MyFaces has some "man/women power" problems
currently I think. If no one is willing to pick up one of these modules
they are dead in MyFaces land too.
Point is, that too many dormand modules in MyFaces might harm the
MyFaces community. We might create a dormand section where we move those
modules then to express that we are waiting for someone with some urge
to pick them up again.
Ciao,
Mario
Re: Merging Shale into MyFaces
Posted by Mario Ivankovits <ma...@ops.co.at>.
By accident I sent my answer to dev@shale only.
If possible, we should discuss this topic just in dev@myfaces, no?
I'd like to invent every Shale developer not yet at dev@myfaces to
subscribe there too.
Is this an option?
Ciao,
Mario
Kito D. Mann schrieb:
> Hello everyone,
>
>
>
> 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?
>
>
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Kito D. Mann - Author, JavaServer Faces in Action
> <http://www.virtua.com/> http://www.virtua.com - JSF/Java EE consulting,
> training, and mentoring
> <http://www.jsfcentral.com/> http://www.JSFCentral.com - JavaServer Faces
> FAQ, news, and info
>
>
>
>
>
>
>
Re: Merging Shale into MyFaces
Posted by Mario Ivankovits <ma...@ops.co.at>.
By accident I sent my answer to dev@shale only.
If possible, we should discuss this topic just in dev@myfaces, no?
I'd like to invent every Shale developer not yet at dev@myfaces to
subscribe there too.
Is this an option?
Ciao,
Mario
Kito D. Mann schrieb:
> Hello everyone,
>
>
>
> 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?
>
>
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Kito D. Mann - Author, JavaServer Faces in Action
> <http://www.virtua.com/> http://www.virtua.com - JSF/Java EE consulting,
> training, and mentoring
> <http://www.jsfcentral.com/> http://www.JSFCentral.com - JavaServer Faces
> FAQ, news, and info
>
>
>
>
>
>
>
Re: Merging Shale into MyFaces
Posted by Dennis Byrne <de...@apache.org>.
+1 from me, but only if my logo contest entry is retroactively promoted to
the official Shale logo.
http://shale.apache.org/logo-contest.html
Dennis Byrne
On 10/20/07, Kito D. Mann <km...@virtua.com> wrote:
>
> Hello everyone,
>
>
>
> 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?
>
>
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Kito D. Mann - Author, JavaServer Faces in Action
> http://www.virtua.com - JSF/Java EE consulting, training, and mentoring
> http://www.JSFCentral.com <http://www.jsfcentral.com/> - JavaServer Faces
> FAQ, news, and info
>
>
>
--
Dennis Byrne
Re: Merging Shale into MyFaces
Posted by Dennis Byrne <de...@apache.org>.
+1 from me, but only if my logo contest entry is retroactively promoted to
the official Shale logo.
http://shale.apache.org/logo-contest.html
Dennis Byrne
On 10/20/07, Kito D. Mann <km...@virtua.com> wrote:
>
> Hello everyone,
>
>
>
> 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?
>
>
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Kito D. Mann - Author, JavaServer Faces in Action
> http://www.virtua.com - JSF/Java EE consulting, training, and mentoring
> http://www.JSFCentral.com <http://www.jsfcentral.com/> - JavaServer Faces
> FAQ, news, and info
>
>
>
--
Dennis Byrne
Re: Merging Shale into MyFaces
Posted by Greg Reddin <gr...@gmail.com>.
Meant to send to MyFaces rather than Shale. Sorry for the double post.
On 10/22/07, Greg Reddin <gr...@gmail.com> wrote:
>
> On 10/20/07, Kito D. Mann <km...@virtua.com> wrote:
> >
> > 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?
>
>
> Wow, my mailing-list mgmt. skills must be worse than I thought :-) How did
> I totally miss that thread? I'll check the archives.
>
> Anyway, I'm in favor of the notion. My only reservation would be that the
> MyFaces community could become too splintered with JSF "extras". Was that
> discussed in the original thread?
>
> Greg
>
>
Re: Merging Shale into MyFaces
Posted by Greg Reddin <gr...@gmail.com>.
On 10/20/07, Kito D. Mann <km...@virtua.com> wrote:
>
> 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?
Wow, my mailing-list mgmt. skills must be worse than I thought :-) How did I
totally miss that thread? I'll check the archives.
Anyway, I'm in favor of the notion. My only reservation would be that the
MyFaces community could become too splintered with JSF "extras". Was that
discussed in the original thread?
Greg