I am wondering what is the best way to store a list of entities in Umbraco.
Say, I have a page that list a bunch of contact information (name, company address, phone number, etc...). I want a web administrator to be able to easily create and edit them inside Umbraco.
Should I be creating a new Data Type call Contact. And have those properties in that Data Type?
If so, is this a good practice? I always think each node in Umbraco is suppose to be a page.
If not, what other options do I have?
Thank you,
Chi
Each node in Umbraco does not necessarily have to be a page. You can have child nodes (not pages) which constitute a list to be displayed on their parent node (a page).
For example: you could have a document type called ContactList. The corresponding template will look for all child nodes having the document type Contact and list them. The Contact document type has all the properties you need for a contact. You do not need to assign a template to the Contact document type (or a NullTemplate, displaying nothing).
Advantages of using nodes for each contact:
The user can use the publishing features of content nodes
The user can manipulate the sort order within Umbraco as with any node
The data of each Contact is stored in the umbraco.config and can be interrogated like any property of any node (xslt, razor).
Of course, there are limits. For example, if you have more than 40-50 contacts, this will be difficult to use. Or if you have to regularly import or synchronize contacts, some additional programming effort will be required.
Today the best way to store list of entities which will not have pages is Archetype. It's an Umbraco 7 property editor that wraps other installed property editors. By wrapping the other properties, Archetype allows for custom and repeatable fieldset mashups. Archetype documentation - https://github.com/kgiszewski/ArchetypeManual
Related
I am making a user form in Delphi for documents tracking application. I am interested in functionalities input new entry (record) and view list by... (date, name of document, ID,...).
My problem is that I don't know how to implement these functionalities for more than one user. Currently, I have 5 users. Each user has a unique input data (record) fields (columns) and view fields (columns) of each user are also unique. There could be more users.
So, how to implement these functionalities for this form? How to assign different data (fields) for each separate user for input and view? That is what I don't understand. Is that distributed functionality of an application? If yes, how to achieve it?
Note that I don't want static assigning of a user in application's code, e.g:
if(username='user1') then {
input();
view();
}
else if (username='user2') then {...}
...
because, than, every time there is a new user, developer must go back to the application's code and hard-code it. That is not efficient and is a bad implementation. Rather, I want that to be dynamic (if that is the right term). How to achieve this?
Note: I am using dbExpress tool with MySQL DBMS with RAD Studio XE7 Architect.
If I'm correctly understanding what you are asking, it seems as if you are unfamiliar with the idea of tables/datasets which operate in a so-called Master-Detail relationship. These are very easy to set up in Delphi.
Once you get familar with M->D relationships, I think you'll realise that what you should have been asking about is how to set one up in your app, rather than the problem of hard-coding of individual users into your form.
In your case, what you are missing at the moment is a table of users' details. Let's call that the Users table. Usually this would contain their name, obviously, and some kind of unique identifier (best is a "Primary key" in the Users database table), but NOT, please, their password to access the db, especially not in plain text.
Once your Users table is created, you can create a display grid (TDBGrid) and input/editing form for it.
Then, if you don't have it already, you could set up a grid and editing form for users' documents (which I'm going to refer to as the Documents table).
Once that's done, the main thing left to do is to set up in your Delphi project a Master-Detail relationship between your Users table (the master) and your Documents table (the detail).
If you prefer you can have a single form with two grids, the Users grid and the Documents grid on it, and as you scroll through the Users grid, you'll see that the Documents grid shows only their document records.
The details of how to set up a Master-Detail vary somewhat according to the type of table/dataset you're using so you'll need to search online for the details of how to do it. Broadly, it's a matter of connecting a TDataSource to your Users table and setting the DataSource (or MasterSource) property of your Documents table to point at the Users TDataSource, and then setting a couple of other, table-type-dependent properties of the Documents table.
Every edition of Delphi since well before D7 has come with a demo app, "MastApp" which illustrates how you use Master-Detail relationship amongst a number of tables. I suggest you take a look at the MastApp for your Delphi version and then look into how to set up M->D relationships for the type of Delphi dataset you are actually using.
I know that I can implement an interface when defining an Entity, but I want to be able to treat all implementations of this interface as if they had a shared table, with a common Repository. To better illustrate my problem, here a two examples:
GitHub repository owners
On GitHub both users and organizations can own repositories. Let's imagine there is a User and an Organization entity. They both implement the RepositoryOwner interface that specifies stuff like an array of Repository's as a relation.
Now take a look at GitHub's "Trending developers" page. It treats User's and Organization's equally as if there was a common Repository<RepositoryOwner> that could be used to fetch the data.
Resource sharing site
A site where users can upload different types of resources like images, videos and documents. All of these types have their own Entity with different properties, but all of them implement the Resource interface. On a user's profile page there's a list of all the resources uploaded by this user. A Repository<Resource> would be very helpful again, the type of a resource is determined using typeof and displayed using an icon.
I'm assuming that you intend to share a common table from which you want to derive two more tables? In that case you can define an interface IRepositoryOwner and implement it in a base entity RepositoryOwner. And then extend RepositoryOwner to Organization and User entities.
This would allow you to retrieve an array of RepositoryOwners but repositoryOwner instanceof User would be false. And casting repositoryOwner to User would not be possible. You'd be missing the derived class properties.
I'm a new comer to Microsoft Dynamics CRM 2013 and I've self-learned in high-level to customise the CRM.
I have created a custom entity called "Project" which have two 1:N relationships to Accounts and Contacts. In create form for Project, instead of having two sub-grids for accounts and contacts can I create a single sub-grid which can have accounts and contacts as a single list? And also the user need to be able to add an account or a contact to the list as well.
Thanks.
It is not possible to create a sub-grid that contains different type of records (in your case accounts and contacts).
You still need to use 2 sub-grids.
Guido is right. OOB no. I guess with a little stretch of imagination and little pixie dust you can. So what you need is a) Custom Entity called Project_Accounts_Contacts. Add 3 lookup fields to this entity 1) Project(Required) 2) Account (optional and c)Contact (Optional). This entity is maintained for creating this single list only at any given time. You will have to have workflows that takes care adding and removing Accounts and Contacts to this entity. Create subGrid based on this entity and you have a single list of Accounts and Contacts. You can do some realy fancy stuff with manipulating the FetchXML of the view used for this SubGrid. If this is what the customers want, this one way of accomplishing a composite subgrid.
Good luck.
I'm trying to design a scheme for event logs, which record page view flow on webpages, using Neo4j.
I'm interested in finding page view flows to a certain collection of pages (URLs). I'm thinking defining nodes as page view events and important properties include user id, timestamp, etc. The only relationship between nodes is visit.
I'm completely new to Neo4j. So is this design reasonable?
If the properties are recurring, I would model them as nodes, too. You could even look at things like http://datablend.be/?p=1516 for inspiration.
I need to generate a user interface for entering a sales document (eg invoice). I'm trying to use components of "developer express" specifically the QuantumGrid component (TcxGrid). I've seen the demos of master-detail components and search in the devexpress support center, but none has helped me because all use 2 grids to handle the master-detail relation, and edit multiple records at once.
I just need to edit a record (document) at a time and using a pair of objects dataware components (eg TDBEdit) in the header and a grid to handle the detail.
something like this
Where can I find a basic example of using these components in this way?
Tthe Master/Child properties in the QuantumGrid are mainly designed to nest multiple items in the grid. If you setup the relationship in the data components you can simply hook the controls up to the correct DataSource and everything will work.
So if you have two DataSets Customer and Invoice. The Invoice Master Datasource is the Customer DataSource. Then on your edit controls you point to the Customer DataSource and you point the Grid to the Invoice DataSource.
If you think about what the Master/Detail relationship is doing it really just filters the records on the Detail DataSet to match the current record on the Master DataSet. Individual Edit controls will always display the "current" record in the DataSet they are connected to. Grids will show all visible records in the DataSet they are connected to.
I have a tendency to not use Master/Detail relationships in an edit form like you show here. I'm assuming there is some way on a different screen to pick the invoice to edit. I usually create a copy of the needed DataSets with only the records needed for this edit. If I am editing a existing invoice I copy the current records. If it is a new invoice I can start off with an empty recordset. It is more work - I have some generic library functions that will copy a DataSet Structure and then copy one or more records into that Dataset. Depending on your setup you can also requery your Database to just get the records you are interested in. Obviously that should not be done in all cases. Another issue with this approach is you need a way to update any other Datasets you may have with this data - i.e. your main search screen.
However, once I get on the edit screen I find it makes things eaiser. Now I don't need to worry about the master detail relationship at the top level. If the invoice has internal Master/Detail relationships you can just deal with those, but you know that the DataSets only have the data for this one invoice - not everything in the Database.
In the case of your form if you limit the Data in the DataSets you can just hook everything up directly and it should work as you expect. You would only have one record in the Customer DataSet and the invoice would just have the records for this Invoice.
I think you'll need to take care of the master-detail relations in your ClientDataSource components. The grid will then follow this relation.
Why don't you ask this at support#devexpress.com ?
The reason why I have a vcl subscription is, apart from the quality of the components of course, because they do have a great support site and staff ?
There you ask it directly to the people who have written the stuff, and they are most likely happy to supply you with a sample program (at least I have received a lot of samples over the years).
The premise is the same as with any other master-detail relationship, regardless of the components. You will need to setup the master-detail on the dataset level to accomplish what you want.