Where can I store app wide error messages or static strings?
Currently I'm using Providers. Does we have any better way of doing this?
Exporting one class for storing all your constants would definitely be an option I'd say.
However in case your speaking of error messages or generally text being rendered and displayed in your app, ng2-translate would be an option. Even when you're not planning to publish your app for different languages, ng2-translate has several advantages, as you can store text for different parts of your app in different json files, allowing you to easily structure your text constants.
Also you do not need to load all your translations at once but have the possibility to require them when you really need them - so load the texts when you navigate to a particular route in your app instead of loading all of it on startup.
However - I'm assuming here, that you're speaking of messages or page content and not string constants you're using programmatically somewhere. In this case I'd say stick to your initial approach and export a class containing your constants to keep them in one place:
export class AppConstants {
public static get API_ENDPOINT(): string
{
return 'http://some.url/api/';
}
}
Related
Now I have some experience in using the Zend Framework. I want to go deeper in the topic and rewrite some old php projects.
What is the best place to save own functions and classes?
And how do I tell Zend where they are? Or is there already a folder for own stuff? May I have different folders for different files?
For example I want to save a php document with the name math_b.php which includes several special functions to calculate and another one date_b.php which has abilities for datetime stuff. Is that possible or shall I have different files for every function?
I would also like to reuse the functions in other projects and then just copy the folders.
There is no single "right" answer for this. However, there are several general guidelines/principles that I commonly employ.
Do not pollute global scope
Namespace your code and keep all functions is classes. So, rather than:
function myFunction($x) {
// do stuff with $x and return a value
}
I would have:
namespace MyVendorName\SomeComponent;
class SomeUtils
{
public static function myFunction($x)
{
// do stuff with $x and return a value
}
}
Usage is then:
use MyVendorName\SomeComponent\SomeUtils;
$val = SomeUtils::myFunction($x);
Why bother with all this? Without this kind of namespacing, as you bring more code into your projects from other sources - and as you share/publish your code for others to consume in their projects - you will eventually encounter name conflicts between their functions/variables and yours. Good fences make good neighbors.
Use an autoloader
The old days of having tons of:
require '/path/to/class.php';
in your consumer code are long gone. A better approach is to tell PHP - typically during some bootstrap process - where to find the class MyVendor\MyComponent\MyClass. This process is called autoloading.
Most code these days conforms to the PSR-0/PSR-4 standard that maps name-spaced classnames to file-paths relative to a file root.
In ZF1, one typically adds the ./library folder to the PHP include_path in ./public/index.php and then add your vendor namespace into the autoloaderNameSpaces array in ./application/config.ini:
autoloaderNameSpaces[] = 'MyVendor';
and places a class like MyVendor\MyComponent\MyClass in the file:
./library/MyVendor/MyComponent/MyClass.php
You can then reference a class of the form MyVendor\MyComponent\MyClass simply with:
// At top of consuming file
use MyVendor\MyComponent\MyClass;
// In the consuming page/script/class.
$instance = new MyClass(); // instantiation
$val = MyClass::myStaticMethod(); // static method call
Determine the scope of usage
If I have functionality is required only for a particular class, then I keep that function as a method (or a collection of methods) in the class in which it is used.
If I have some functionality that will be consumed in multiple places in a single project, then I might break it out into a single class in my own library namespace, perhaps MyVendor.
If I think that a function/class will be consumed by multiple projects, then I break it out into its own project with its own repo (on Github, for example), make it accessible via Composer, optimally registering it with Packagist, and pay close attention to semantic versioning so that consumers of my package receive a stable and predictable product.
Copying folders from one project into another is do-able, of course, but it often runs into problems as you fix bugs, add functionality, and (sometimes) break backward-compatibility. That's why it is usually preferable to have those functions/classes in a separate, semantically-versioned project that serves as a single source-of-truth for that code.
Conclusion
Breaking functionality out into separate, namespaced classes that are autoloaded in a standard way gives plenty of "space" in which to develop custom functionality that is more easily consumed, more easily re-used, and more easily tested (a large topic for another time).
I'm trying to use layers to make sure I separate everything into it's correct areas in my Swift / iOS / Xcode 6 project. The question, ultimately, is: is it OK / a common practice to move commonly used presentation-level logic to a separate presentation helper class instead of writing it over and over in multiple view controllers with little or no difference?
Here is an example to tie this in and give context:
One of the things I am aiming to do is use a UITableView to display report data. This UITableView will contain 7-10 rows, depending upon the user's preferences (nsuserdefaults). Each row contains a localized string for a label, and some decimal value.
As an example one row could be "Sales made this week: $500.00"
I have a reporting service class that's responsible for talking to the database and getting back / instantiating a report object. This report object contains the raw data for the report, i.e. how much you made this week, this month, this year, etc. Whether the user wants to show all these values or not is irrelevant to the service - it simply gets everything.
So since I have 3 view models that use this same report, I thought it would be wrong to rewrite the same code each time that checks the user's preferences, then creates/binds an array to the UITable and matches the labels with the report values from the object returned by the service.
A better way, I thought, was to create a presentation-level helper class whose job would be to take a report object (the thing I mentioned before that contains the report values), take a user's preferences, and then more generically combine them to create a list of localized strings matched with their respective report values, agnostic to what the view controller wants. Maybe if that requirement changes later (where different view controllers need more customization) I could use flags or different function names within that class.
This way all I have to do is something like
var report = ReportHelper.GenerateReport(reportData, userSettings)
and now report would be an object that could look like this (mock JSON data):
{"Amount made this week":"$100", "Amount made this month":"$500", "Amount made this year": "$10,000"}
And I can use this in any view controller.
The alternate is to just hard code those above values (obviously still pulling localized strings) but I don't know if I adding all those strings + checks based on user preferences + formatting. Seems more elegant to move it away.
Thanks!
I know too little about your problem to provide the definite answer, but basically you have 2 options:
- inheritance
- composition
I personally like inheritance although it is often stated you should choose composition over inheritance.
Your helper sounds somewhat like composition, so that would be the preferred setup. With your specific problem as I understand it, inheritance would lead to a duplication of data, so that is one more argument to choose composition.
So all in all you seem to be about right
Edit:
Inheritance is an "is" relationship, whereas composition is a "has" relationship.
See http://en.wikipedia.org/wiki/Object_composition for more details about composition.
And see http://en.wikipedia.org/wiki/Composition_over_inheritance for more info why and when to choose composition
II want to share data between Activities (which are my presenters) without passing the data with the Place. How can I do that?
If the data really isn't all that large I'd try and encode it in the Place: then your users can bookmark/distribute URLs that lead right into the guts of the application (link to a specific product, search filter, etc).
Quite some ways. A simple way is -
you could create a public static field in some class and use that in all of your presenters . (This method obviously has strings attached and must be used carefully)
Jai
I'm looking for an elegant solution for the following problem:
In my database, I have some predefined(!) entities. These entities have names and descriptions (Strings). Around the data access layer, there are some EJBs containing business logic to load/search for/etc. those entities.
Now for the frontend, we are developing a GWT application which calls the EJB methods on our backend.
The problem is, that the name and the descriptions of the entities mentioned above must be internationalized - e.g., depending on the user's locale, an entity's description must be "My cool description" (English) or "Beschreibung bla" (German) or whatever :)
My first approach was to use a resource string in the database. So entity A has a description "descriptionA", entity B has a description "descriptionB"... Later on, the GWT app (or any other client) translates this resource string into the actual description using some kind of "resource bundle". E.g.:
*resources_en.properties*:
descriptionA=Actual Description of Entity A
descriptionB=Actual Description of Entity B
*resources_de.properties*:
descriptionA=Beschreibung A
descriptionB=Beschreibung B
(Remember, the entities are predefined, so it's possible to "know" all descriptions at compile time. BUT it would be better if the resource bundle could be enhanced without having to recompile the application).
Is this possible with GWT? How can I do this? Is it better to "translate" on the server or on the client side?
Otherwise, I've to deal with all that i18n stuff on the backend side. Well, this would allow to keep data together (instead of defining the descriptions on the client side). But the big drawback is that the backend must be aware of the caller's locale.
Regards,
Frank
It's mainly a decision between download time/speed vs flexibility. If you compile it GWT inlines the messages and can generate a little faster code, because no string lookup has to be done. However, if you need to make changes and don't want to recompile or want to be a able to let users dynamically alter messages you need dynamic messages.
Regarding the latter case, the Dictionary class can help you with this, see also: http://code.google.com/webtoolkit/doc/latest/DevGuideI18n.html#DevGuideDynamicStringInternationalization
With the Dictionary you generate all messages in the static page served to the user. The users locale can be found in the header Accept-Language, which is send by the browser when a page is requested.
In either case (compiled or dynamic) you might want to serve the locale set by the user in some configuration property and in that case you still need logic for both cases on the server side to serve the locale to the user.
Everything is possible for those who try...
Back to your question: there are several ways to resolve your issue. One would be to introduce some kind of i18n facade and treat your descriptions and names as resource keys. Then you could define convenience methods to access translations i.e. public String translate(String message, Locale locale);. This method could use standard Java ResourceBundle class to access resources at runtime.
The only real problem I see is how to deal with compound messages (i.e. "Blah, blah 4 items" where 4 is a placeholder). Well, what we did in one project in similar situation, we added delimiter and actual resource key then another delimiter and count: "Blah, blah 4 items##items.in.your.whatever##4". In the case of English you could simply trim the first part and for other languages you would need to process whole string.
I'm currently making good use of GWT's ClientBundles in my app. It works fine, but I have a large number of resources and it becomes tedious to manually create Java interfaces for each file:
#ClientBundle.Source("world_war_ii.txt")
public ExternalTextResource worldWarII();
#ClientBundle.Source("spain.txt")
public ExternalTextResource spain();
#ClientBundle.Source("france.txt")
public ExternalTextResource france();
I'd like to be able to (perhaps at compile time) dynamically list every *.txt file in a given directory, and then have run-time access to them, perhaps as an array ExternalTextResource[], rather than having to explicitly list them in my code. There may be hundreds of such resources, and enumerating them manually as code would be very painful and unmaintainable.
The ClientBundle documentation explicitly says that "to provide a file-system abstraction" is a non-goal, so unfortunately this seems to disallow what I'm trying to do.
What's the best way to deal with a large number of external resources that must be available at run-time? Would a generator help?
There's an automatic generator for CssResource - maybe you could look at its code and modify it to your needs?
I ended up following this advice: perform the file operations on the server, and then return a list of the file (meta)data via an RPC call.
This turns out to be fairly simple, and also allows me to return lightweight references (filenames) in the list, which I use to populate a Tree client-side; when the user clicks on a TreeItem the actual text contents are downloaded.