On 8/18/07, Mario Ivankovits <[EMAIL PROTECTED]> wrote: > Hi! > > There is already an implementation of this sort of thing in the Shale > > project's view-controller module: > > http://shale.apache.org/shale-view/index.html > > > I do not have any good argument why I didn't go the shale way. Maybe I > was just to shy to convince the shale people about the surely required > API change which might have been resulted in an huge patch .... <snip/>
Eh? Majority of the Shale folks are also members of the MyFaces community (e.g. Craig, Gary, Wendy, Sean, Matthais) -- I'd like to believe that'd be useful to the cause? > And I just doesn't know at the time of writing this stuff what the exact > API changes in Shale would have been. > > I'd say, Orchestras implementation is just a lightweight variant of the > shale stuff. > If we would like to go the shale way, we have to add the shale, > shale-view and shale-tiger jar to the project which requires the view > controller stuff. > Doesn't really help in lowering the stack required to startup an > Orchestra application, does it? > <snap/> Its not too bad (Shale is more modular than before and getting better in that respect still) and it may be the right thing to do (I haven't looked at a line of [orchestra] code). I understand that there can always be numerous reasons for coming up with "Yet Another Foo", but might be useful to pause to see how much of the overlap is a service or disservice to users. Considering three coarse phases in the evolution of many technologies around us ... 1) Discovery - Someone invents something cool, people rave 2) Thousand flowers blooming - Everyone wants to do it their own way 3) Standardization - Soon enough users are fed up with (2) ... I'd encourage the [orchestra] folks to take a look at the overlap in Shale (or elsewhere) and perhaps participate / collaborate / discuss where it makes sense? -Rahul
