Again, Craig, we are in complete agreement. I also am madly in love with the basic idea behind Tiles and with what Tiles does. I don't see why everyone isn't.
Tiles, however, uses a "controller" in a very different sense than the sense Struts uses a web framework controller in a MVC pattern. Tiles is not at all like Java ServerFaces. That is to mix apples and oranges. Tiles, unlike Java ServerFaces, is perfectly consistent with Struts. Indeed, the JerichoFaces envisioned at http://131.191.32.112:8080/ encompasses the whole Tiles idea. The fact that Tiles has an interface used to insert the referents of attributes in definitions which is called incidentally called "Controller" does not mean it is anything like a controller in an MVC framework. It is not. Tiles is not a page based MVC controller or any type of MVC controller at all, and is consistent with either a page based controller such as Java ServerFaces or a controller that keeps the view and the model appropriately separate such as Struts. RIght? The bottom line is that Shale is wholly inconsistent with the Struts approach. If Struts 2.0 becomes Shale, Struts is dead. That would be, I think, a shame. I would encourage Shale and Struts. I know that as things stand, I simply cannot go the Shale route. So far my concerns are magnified not ameliorated by my admitted learning curve on Java ServerFaces. If Shale were to adopt something like Java ServerFaces but consistent with Sttuts, that would be different. But that is not in the mix, so the difference is moot. As you can see, at http://131.191.32.112:8080/ I have now split up JerichoData and JerichoFaces. I think that a wholly separate event based architecture with a multithreaded scheduler on the side is needed for workflow. That is what I have been doing for about six months and I am very happy with the results. The View in the MVC does not care about the model, really. What it cares about is what eventually is moved to request, page (tile), session and application scope and is available to tags. Consequently, I think that an abstraction which provides a framework data center apart from the model data in databases, etc., not only makes sense but will allow workflows to concentrate on algorithms and policies and not worry about where the data is. The data will be where the interface between the JerichoFaces and JerichoData says it is. The basic idea is just to have a Data interface which JerichoFaces can use to retrieve its Data for its components. Thanks for your thoughts. Please feel free to smack me around if there is some legitimate sense in which Tiles Controller classes can be considered to be a controller in the MVC pattern in Struts. On Wed, 17 Nov 2004 21:52:56 -0800, Craig McClanahan <[EMAIL PROTECTED]> wrote: > On Wed, 17 Nov 2004 21:43:14 -0800, Dakota Jack <[EMAIL PROTECTED]> wrote: > > Craig, > > > > I not only have no technical arguments against a View Helper design > > pattern, but the suggestion on the Wiki WhiteBoard for Struts both for > > the JerichoData and the JerichoFaces is an instance of advocating such > > a design pattern. What I don't trust is the page based controller. > > It's sort of interesting that a "page controller" is one of the things > people really like about Tiles, for the same reason I like it -- > cutting down on the number of moving parts :-). > > http://struts.apache.org/api/org/apache/struts/tiles/Controller.html > > > > > Jack > > > > Craig > > > > > > > > >Personally, I'm underwhelmed by the technical arguments made against a > > >View Helper design pattern so far, so I'm not particularly interested > > >(personally) in Jericho or JerichoFaces as a solution to anything -- > > >but who knows, some of the other developers might be. > > > > -- > > "You can't wake a person who is pretending to be asleep." > > > > ~Native Proverb~ > > > > "Each man is good in His sight. It is not necessary for eagles to be crows." > > > > ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
