Re: [fw-general] Creating a portal-like site
I think I understand the gist of what you're getting at now. a) Use Ajax to asynchronously process things like subscribing and logging in, using a small JSON or XML token that reports either success (with relevant data like success message, first name, user ID, etc.) or failure (with any error messages). b) As a fallback method, check the referrer on the server side and, after processing the request, redirect them back there when appropriate using a common helper class. If you use Prototype for your Ajax functionality, you can check if a request was made with XMLHttpRequest or not (via the non-standard X-Requested-With header), and redirect them if you need to. There's no standard way to do this because Zend Framework doesn't (and shouldn't) endorse a specific JavaScript framework. If you used another JS framework, you might have to have two entry points (one that redirects, one that doesn't). Even if you chose to do it strictly on the server side, the redirect functionality is already built in--you just have to figure out where the request is sent to. Hope that helps, -Matt On Sat, March 24, 2007 8:52 am, Stephan Stapel wrote: > that's right but probably wouldn't work here. > > What I imagined about creating a portal project was: > Say we have a page called index (IndexController, index.tpl.php). On the > index page, we embed two 'portlets' called subscribeNewsletter > (SubscribeController, subscribe.tpl.php) which comes with a Javascript > button called 'subscribe' and login (LoginController, login.tpl.php) which > comes with a Javascript button 'login' into one cell of the table layout > each. > > When someone now presses the subscribe button, we have to process > SubscribeController::subscribeAction() as the activity on the portlet but > also we need to stay on the index page, i.e. > IndexController::indexAction() should be processed as we don't change the > page but only invoked a particular portlet action. > > What I'm aiming at is that I would like to be more flexible, e.g. adding > more portlets to a page (in this case, it could be a news portlet) or > removing them (removing the subscribe portlet). > > What I'm worrying about is whether such behaviour could be implemented > using the routing classes and the framework in general. > > Would you implement it like this or choose another approach? > > regards, > > Stephan
Re: [fw-general] Creating a portal-like site
Hi Matt, > > Form actions would just be URLs like any other in your application. Say > a user is at the application index, and logs in. A form action of > '/user/login' would send form results to UserController::loginAction(). > that's right but probably wouldn't work here. What I imagined about creating a portal project was: Say we have a page called index (IndexController, index.tpl.php). On the index page, we embed two 'portlets' called subscribeNewsletter (SubscribeController, subscribe.tpl.php) which comes with a Javascript button called 'subscribe' and login (LoginController, login.tpl.php) which comes with a Javascript button 'login' into one cell of the table layout each. When someone now presses the subscribe button, we have to process SubscribeController::subscribeAction() as the activity on the portlet but also we need to stay on the index page, i.e. IndexController::indexAction() should be processed as we don't change the page but only invoked a particular portlet action. What I'm aiming at is that I would like to be more flexible, e.g. adding more portlets to a page (in this case, it could be a news portlet) or removing them (removing the subscribe portlet). What I'm worrying about is whether such behaviour could be implemented using the routing classes and the framework in general. Would you implement it like this or choose another approach? regards, Stephan
Re: [fw-general] Creating a portal-like site
Hi Stephan, I'm not sure I understand your question. Form actions would just be URLs like any other in your application. Say a user is at the application index, and logs in. A form action of '/user/login' would send form results to UserController::loginAction(). loginAction() would then parse the username and password and possibly redirect him to some other page (maybe back to the page he was on) using $this->_redirect(...). Does that help? -Matt On Sat, March 24, 2007 2:38 am, Stephan Stapel wrote: > Hi! > > I am currently considering to create a portal-like application using Zend > fw. > > I did a quick test (http://www.rehno.de) which works quite well: I used a > standard-router and a table based layout. In each cell, I rendered a > different 'portlet' using views. > > However, there's one issue that I'm worrying about: currently, I have > output-only views in each cell. The question is how to introduce > interaction. E.g. what if I have one form in one portlet and another form > in another portlet. In case of clicking a form button, the corresponding > controller function would have to be invoked. > How can I determine where to route these form actions? > > Did anyone do similar things or do you have recommendations on how to > implement such features? > > regs, > > Stephan
[fw-general] Creating a portal-like site
Hi! I am currently considering to create a portal-like application using Zend fw. I did a quick test (http://www.rehno.de) which works quite well: I used a standard-router and a table based layout. In each cell, I rendered a different 'portlet' using views. However, there's one issue that I'm worrying about: currently, I have output-only views in each cell. The question is how to introduce interaction. E.g. what if I have one form in one portlet and another form in another portlet. In case of clicking a form button, the corresponding controller function would have to be invoked. How can I determine where to route these form actions? Did anyone do similar things or do you have recommendations on how to implement such features? regs, Stephan
