I noticed during the studies of the source code that there is a class (DefaultAction.php) that use a smarty instance in order to assign strings to the variables in the template file.
Due to this dependence from Smarty it is very difficult to integrate OFB into existing frameworks (such as Prado) or using it together with other components (e.g. PEAR-components).
Therefore I would like to suggest an other approach:
Instead of using resource.<language>.properties files, one could use php files with php-constants in it. Then it wouldn't be necessary to use code fragments like
<code>
// get smarty instance
$smarty = $this->getSmarty();
In fact, you are right that business layer assumes that there is a Smarty on top as a presentation layer. I always liked the way how Smarty works and its approach to separate presentation layer for data and business layers In *.php files you won’t find anything which define how HTML should looks like, php files are responsible for preparing data. This is in my mind a good separation between different tiers. Please, let me know if I’m missing something.
Questionable might be if assumption that there is Smarty is correct ... Unfortunately, I don’t know Prado so I don’t know also what kind of problems can people encounter trying to integrate OFB with the framework. And why Smarty is a problem? Anyway, I would like to understand the problem then I’ll be able to help (redesign OFB if necessary) to facilitate the integration. I would be appreciate if you could you give me some examples how Smarty and properties file hamper integration. Then we can try to fix that :)
In terms of properties files, I think it shouldn’t be difficult to generate php files with constants in fly based on properties files if it will be helpful. What do you think?
Idea behind properties files is that there is no need to modify php files which might be scary for people not familiar with PHP or programming in general. I wanted to keep installation and configuration process as simple as it’s possible.
Thanks for you though-provoking suggestions :)
Cheers, Marek
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When I've tried to integrate OFB into the Prado framework, I noticed that OFB is designed as a standalone website, with its own authentication mechanism and its own index.php file.
That makes it difficult to use it within another template engine or web application.
In my opinion it would be great, if e.g. there were a toHtml() function in the Browser class. Then one could embed the OFB within other web applications.
(
* the addEventHandler() method is just my suggestion (see my E-Mail the day before yesterday)
* RessourceEnglishProperties could be a class with constants (as mentioned above)
)
That would make OFB more a component than a standalone web-page and it would be possible to integrate it into different Content Management Systems or Frameworks. Moreover one could extend the behaviour of Browser.php using your own EventHandler, config-classes (see RessourceEnglishProperties above), etc. and without the need of editing the config-files.
In terms of property files:
You are right, one could generate an array in fly, but that would make it necessary to read and parse the file what could decrease the performance of the whole application. But it would in fact require some knowledge in php. On the other side I believe that there are more advantages as drawbacks of such an approach (e.g. performance).
Thank you again.
Cheers, Mike.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I noticed during the studies of the source code that there is a class (DefaultAction.php) that use a smarty instance in order to assign strings to the variables in the template file.
Due to this dependence from Smarty it is very difficult to integrate OFB into existing frameworks (such as Prado) or using it together with other components (e.g. PEAR-components).
Therefore I would like to suggest an other approach:
Instead of using resource.<language>.properties files, one could use php files with php-constants in it. Then it wouldn't be necessary to use code fragments like
<code>
// get smarty instance
$smarty = $this->getSmarty();
$smarty->assign('labels', Browser_Utilities :: loadProperites("conf". Browser_Utilities :: getSeparator() .Browser_Utilities :: getValueFromConfiguration("resource.labels.file")));
//$this->smarty->debugging = true;
$smarty->display("main.tpl");
</code>
(see DefaultAction.php -> perform() )
that actually belong to the presentation tier within classes of the logic tier.
The advantage of this approach is a better separation between the different tiers.
Thanks again for the great work,
Mick.
Hello Mick,
In fact, you are right that business layer assumes that there is a Smarty on top as a presentation layer. I always liked the way how Smarty works and its approach to separate presentation layer for data and business layers In *.php files you won’t find anything which define how HTML should looks like, php files are responsible for preparing data. This is in my mind a good separation between different tiers. Please, let me know if I’m missing something.
Questionable might be if assumption that there is Smarty is correct ... Unfortunately, I don’t know Prado so I don’t know also what kind of problems can people encounter trying to integrate OFB with the framework. And why Smarty is a problem? Anyway, I would like to understand the problem then I’ll be able to help (redesign OFB if necessary) to facilitate the integration. I would be appreciate if you could you give me some examples how Smarty and properties file hamper integration. Then we can try to fix that :)
In terms of properties files, I think it shouldn’t be difficult to generate php files with constants in fly based on properties files if it will be helpful. What do you think?
Idea behind properties files is that there is no need to modify php files which might be scary for people not familiar with PHP or programming in general. I wanted to keep installation and configuration process as simple as it’s possible.
Thanks for you though-provoking suggestions :)
Cheers, Marek
Hello Marek,
First of all thank you for your reply.
When I've tried to integrate OFB into the Prado framework, I noticed that OFB is designed as a standalone website, with its own authentication mechanism and its own index.php file.
That makes it difficult to use it within another template engine or web application.
In my opinion it would be great, if e.g. there were a toHtml() function in the Browser class. Then one could embed the OFB within other web applications.
Example:
<template-file>
...
{php} $ofb = new Browser(); {/php}
{php} $ofb->setLanguage(new RessourceEnglishProperties()); {/php}
{php} $ofb->addEventHandler(new DefaultEventHandler()); {/php}
{php} $ofb->addEventHandler(new MyEventHandler()); {/php}
{php} $ofb->toHtml(); {/php}
...
</template-file>
(
* the addEventHandler() method is just my suggestion (see my E-Mail the day before yesterday)
* RessourceEnglishProperties could be a class with constants (as mentioned above)
)
That would make OFB more a component than a standalone web-page and it would be possible to integrate it into different Content Management Systems or Frameworks. Moreover one could extend the behaviour of Browser.php using your own EventHandler, config-classes (see RessourceEnglishProperties above), etc. and without the need of editing the config-files.
In terms of property files:
You are right, one could generate an array in fly, but that would make it necessary to read and parse the file what could decrease the performance of the whole application. But it would in fact require some knowledge in php. On the other side I believe that there are more advantages as drawbacks of such an approach (e.g. performance).
Thank you again.
Cheers, Mike.