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 <dan.t.le...@gmail.com> 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 <cameronmander...@gmail.com> 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 symfony-devs@googlegroups.com
> > To unsubscribe from this group, send email to
> > symfony-devs+unsubscr...@googlegroups.com
> > 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 symfony-devs@googlegroups.com
To unsubscribe from this group, send email to
symfony-devs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
