I'm using codefluent entities and I was wondering if is possible set a localized label for the properties of a entity example I have a Test entity with a name and description field I want to set custom labels for example in english is name an description but in spanish I want to set nombre and descripción I searched in the documentation but I didn't find the option
CodeFluent Entities provides two ways to localized properties:
Static Resources
CodeFluent Entities handles static localization with the message concept. Static resources refer to all those UI messages that will never change throughout your application's life-time: labels, error messages, information messages, titles, button texts, tool tips, etc.
<cf:property name="Description">
<cf:message cultureName="en-US" value="Description EN"/>
<cf:message cultureName="fr-FR" value="Description FR"/>
</cf:property>
https://www.softfluent.com/documentation/Messages_Section.html
https://www.softfluent.com/documentation/BOM_LOC_StaticResources.html
Dynamic resources
CodeFluent Entities also handles dynamic localization out of the box. Dynamic resources refer to localized data created at runtime. For instance a web shop could have an international catalog in several languages, and this catalog should be displayed in a specific language depending on the users' language (i.e. culture in .Net). Administrators add, remove or modify items from this catalog during the application's life-time. Thus, administrators of the catalog will need to create catalog items with labels in several languages in order to support internationalization.
http://www.softfluent.com/documentation/BOM_LOC_DynamicResources.html
https://blog.codefluententities.com/2014/09/15/localize-dynamic-resources-using-aspect/
Related
I’ve developed a VSCode extension which supports Axibase Charts syntax, a domain-specific language. Typically a configuration will look something like this.
[series]
entity = entity-1
metric = metric-1
The extension contains several snippets which streamline the configuration process by eliminating the need for re-typing repetitive words.
Some users write configurations using databases other than ATSD (Axibase database) where entity and metric settings are replaced by table and attribute for example:
[series]
table = table-1
attribute = attribute-1
How can I provide two unique sets of snippets: One with metric and entity and another with table and attribute, based on the extension configuration?
We have a lots of Entity and we are trying to limit the number of SQL objects generated by CodeFluent Entity. We are using some lightViews but I have the feeling that a lot of generated views are useless.
Is it possible to decide Entity by entity to produce view or not ? (I'm aware of the produceViews option on the SQL producer but we still need some views)
No this is not an option. The produceViews attribute only related to persistent views explicitly defined in your model.
Now : if you are completely in control of what you can use, sure you are not referencing some default generated views in any model attribute, any methods (CFSQL or raw SQL), or partial code, then here some ideas :
You can choose not to use the default generated xx_views.sql :
- do not keep it in sourcecontrol
- provide your own views (the persistent known ones extraceted from the generated file) in a custom post SQL script after_[DefaultNamespace]_views.sql : in it you could for instance delete all existing views, then declare only the ones you want to use. It would be a manual step that can be time consuming if your persistent views are changing a lot between versions. May be a good name convention for persistent views will help this manual report for a good enough solution.
Another more advanced and cleaner idea would be to provide a custom aspect removing the "default" view created for each entity in the meta model before production (see infered meta model and CodeFluent.Model.Entity class), except for entities marked with a custom attribute. This is an idea not guaranted/tested.
I have to migrate my custom system to typo3 version 6.2 but I did not find any database diagram(design/schema) of typo3. Would be great if someone can help. Thank you.
In a TYPO3 installation without extensions, there are not many tables that will interest you. Interesting tables are
pages and pages_language_overlay: Pages and their translations.
tt_content: Content, translations are in the same table.
sys_language: Define available languages. For pages with only a default language it can stay empty.
sys_domain: Define Domains under which a site is available. For single domain installations it can be left empty.
sys_file_reference: References to files, which are stored in table sys_files. The table sys_files will be automatically filled when you put files into the fileadmin folder.
fe_users and fe_groups: Frontend users and groups.
The other tables are either caching tables (names start with cf_) or are mostly used internally (most tables having names starting with sys_).
In some of the tables, especially in pages and tt_content, there are deprecated fields.
The usage of some fields depends on the actual TYPO3 setup. For example, the text of a content element from tt_content could be stored in the field bodytext, or in the field pi_flexform. So the question how to import your data depends on your setup.
For further information have a look at the official docs: https://docs.typo3.org/typo3cms/CoreApiReference/latest/ApiOverview/Database/DatabaseStructure/Index.html
I don't have a diagram either, but this note is too long for a comment:
Most M:N relationships (e.g. users & groups) are handled with foreign key attributes stored as comma-separated entries inside table cells, inside rows of the parent table. Of course, this nonatomic way of storing data violates first-normal form of database-table design.
However, some newer extensions do rely on bridge tables. In typo3, this is called an M:M relation, and some tables have a naming corresponding convention, e.g. tt_news_cat_mm, linking news-messages with news-categories.
How to store only metadata for an object of type sys:base or cm:object? I have a type which is sub-type of sys:base. I need to store the metadata of it.
My doubts are:
1. Where should the data be stored?
How to retrieve the data, as in content and folder you can see the appearance as icon in the company home or user home etc. How does the metadata appear in a folder(is it like an icon of cm:object)?
With reference to the question posted earlier in alfresco forum (http://forums.alfresco.com/forum/developer-discussions/content-modeling/can-i-store-only-metadata-alfresco-11292012-0437) should the object be of type cm:content to store the metadata (except that they do not have a content property). Is there anyway to create metadata other than being subtype of cm:content?
Thank you
You can store metadata on instances of any type as long as the content model includes properties that meet your needs. Those might be out-of-the-box types or they might be custom types.
If you need to create objects that have a content stream, use cm:content. If you don't need to set a content stream you might consider using one of the two types you mentioned. But it won't necessarily hurt anything if you elect to simply create instances of cm:content that don't have a content stream.
If you want to use sys:base or cm:object, simply create an instance of either of those types. Alternatively, define your own sub-type of those types then instantiate that custom type and set your metadata.
If you don't know how to define custom types or you are unsure about how to set, update, or query metadata, you could start by reading this tutorial.
Also note that if you create instances of any type other than cm:content, cm:folder, or a custom type that inherits from one of those two types, you will be unable to do that using CMIS. That isn't the end of the world, just be aware that it is currently a limitation. Someday Alfresco will support the "item" type which is new in CMIS 1.1, but until then, CMIS in Alfresco can only work with documents, folders, and your custom types that inherit from those types.
I would like to experimentally apply an aspect of encapsulation that I read about once, where an entity object includes domains for its attributes, e.g. for its CostCentre property, it contains the list of valid cost centres. This way, when I open an edit form for an Extension, I only need pass the form one Extension object, where I normally access a CostCentre object when initialising the form.
This also applies where I have a list of Extensions bound to a grid (telerik RadGrid), and I handle an edit command on the grid. I want to create an edit form and pass it an Extension object, where now I pass the edit form an ExtensionID and create my object in the form.
What I'm actually asking here is for pointers to guidance on doing this this way, or the 'proper' way of achieving something similar to what I have described here.
It would depend on your data source. If you are retrieving the list of Cost Centers from a database, that would be one approach. If it's a short list of predetermined values (like Yes/No/Maybe So) then property attributes might do the trick. If it needs to be more configurable per-environment, then IoC or the Provider pattern would be the best choice.
I think your problem is similar to a custom ad-hoc search page we did on a previous project. We decorated our entity classes and properties with attributes that contained some predetermined 'pointers' to the lookup value methods, and their relationships. Then we created a single custom UI control (like your edit page described in your post) which used these attributes to generate the drop down and auto-completion text box lists by dynamically generating a LINQ expression, then executing it at run-time based on whatever the user was doing.
This was accomplished with basically three moving parts: A) the attributes on the data access objects B) the 'attribute facade' methods at the middle-tier compiling and generation dynamic LINQ expressions and C) the custom UI control that called our middle-tier service methods.
Sometimes plans like these backfire, but in our case it worked great. Decorating our objects with attributes, then creating a single path of logic gave us just enough power to do what we needed to do while minimizing the amount of code required, and completely eliminated any boilerplate. However, this approach was not very configurable. By compiling these attributes into the code, we tightly coupled our application to the datasource. On this particular project it wasn't a big deal because it was a clients internal system and it fit the project timeline. However, on a "real product" implementing the logic with the Provider pattern or using something like the Castle Projects IoC would have allowed us the same power with a great deal more configurability. The downside of this is there is more to manage, and more that can go wrong with deployments, etc.