Derick Rethans wrote: > On Mon, 28 Jan 2008, Tobias Schlitt wrote: > > > On 01/29/2008 01:09 AM James Pic wrote: > > > > > Tobias Struckmeier wrote: > > > > >>>> - Input abstraction (also see above) > > >>>>> - Routing > > >>>>> - Controllers > > >>>>> - Output abstraction > > > > >> I want to add here: > > >> - A standard "URL building mechanism" should be there that helps to > > >> build the urls for the specific contexts (eg. AJAX), make redirections > > >> etc. > > > > > Isn't it possible to do with Url component natively ? > > > > Partly, yes. But the idea is to not rely on Url for the Mvc in a first > > place, but to possibly offer a tie-in (later). Therefore we need to > > abstract that somehow. I'd suggest to go with GET parameters for the > > very basic implementation and offer a mechanism that makes use of Url > > through a tie-in. > > I actually don't mind if this is a dependency. I never like the concept > of using GET parameters yourself as that's such a pain. We've the Url > component to handle this, and as Mvc would be a slightly higher level > component, I don't see a dependency as bad.
Actually, only the router should deal with the HTTP request. The component wasn't required to supply a usable router-class. The component allows much freedom to use with other components. Do you mean that the component supplies a router tie-in with Url+UserInput ? In that case, shouldn't it should supply the view-manager tie-ins with Template/(Document)/Pdf etc ... And the PersistentObject tie-in ? Several solutions are possible : - one component per tie-in set, matches the current development-process - another component supplying all the "mvctools" tieins - integrate all the tieins in the "mvctools" component itself I'm fine with any solutions. I think that tieins-supplying should be unified. Regards, James -- James Pic -- Components mailing list [email protected] http://lists.ez.no/mailman/listinfo/components
