The Basic File Structure
sf_root_dir # myproject/
# apps/
sf_app_dir # myapp/
sf_app_config_dir # config/
sf_app_i18n_dir # i18n/
sf_app_lib_dir # lib/
sf_app_module_dir # modules/
sf_app_template_dir # templates/
sf_bin_dir # batch/
# cache/
sf_base_cache_dir # myapp/
sf_cache_dir # prod/
sf_template_cache_dir # templates/
sf_i18n_cache_dir # i18n/
sf_config_cache_dir # config/
sf_test_cache_dir # test/
sf_module_cache_dir # modules/
sf_config_dir # config/
sf_data_dir # data/
sf_doc_dir # doc/
sf_lib_dir # lib/
sf_model_lib_dir # model/
sf_log_dir # log/
sf_test_dir # test/
sf_plugins_dir # plugins/
sf_web_dir # web/
sf_upload_dir # uploads/
// If you require a URL like http://myapp.example.com/article/21
// Use the following in article/read action
$uri = sfRouting::getInstance()->getCurrentInternalUri();
=> article/read?id=21
$uri = sfRouting::getInstance()->getCurrentInternalUri(true);
=> @article_by_id?id=21
$rule = sfRouting::getInstance()->getCurrentRouteName();
=> article_by_id
// If you just need the current module/action names,
// remember that they are actual request parameters
$module = $this->getRequestParameter('module');
$action = $this->getRequestParameter('action');
> Is it possible to access the current module name / action name inside the view?
$this->moduleName = $this->getModuleName();
$this->actionName = $this->getActionName();
<?php echo $moduleName ?>
<?php echo $actionName ?>
You find this info in part 6 : Inside the controller layer.
documented on: 21 August 2007, ubbels
Using the module / action name in the view
If you need to get module and action names outside of action:
$moduleName = $sf_context->getInstance()->getModuleName();
$actionName = $sf_context->getInstance()->getActionName();
documented on: 21 August 2007, pezetgee
> how I can call the link_to() function from a class within my model?
You can also load template helpers from scripts outside the view, like
inside actions, models or batch scripts.
Below, you see the loading of the Url helper, which you need to create links
with link_to().
sfLoader::loadHelpers('Url');
$sUrl = link_to('myLink', 'module/action');
How to call link_to from model
First, you have to load the helper -
sfLoader::loadHelpers('Link');
You should then be able to use it as normal.
documented on: 18 August 2007, bluesman
> Is there a possibility to forward or redirect in an action defined in
> components.class.php?
Nope. A component is called by an action, and only an action proper can do a
redirect. This limitation does make sense: if a component could do a
redirect it would interrupt the rendering of the template halfway through -
inefficient and inelegant.
As it happens, I've tackled this very problem recently. I've put my
component in a plugin, and in the plugin I also offer a static method to
capture POST events from the action. This looks a bit like this:
<?php
class MyPostHandler
{
public static function execute($action)
{
if (POST)
{
if (other tests)
{
$action->redirect(...);
}
}
}
}
?>
Then I do this in my action:
<?php
MyPostHandler::execute($this);
?>
documented on: 29 August 2007, halfer
I want to do several things after saving a record, eg.
-
update another table according to the latest update
-
send email notifications, etc
-
then redirect to another place
I've done the 1st step in actions/actions.class.php
then I realized that if I want to do them all, that's not the
best place.
What's the best place for such post processing?
what are the recommended approaches for above post processing?
apps/my_app/modules/my_mod/templates/saveSuccess.php
but it isn't used at all.
Post process after save
> I want to do several things after saving a record, eg.
>
> - update another table according to the latest update
> - send email notifications, etc
> - then redirect to another place
>
> What's the best place for such post processing?
documented on: 06 March 2007, sfxpt
Post process after save
Yes, I think you are right. If the update and email are to happen when a
particular table is saved, then you should extend the model. Redirections
however are, as you say, best executed from the action and not the model or
the template.
documented on: 06 March 2007, halfer
What are the advantages of keeping the back and frontends separate? So far
after looking through the old posts, I have gathered that most people keep
them together because this gets rid the problem of repeating code for
similar actions on both ends.
The only advantage that I see in keeping the two ends in separate
applications is that you can have a different layout and routing rules in
each, but the layout can be designated on a per module basis.
From the way it seems, the advantage of not needing to duplicate code far
outweighs the disadvantage of need to specify a layout in each module.
Could anyone list anymore pros and cons of keeping the front and backends
separate?
Pros and Cons of front- and backend in separate applications
9 times out of 10 I'll keep frontend and backend in separate apps. I like my
code clean and simple, and looking at an action file with a million methods
gives me a headache… same with the routing file— that can get pretty ugly
if you're explicitly naming all of your routes.
Another good reason is portability. If you decide later you want your
administrative functionality to live under a different domain name, it's a
cinch if that functionality has its own app.
Finally, I much prefer to assign credential requirements on a
module-by-module basis, rather than on an action-by-action basis. That gets
messy, and it's easy to forget to secure an action here or there, especially
if you've got a ton of them, and rename them, etc…
Also, I find that I very rarely duplicate any code between the two apps. If
you've got wicked long controller actions, that might be a sign that you
should leverage more functionality to your model.
documented on: 25 June 2007, east3rd
Pros and Cons of front- and backend in separate applications
I'd like to separate backend and frontend, too… but with the plugins I'd
very like to use (sfGuardPlugin, sfSimpleCMSPlugin, sfSimpleBlogPlugin), I
didn't find out how to separate the *Admin-Modules of the Plugins in an own
app.
Doesn't work this or do I have to add very much routes? Or is there an
"easy" way?
documented on: 22 August 2007, mix
Pros and Cons of front- and backend in separate applications
I wish both backend and frontend would be together.
For example, in my cms I want the backend to be able to access the routing
and the custom helpers that were build for frontend.
documented on: 22 August 2007, z01d
