Thanks for the suggestion Dan :-) I wonder if when symfony2 creates the new sub request whether it could also link back to the master request, stopping from you needing to make it a parameter of your request?
Would this be a good suggestion? On Jul 15, 8:27 pm, Dan Leech <[email protected]> wrote: > We pass the container of the parent request as a parameter to the sub > request action when rendering dynamic content on a page, e.g. > > public function fooAction($parentContainer) { > $formData = $parentContainer->get('request')->get('fooFormData'); > > } > > On 14 July 2011 23:05, cammanderson <[email protected]> wrote: > > > > > > > Hi Guys, > > > I have worked on developing a few CMS's, and the idea of being able to > > have an initial request that dynamically calls-in/loads other content > > elements is very useful (think H-MVC). The problem I have is that due > > to the very dynamic behaviour of those includes we can't easily > > identify which parts of the original request parameters will be > > useful. > > > Currently, when we include another controller or URL, a new request is > > authored without any parameters being passed through. I understand > > this is to do with how ESI technology works, but I don't think that it > > has to be the only exclusive way of handling this. Is it possible to > > have an option that allows the current request parameters/files etc > > passed through automatically in a subrequest. > > > I have thought about it in the past, and wasn't sure whether I thought > > it should be part of the main app. > > > A trivial example where this makes sense: > > A page that loads some static content, but also draws in a Form (using > > the render call or similar). We can not anticipate the requirements of > > the form in the initial controller in this case, unless we want to > > create that dependency. If we draw in that other form we lose access > > to the original request parameters/files unless we explicitly define > > them in the view level. The simplest example of this would be a page > > that loads and article, and has included some form of a subscription > > form on the right hand side. The request is to be sent to the same > > current page, and using H-MVC the form is handled independently. The > > original controller used to load the article shouldn't be involved in > > handling the form, or need to have the view updated with changes to > > the subscription form. Of course alternative approaches exist for this > > scenario, but there could be 15 or more different actions that are > > being embedded on each page, each with their own MVC (hence the H-MVC > > capability). > > > I would suggest that an additional flag (like the standalone flag) > > that would allow us to pipe the request (sans the controller > > identification etc) with all the parameters/files etc to that > > page.This will allow us to develop H-MVC approaches without creating > > cascading pass-throughs needing to be defined at every level to be > > able to hold onto parts of the request that further down the chain > > needs. > > > It may very well be a feature that is not supported by the caching/ESI > > component, but for a flexibility for creating dynamic H-MVC that can > > handle forms (post data) further down the chain. > > > Cheers > > Cameron > > > -- > > If you want to report a vulnerability issue on symfony, please send it to > > security at symfony-project.com > > > You received this message because you are subscribed to the Google > > Groups "symfony developers" group. > > To post to this group, send email to [email protected] > > To unsubscribe from this group, send email to > > [email protected] > > For more options, visit this group at > >http://groups.google.com/group/symfony-devs?hl=en > > -- > Dan Leech > > Web Developerwww.dantleech.com -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
