RE: Merging Shale into MyFaces
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:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
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
That's a very good idea.. -Original Message- From: Paul Spencer [mailto:[EMAIL PROTECTED] 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
-Original Message- From: Martin Marinschek [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 24, 2007 3:16 AM To: MyFaces Development; [EMAIL PROTECTED] Subject: Re: Merging Shale into MyFaces For me, a merger makes sense. Seems almost unanimous :-). The question is who will do the work, though. That's always the question :-). Some reflections on the modules: - ViewController/Dialog: I hope Orchestra can take in what makes sense here (the notion of subflows which I like Orchesta a lot, but I don't think the view controller/dialog features should be tied to Spring - Clay: Yes, obviously Facelets has won the race - we should all concentrate our efforts there, so that the JSF community can profit as a whole (and is not splitted) Facelets definitely needs more resources too. - Tiger-extensions: again, this would make sense in Orchestra, as an alternative way of configuring Orchestras beans (and also other beans, of course) to using Spring I think we'd still need to support standard managed beans, though. - test-framework: we've long used it in MyFaces, but for recent tests both Matthias and me have used EasyMock, it is somewhat easier to define changing interface behaviour with EasyMock than with static mock-classes. Still, this is valuable, and should be a separate module in the merger. Could shale-test be enhanced by using EasyMock? ' - validators - no, probably not really - s:token: I'd love to have a generic way of preventing duplicated posts. But I guess this is something that Orchestra could eventually handle? Honestly, this may be more of a Tomahawk think. Perhaps a specialized form component? apart from that, I don't know much more about Shale - sorry. regards, Martin On 10/22/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Ok, so what about having a 'myfaces dormant' project where each module gets added where it seems there is no real maintainer. This could be a place for abandoned sandbox stuff too. I know, the word 'maintainer' is not well placed in the context of an apache community, but in the end I think it would be fair to show to users that no one is really working on an project. Mario -Original Message- From: Grant Smith [EMAIL PROTECTED] Date: Monday, Okt 22, 2007 6:02 pm Subject: Re: Merging Shale into MyFaces To: Reply-MyFaces Development [EMAIL PROTECTED]To: MyFaces Development [EMAIL PROTECTED] Conceptually, I am in favor of a merge. I wouldn't wait for JSF 2.0 to do it, though. +1. On 10/22/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:At least, 1 year, that is my guess. So, I agree w/ Kito here -M On 10/22/07, Kito D. Mann [EMAIL PROTECTED] wrote: I don't think that's a good idea, since JSF 2.0 is a year or more away ~~~ 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: Bernhard Slominski [mailto:[EMAIL PROTECTED] Sent: Monday, October 22, 2007 8:41 AM To: 'dev@shale.apache.org'; MyFaces Development Subject: AW: Merging Shale into MyFaces Hi all, I guess it makes sense, to make the merger a post JSF 2 project. So all features, which are included in JSF 2 (e.g Remoting) should not move, but just stay in Shale. Also let's see where templating and component development goes before making a decision about Clay. So Shale is then the JSF 1.X add-on framework, when it comes to JSF 2 all Add-Ons move to MyFaces. Bernhard -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Auftrag von Craig McClanahan Gesendet: Montag, 22. Oktober 2007 01:48 An: MyFaces Development; Shale Developers List Betreff: Re: Merging Shale into MyFaces * 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. A secondary benefit is near-zero config for resource access, gt -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Merging Shale into MyFaces
- test-framework: we've long used it in MyFaces, but for recent tests both Matthias and me have used EasyMock, it is somewhat easier to define changing interface behaviour with EasyMock than with static mock-classes. Still, this is valuable, and should be a separate module in the merger. Could shale-test be enhanced by using EasyMock? there is JMock support in -M ' - validators - no, probably not really - s:token: I'd love to have a generic way of preventing duplicated posts. But I guess this is something that Orchestra could eventually handle? Honestly, this may be more of a Tomahawk think. Perhaps a specialized form component? apart from that, I don't know much more about Shale - sorry. regards, Martin On 10/22/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Ok, so what about having a 'myfaces dormant' project where each module gets added where it seems there is no real maintainer. This could be a place for abandoned sandbox stuff too. I know, the word 'maintainer' is not well placed in the context of an apache community, but in the end I think it would be fair to show to users that no one is really working on an project. Mario -Original Message- From: Grant Smith [EMAIL PROTECTED] Date: Monday, Okt 22, 2007 6:02 pm Subject: Re: Merging Shale into MyFaces To: Reply-MyFaces Development [EMAIL PROTECTED]To: MyFaces Development [EMAIL PROTECTED] Conceptually, I am in favor of a merge. I wouldn't wait for JSF 2.0 to do it, though. +1. On 10/22/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:At least, 1 year, that is my guess. So, I agree w/ Kito here -M On 10/22/07, Kito D. Mann [EMAIL PROTECTED] wrote: I don't think that's a good idea, since JSF 2.0 is a year or more away ~~~ 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: Bernhard Slominski [mailto:[EMAIL PROTECTED] Sent: Monday, October 22, 2007 8:41 AM To: 'dev@shale.apache.org'; MyFaces Development Subject: AW: Merging Shale into MyFaces Hi all, I guess it makes sense, to make the merger a post JSF 2 project. So all features, which are included in JSF 2 (e.g Remoting) should not move, but just stay in Shale. Also let's see where templating and component development goes before making a decision about Clay. So Shale is then the JSF 1.X add-on framework, when it comes to JSF 2 all Add-Ons move to MyFaces. Bernhard -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Auftrag von Craig McClanahan Gesendet: Montag, 22. Oktober 2007 01:48 An: MyFaces Development; Shale Developers List Betreff: Re: Merging Shale into MyFaces * 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. A secondary benefit is near-zero config for resource access, gt -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
Re: Merging Shale into MyFaces
- ViewController/Dialog: I hope Orchestra can take in what makes sense here (the notion of subflows which I like Orchesta a lot, but I don't think the view controller/dialog features should be tied to Spring I see two configuration options - Spring and annotations. The managed bean-facility just won't cope with scope=conversation! - test-framework: we've long used it in MyFaces, but for recent tests both Matthias and me have used EasyMock, it is somewhat easier to define changing interface behaviour with EasyMock than with static mock-classes. Still, this is valuable, and should be a separate module in the merger. Could shale-test be enhanced by using EasyMock? nope. I don't think so - it's very much static mocks or dynamic mocks (well, with a few exceptions, were you actually need implementation classes). I don't see much of a mixture here. regards, Martin
Re: Merging Shale into MyFaces
2007/10/22, Craig McClanahan [EMAIL PROTECTED]: * 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
AW: Merging Shale into MyFaces
Hi all, I guess it makes sense, to make the merger a post JSF 2 project. So all features, which are included in JSF 2 (e.g Remoting) should not move, but just stay in Shale. Also let's see where templating and component development goes before making a decision about Clay. So Shale is then the JSF 1.X add-on framework, when it comes to JSF 2 all Add-Ons move to MyFaces. Bernhard -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Auftrag von Craig McClanahan Gesendet: Montag, 22. Oktober 2007 01:48 An: MyFaces Development; Shale Developers List Betreff: Re: Merging Shale into MyFaces * 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. 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. Craig
Re: Merging Shale into MyFaces
On 10/21/07, Craig McClanahan [EMAIL PROTECTED] 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
On 10/20/07, Kito D. Mann [EMAIL PROTECTED] 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
On 10/21/07, Niall Pemberton [EMAIL PROTECTED] 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
On 10/21/07, Craig McClanahan [EMAIL PROTECTED] 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
From: Pavel Savara [EMAIL PROTECTED] but I'm having a hard time seeing benefits over Facelets and Clay. What I see as benefit for tiles is possibility to define another tiles.xml config which specify what page should be displayed for different locale. So you don't have only localized messages and text but complete web page layout event you can serve completely different web page under the same url for different locale. Not sure it this is possible in clay or facelets. FWIW, this is definitly possible in clay. Pavel Gary -Original Message- From: Greg Reddin [mailto:[EMAIL PROTECTED] Sent: Monday, October 22, 2007 4:47 PM To: dev@shale.apache.org Subject: Re: Merging Shale into MyFaces On 10/22/07, Antonio Petrelli 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
AW: Merging Shale into MyFaces
The spec develops over the time so even it's not finsihed we roughly know what will be in it, it's getting clearer when time moves on. Maybe for the merger we don't have to set a hard dependency on JSF2, but it doesn't make sense to me to migrate any features which are not needed anymore in the near furture like Remoting. Bernhard -Ursprüngliche Nachricht- Von: Kito D. Mann [mailto:[EMAIL PROTECTED] Gesendet: Montag, 22. Oktober 2007 17:49 An: dev@shale.apache.org Betreff: RE: Merging Shale into MyFaces I don't think that's a good idea, since JSF 2.0 is a year or more away ~~~ 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: Bernhard Slominski [mailto:[EMAIL PROTECTED] Sent: Monday, October 22, 2007 8:41 AM To: 'dev@shale.apache.org'; MyFaces Development Subject: AW: Merging Shale into MyFaces Hi all, I guess it makes sense, to make the merger a post JSF 2 project. So all features, which are included in JSF 2 (e.g Remoting) should not move, but just stay in Shale. Also let's see where templating and component development goes before making a decision about Clay. So Shale is then the JSF 1.X add-on framework, when it comes to JSF 2 all Add-Ons move to MyFaces. Bernhard
RE: Merging Shale into MyFaces
-Original Message- From: Bernhard Slominski [mailto:[EMAIL PROTECTED] Sent: Monday, October 22, 2007 12:33 PM To: 'dev@shale.apache.org' Subject: AW: Merging Shale into MyFaces The spec develops over the time so even it's not finsihed we roughly know what will be in it, it's getting clearer when time moves on. Maybe for the merger we don't have to set a hard dependency on JSF2, but it doesn't make sense to me to migrate any features which are not needed anymore in the near furture like Remoting. Seems to me it'd be easy to implement JSF 2.0 in MyFaces if we're already maintaining a similar code base... -Ursprüngliche Nachricht- Von: Kito D. Mann [mailto:[EMAIL PROTECTED] Gesendet: Montag, 22. Oktober 2007 17:49 An: dev@shale.apache.org Betreff: RE: Merging Shale into MyFaces I don't think that's a good idea, since JSF 2.0 is a year or more away ~~~ 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: Bernhard Slominski [mailto:[EMAIL PROTECTED] Sent: Monday, October 22, 2007 8:41 AM To: 'dev@shale.apache.org'; MyFaces Development Subject: AW: Merging Shale into MyFaces Hi all, I guess it makes sense, to make the merger a post JSF 2 project. So all features, which are included in JSF 2 (e.g Remoting) should not move, but just stay in Shale. Also let's see where templating and component development goes before making a decision about Clay. So Shale is then the JSF 1.X add-on framework, when it comes to JSF 2 all Add-Ons move to MyFaces. Bernhard
RE: Merging Shale into MyFaces
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:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
-Original Message- From: Pavel Savara [mailto:[EMAIL PROTECTED] Sent: Monday, October 22, 2007 12:15 PM To: dev@shale.apache.org Subject: RE: Merging Shale into MyFaces but I'm having a hard time seeing benefits over Facelets and Clay. What I see as benefit for tiles is possibility to define another tiles.xml config which specify what page should be displayed for different locale. So you don't have only localized messages and text but complete web page layout event you can serve completely different web page under the same url for different locale. Not sure it this is possible in clay or facelets. In Facelets, this isn't built in, but it'd be pretty easy to implement. -Original Message- From: Greg Reddin [mailto:[EMAIL PROTECTED] Sent: Monday, October 22, 2007 4:47 PM To: dev@shale.apache.org Subject: Re: Merging Shale into MyFaces On 10/22/07, Antonio Petrelli [EMAIL PROTECTED] 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
Greg Reddin schrieb: If this is turning into a vote we should specify what +1 and -1 means. Does -1 mean no, don't port it or no we have to have this? :-) I'd say a -1 means it will end up in an MyFaces dormant project. If we agree having one at all. Ciao, Mario
Re: Merging Shale into MyFaces
By accident I sent my answer to [EMAIL PROTECTED] only. If possible, we should discuss this topic just in [EMAIL PROTECTED], no? I'd like to invent every Shale developer not yet at [EMAIL PROTECTED] 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
A couple of notes embedded below. On 10/21/07, Kito D. Mann [EMAIL PROTECTED] 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
