First of all i am very new to Symfony 2 and started to learn.
Is there any possibility for filter a value? Perhaps filter chains too?
I know this concept from Zend Framework 1 and 2.
E.g.:
i have a string "1A- N "
now i want to filter so that only numeric values pass; result "1"
Do i have to implement this on my own i Symfony?
I would like to do something like:
$text = '1A - N';
$numberFilter = new NumberFilter();
$filteredText = $numberFilter->filter($text);
//now in $text i find '1'
But for now i nowhere found something like this in Symfony what surprises me a lot. I thought it is a full stack framework and such function is so basic.
I found something like validators but they only say if a value e.g. contains only numbers or not. Or is the validation concept of symfony like that it does not only say if it is numeric or not but filter all other smybols out, too?
Depending on what you want precisely:
disallow user input not fulfilling certain rules
use validators in forms
use asserts in entities
chenge user input in case it's wrong
use viewransformers in forms
use event listeners in forms
use event listeners for doctrine
change data that already exists in the database
use filters in twig
create a command to execute from commandline
You can also try http://php.net/manual/ro/filter.filters.sanitize.php
I have built quite big apps with Symfony and never needed such a feature. Filters are mostly used in views anyway. Symfony comes with Twig, which has filters, that can be chained, and you can write your own filters. But if you need filters in the backend to do some background processing, you can accomplish it the way you suggested.
I suggest you write an interface and use a factory pattern, so you set a standard if you make many filters, so it will be easier to make the chaining work;)
After the answers and searching i got to the following conclusion.
There is no concept for this for now in Symphony 2.
You have to write it on your own.
I've started a Symfony2 project from scratch where I then installed FOSUserBundle.
Then, I have written (actually, generated with ORM Designer) some entities that need to have relations between them, and with the User entity.
I have Items belonging to Users, Collections belonging to Users that group Items, and so on.
Since I used FOSUserBundle I only have a basic User class (https://github.com/FriendsOfSymfony/FOSUserBundle/blob/master/Resources/doc/index.md , step 3a) defined using annotations, no config/doctrine folder and no User.yml file in it.
I then created the MyBundle/Resources/config/doctrine folder and added the yml files mentioned above.
When I try to generate the entities with the command-line tool everything works fine: it will create the Entities from my yml files.
However, at this point, trying to load up in browsers the url where the login previously worked (when I only had the FOSUserBundle installed) will throw this error:
MappingException: No mapping file found named
'/var/www/concert/src/X/MyBundle/Resources/config/doctrine/User.orm.yml'
for class 'X\MyBundle\Entity\User'.
Following actions, such as generating the CRUD logic, will not work as long as I have an *.orm.yml file in the config/doctrine folder. If I remove those, CRUD generation will work, but generation of actual mysql tables won't.
Juggling with these gets me to a point where I can also get the tables, but then the actual app doesn't work if I try to use any of the url's where the newly generated CRUD is involved because since the entities are based on yml (which I remove to get things "working") it won't have any mapping knowledge.
Is this inherently wrong? To have yml-based entities in relationship with an User entity based on the FOSUserBundle and still be able to get the nice command-line generation tools?
The problem you describe stems from mixing configuration formats (yaml and I assume annotations). You can easily fix this by ditching the annotations in your models and replacing them with yaml-files like you would do in your own models.
Unfortunately the FOSUserBundle-docs only show you how to use annotations, so here is a quick transformation into yaml format when your X\MyBundle\Entity\User extends FOSUSerBundle's UserEntity:
X\MyBundle\Entity\User:
type: entity
table: fos_user
id:
id:
type: integer
strategy: { generator: "AUTO" }
The remaining stuff is taken care of by FOSUserBundle, as the BaseModel is a mapped-superclass and already describes the stuff in the User.orm.xml, but you could just as well replace the existing values or add additional values just like you would do with your own models.
If you don't use annotations throughout your app, you might also want to disable them in your app/config/config.yml to prevent side effects.
I'm trying to create a join across multiple databases (one of them belonging to a legacy application) as described in the Doctrine blog. However, the example suggests hardcoding the name of the database right into the schema, which I'd like to avoid for obvious reasons.
Is there a way to read parameters defined in parameters.ini or config.yml and use them as a value for the annotations, like this?
/**
* #ORM\Table(name="%legacy_db_name%.%legacy_table_name%")
*/
No, it's impossible. The "%key%" form is only available in the DIC.
Why would you put these data in a yml file? Would it be useful?
I need to access data from pre-existing tables. I've started working my way through creating a module to display the data etc. However, Orchard is prefixing the table commands with the 'Table_Prefix' and 'Module Name'.
Is there any way I can specify what table to bind the model, so that I can use the existing IRepository
I'm trying to steer clear of modifying the core code, or implement my own IRepository ( which I've got a feeling is what I'm going to have to do.)
Thanks in advance.
You can create custom table naming convention (so that it would fit your current naming) by altering the core code, in three ways:
Record name mapping is created in BuildRecord method of
CompositionStrategy class
(Orchard.Framework/Environment/ShellBuilders/CompositionStrategy), so you can simply modify the code here.
By altering the Apply method of Orchard.Data.Conventions.RecordTableNameConvention class. This is where the record table name mappings (built in point 1.) get pushed to NHibernate.
Create your own implementation of FluentNHibernate.Conventions.IClassConvention (similar to RecordTableNameConvention mentioned above and replace the default one used by AutoMap in Orchard.Data.Providers.AbstractDataServicesProvider's CreatePersistenceModel(...) method with it.
You could also create your own IDataServicesProvider implementation, but that would surely be an overkill if you only need to change the table naming convention.
I was modifying CompositionStrategy and discovered that you have to modify the following
1. SetupService.cs (Modules\Orchard.Setup\Services):
Tables hardcoded in the Setup method are
"Orchard_Framework_DataMigrationRecord" and
"Settings_ShellDescriptorRecord"
2. InfosetController.cs (Modules\Upgrade\Controllers):
Multiple tables were hardcoded in this class which need to be updated.
3. DataMigrationManager.cs (Data\Migration):
Replace the SchemaBuilder parameters to the contructor.
Recently, I discovered that the "Web.Config" file contains an <appSettings> section which seemed good for storing one's Application Settings. Heck, it even has a programmatic way to access the file thru a standard System library. So being all clever, I wrote an Interface to access it and then a Concrete implementation of the interface, shown here:
public interface IAppSettings
{
IEnumerable<string> GetValues(string componentName, string settingName);
IEnumerable<KeyValuePair<string, string>> GetValuePairs(string componentName, string settingName);
void SetValues(string componentName, string settingName, IEnumerable<string> valueList, bool append);
void SetValuePairs(string componentName, string settingName, IEnumerable<KeyValuePair<string, string>> pairList, bool append);
}
Then I came to discover that saving settings back to "web.config" while the application is running causes the entire application to re-start. This seems completely unreasonable to me because if I'm writing back to web.config a lot and the application is restarting each time, then things like HttpRuntime.Cache get completely emptied effectively making my Cache useless because it's constantly emptying and repopulating.
So I'm wondering: Where should I store my Application Settings?
Is there a good solution out there for this so that I don't have to roll my own?
EDIT:
Okay, thanks to everyone who suggested using a DB and a potential table schema. I think I'm going to go with the following schema:
settings:
index NUMBER NOT NULL AUTO_INCREMENT <== Primary Key
component NVARCHAR(255) NOT NULL
setting NVARCHAR(255) NOT NULL
key NVARCHAR(255)
value NVARCHAR(255) NOT NULL
Though I don't think I'll make the "setting" the P-Key, but use an Auto-Incr Index instead. This way if I have an application that needs to mail something to multiple managers, I can store many:
index component setting value
1 RequestModule ManagerEmail manager1#someplace
2 RequestModule ManagerEmail manager2#someplace
And then I can use:
IEnumerable<string> GetValues(string componentName, string settingName);
And it will return a list of email addresses, rather than just a single value.
Does this make sense?
web.config is generally used for read-only settings, ie. the settings set during deployment of the application by the system administrator.
If you want to read and write the settings, the most obvious way is to use the database. By the way, this has an advantage: an application can be hosted on several servers and will still read and write the settings correctly,
You can also implement your custom storage for the settings, but it will be probably more difficult to implement and not much faster.
To answer your second question, the structure of your database depends on the type of settings you want to store.
If you need to store heterogeneous unique entries like this:
Mail address of an administrator,
Maximum number of entries to display on home page of the website,
Text to display on "About us" page,
Boolean value indicating whether public comments are enabled or not,
then you have to use varchars or other more or less friendly types as keys to identify the entries (rather than to refer to them by their index).
On the other hand, if your purpose is to store the mail addresses of several managers, you should create a Manager table containing their mail addresses, names, datetime of their last connection, etc.
You really shouldn't mix both. In theory, you can refer to the entry in settings by component/setting pair. In practice, it makes things harder and creates a bunch of problems:
What if, further, you will need, for every manager, to store a boolean value indicating whether she/he wants to receive alerts from you? With your current structure, this will be impossible.
Since the same setting can have multiple values, how do you intend to handle the settings which must be unique? For example, there must be only a single value of text to display on "About us" page. What if there are two values stored in database?
Storing settings in web.config is useful because it makes it easy to have different settings in different environments. However, as you say, this is no use if you are likely to want to change the settings in a live environment.
A simple database table is the most useful way to do this if you need to change the values.
eg.
create table Settings
(Name varchar(50) primary key,
Value varchar(50))
If you're using SQL Server, you can set to the Value column to be sql_variant which will allow you to store a variety of datatypes.
It is meant for application settings, but not settings that are meant to be dynamically changed during runtime. Rather, it is for settings that change only occasionally, and where you would expect (and even desire) an app restart when they change.
For more ephemeral settings, you may want to just use a simple database system - even a flat file/XML in the App_Data dir can work, if your app doesn't use a database otherwise.
Yes.Changing the web.config will reset the application.I usually maintain a settings table to store key-value pairs for the settings and access it from there.
SETTINGS
SETTING_NAME VARCHAR(100)PRIMARY KEY
SETTING_VALUE VARCHAR(100)
Then write a class which can Insert,Delete,Update values to this table.
Ex Data for the SETTINGS table
SETTING_NAME SETTING_VALUE
AdminEmail admin#mysite.com
ErrorTrackingEmail errors#mysite.com
I usually add a "type" field to my settings table so that I only retrieve the group of settings needed this works for me as a way of grouping like settings and retrieving them at once.
Create a key-valued table like this:
settings:
name NVARCHAR(255) PRIMARY KEY
value NVARCHAR(255) NOT NULL
First of all, it's not unreasonable at all when you consider what information is supposed to be stored in the web.config file. When you change things like assembly information, connection strings, etc., your application needs to stop and reload the values to run with those settings.
If you're storing application wide settings, then you can create a Settings table in your database or even use a separate text file to store the settings.
If you're talking about storing per-user settings, you shoul check out ASP.NET Profile Properties.
Application-wide settings should certainly be stored in this section of the web.config file, as it prevents hard-coding values which may change over time. There's no need to read them out using your own code, as there's a built-in method: use the System.Configuration.ConfigurationManager.AppSettings array to retrieve them (you'll need to add a reference to the System.Configuration assembly in your project). You can edit AppSettings through the ASP.NET Web Site Administration Tool, too (Project menu -> ASP.NET Configuration).
For values which you envisage changing more often and while the site is up and running, it's reasonable to use an XML file, lightweight database (such as SQLite or SQL Server Compact) or even a text file for these settings.
If you need to save settings, you can always save them in a custom configuration file.
I did just that a while back, and I have the code available to do it here.