atom feed33 messages in org.apache.shale.devRe: Merging Shale into MyFaces
FromSent OnAttachments
Kito D. MannOct 20, 2007 5:18 pm 
Dennis ByrneOct 20, 2007 5:22 pm 
Mario IvankovitsOct 20, 2007 11:51 pm 
Mario IvankovitsOct 21, 2007 12:05 am 
Gary VanMatreOct 21, 2007 10:39 am 
Gary VanMatreOct 21, 2007 10:41 am 
Kito D. MannOct 21, 2007 11:28 am 
Niall PembertonOct 21, 2007 12:38 pm 
Craig McClanahanOct 21, 2007 4:47 pm 
Antonio PetrelliOct 22, 2007 12:02 am 
Bernhard SlominskiOct 22, 2007 5:40 am 
Gary VanMatreOct 22, 2007 7:37 am 
Rahul AkolkarOct 22, 2007 8:11 am 
Greg ReddinOct 22, 2007 8:31 am 
Greg ReddinOct 22, 2007 8:34 am 
Greg ReddinOct 22, 2007 8:41 am 
Greg ReddinOct 22, 2007 8:44 am 
Greg ReddinOct 22, 2007 8:46 am 
Kito D. MannOct 22, 2007 8:48 am 
Pavel SavaraOct 22, 2007 9:14 am 
Gary VanMatreOct 22, 2007 9:23 am 
Bernhard SlominskiOct 22, 2007 9:32 am 
Kito D. MannOct 22, 2007 9:44 am 
Kito D. MannOct 22, 2007 9:48 am 
Kito D. MannOct 22, 2007 9:49 am 
Mario IvankovitsOct 22, 2007 10:54 am 
Kito D. MannOct 25, 2007 10:21 am 
Matthias WessendorfOct 25, 2007 10:42 am 
Martin MarinschekOct 25, 2007 12:32 pm 
Paul SpencerOct 26, 2007 7:26 am 
Kito D. MannOct 26, 2007 9:40 am 
samjuOct 29, 2007 12:53 am 
Kito D. MannOct 29, 2007 10:33 am 
Subject:Re: Merging Shale into MyFaces
From:Gary VanMatre (gvan@comcast.net)
Date:Oct 21, 2007 10:39:51 am
List:org.apache.shale.dev

From: Mario Ivankovits <mar@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.

-1

* Clay Don't know. I am happy that we (I) moved away from html to components.

+0

I'm pretty certain that JSF 2 will have some kind of template language that is not JSP. I'm also certain that it won't try inheritance but will most likely look like facelets + jsftemplating.

To be honest, I've never had a chance to use Clay outside of just building it. I know there are a couple adopters that we should consider feedback from.

Actually, I'm looking forward too trying it all over with the 2.0 jsf impl.

* 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.

+1

* Remoting Unsure, as most of this can be done with PPR too.

+1

JSF 2.0 will have resource delivery that is based on Shale Remoting.

* Spring Integration Unsure, I didn't get whats the advantage to the intregration with Spring

-1

* Test Framework Must have I think

+1 Shale test is a must. IMO, it's one of the best nuggets in the bunch.

* 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 JSF 2.0 is also considering Shale Tiger in the specification.

* Tiles Integration See Clay.

+0

Clay and tiles are two different things. I know that there needs to be some work
done to make shale-tiles work with JSF 1.2 and integrate with tiles (tlp) 2.x.

Rich ADF faces has a JSP templating feature that's pretty cool but don't have
the rich nested composition options that tiles has. Unsure of the status of that one...

* 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 did allot of work on commons validator and I really believe that the only
way to make this work (client-side) is to couple it into a component library framework.

* View Controller This needs to be reviewed and merged with the Orchestra one if possible

+1

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

Gary