It's simple. I have three tables, for example: Persons(ID, Name, etc.) Lessons(ID, ClassroomID, Description, Etc.) Person_Lesson_Link(PersonID, LessonID)
The third table links the two others in an N:M relationship. A person can follow multiple lessons, and a lesson is given to multiple persons. I've created an entity model around these tables, which only shows the Perssons and Lessons tables and which links the two. I've also created a Dynamic Data website which will allow me to work with these tables, adding, editing and removing records as needed. But I still need to know a few things, in the following priority:
I need to filter the Persons based on a lesson. So a filter is needed which shows the lessons.
I need to add a link between a Person and a Lesson. Or edit a link, or drop a link.
So, any examples on how to do this, without having to write lots and lots of code?
(Main problem: I have about 15 of these linked tables, so I need something generic.)
There is standard Dynamic Data field template for editing Many-To-Many relationships in .NET4.0 based on CheckListBox. Download VS2010 and grab templates from there.
Also you can create Filter Template based on this field template for filtering Many-To-Many relationships.
Related
I'm working on a studio project to try to learn different approaches using Symfony2, Doctrine 2.4.7 as ORM and MySql 5.5 as DB. I've deliberately minimized my question for a better understandability and readability, if you need more details you only have to ask and apologize me if my english is not so good.
To avoid a large discussion due to the title of my question let me synthesize the problem showing a simple and common case (but complex for me because I'm new with doctrine).
The Model:
The User entity (mapped) that stores the user's data
The Category entity (mapped) that stores some categories associated to the User with a ManyToMany BD.
Each User can select one or more Categories.
The Problem:
User categories are near 100.
Many Categories could have a specific associated form.
Each form is composed by common and/or only specific fields (from 1 to 10 fields per category).
The Goal:
Understand what's the most balanced approach for this use case (in terms of flexibility and performances), for create the entities and associations needed to store the data filled by the user (some of these data I wish they were to be searchable).
Some Related References:
Doctrine2 docs
Serialized LOB
Extensible Data Modelling
and many other threads not much relevant...
A Possible Solution:
Create manually a form type for each category with inside the block of related fields (I use this forms as services in DIC and use blocks for the fields I need to reuse on more then one category).
Create a CategoryForm entity with the properties needed to retrieve the name of the form related to the category (useful to the form factory when I build the form) with an association ManyToMany UD with Category and to store the serialized LOB (the data coming from the form and related to the User).
There is a better approach to avoid the serialization of the object in a LOB? (maybe I'm wrong but serialized data are not searchable/indexable in mysql)
Any other solution or reference to a readable resource is welcome!
Well, I will try to answer the question with a simple guess: the category is something shared beetween several users (since you got the many to many).
So, if you want the User's form to be able to set (add/delete or update) Categories assiated to the user, then you should just have acollection of entity widgets related to the Category.
Why do I say that ?
Since your categories are linked to several users, the way you want to treat the relation beetween Categories and Users will cause any update on existing Category from a User's form to be propagated to other Users.
This means that Categories should be created/updated by a single form (modulo your needs). You can then link the Category to the User from User's form.
As far as the number of form of Categories is concerned, there are several parameters to handle:
Are all the Categories validated the same way (to know if you simply need to hide widgets to make the validation work) ?
Do you have a large amount of different types of Categories ?
If yes, are always composed the same way for a given type ?
Give further details if I'm wrong in my initial guess ;)
I’m absolutely stumped by what I suspect is probably simple for those experienced with Access. I’m brand new to Access (2010) and studying a lot, but unfortunately still confused by many basic concepts. I’m embarrassed to admit that I have spent about 40 hours trying (unsuccessfully) to solve the specific issue below. Please forgive me if I haven’t included enough detail here - I’m not sure how much someone needs to know to address this. I’m happy to edit and/or provide more information.
My question:
How do I create a Form for creating new records / editing existing records in Table1 where two fields in Table1 have different values from a single field in Table2? (I have better detail below)
I want the Form to have all the records from Table1. I have tried many different ways with queries, sub-forms, etc., but can’t pull it off. I’m fairly certain the issue is related to how I address Table2. Ideally, the user would be able to select from dropdowns in the form for the two fields to be updated in Table1.
I am including screenshots of a mockup of my intended Form concept, the object Relationships as I currently have them, the design and datasheet views of Table1 and the design and datasheet views of Table2.
“Table1” above is “t_PEOPLE” in the images while “Table2” is “t_COLORS.”
The object relationship types are currently one-to-many with enforced referential integrity (cascade update related fields) and the join properties are "include ALL records from 't_PEOPLE' and only those records from 't_COLORS' where the joined fields are equal."
I'm happy to send the actual database file if that helps.
I will be very grateful for any guidance - thank you!!
The general approach to this is as follows:
A) If I understand what you're trying to do here, your t_colors table is usually referred to as a Reference table or Lookup table. You need to make one form to add, edit, and delete records in this t_colors table. How the user accesses that form varies. I'll get to that in a minute.
B) The form for your People table needs to have drop down menus for your two color selections. In the dropdown menus' RowSource, you will use a query that looks up values in your t_colors table.
C) Depending what you are using your colors for in t_people, you should consider making a third table with PeopleID and ColorID in it. It would then link to both t_people and t_colors. This would allow you to have multiple colors specified for a single person, and you wouldn't be limited to two. In your People form, you would use a subform for these colors. The subform would probably need to be a datasheet form or a continuous form. If you are using a datasheet form for your people form, then you would need to use a datasheet form for the colors subform.
If the user wants to use a color that isn't already in your t_colors table, you need to give them a way of inserting that color. There are various approaches to this. You could use a union query in the dropdowns RowSource that shows a "" option. If selected you would bring up your Colors form and when they close the colors form you have to requery your dropdown menu. Or you could insert the color for them using VBA when they enter a value that is "Not In List" (an event that Combobox's have).
Please note that the relationships you've defined are not overly helpful or important in this case. Yes, they can be helpful when it comes to using the Update Cascade or Delete Cascade features. But quite truthfully, relationships are basically for programmers, to make sure you get an error if and when referential integrity is violated. Users should never see these errors and properly designed forms will prevent them from occurring. The main reason to use them is that it will force you to design your forms properly by giving you an error when something is wrong, hopefully during your own testing phase of the project.
I know how to make custom fields for my custom post types. But I need a pretty complex custom field this time.
I'm making a website about agricultural machinery. There are a lot of types of machines. For every type of machine there are some products available with properties like size, mass, diameter, capacity, ....
Per type there is only one description, one title and one image needed. So my custom post-type machine contains posts (custom type = machines) with the basic information. For every machine I would like to sum up all the different size - mass - capacity - prize information in a table. I know I could just create a html table in the description, but I would really like the data to be structured so I can nicely style it, and eventually even do structured searches for price and stuff.
So ideally I would like to have a custom field that looks a bit like an excel sheet where I can create some columns and add rows per available product in the category. Any ideas how I can do this?
EDIT: I'm trying out the Types wordpress plugin http://wordpress.org/extend/plugins/types/. There's an option to group custom fields together and also an option to allow multiple instances of one field. Would be useful for me if there would be a possibility to allow multiple instances of a group. Does something like that exist?
EDIT: This looks promising. http://wp-types.com/documentation/user-guides/bulk-content-editing-with-fields-table/
I will look into it and maybe answer myself if it turns out to work :)
It seems like wp-types had the solution all along.
http://wp-types.com/documentation/user-guides/bulk-content-editing-with-fields-table/
This is what my custom data table looks like now:
Behind the scenes, all data is not actually saved in a single post. But wp-types allows you to create hierarchical relations between post types, and then provides a way to quickly create sub-posts straight from the parent. That's awesome enough for me.
In my case I created two post types. One called machine-type and another called machine.
machine-type holds all the basic information about the machine (title, description and image) while it's sub-type machine holds the specs for any of the different variants.
My Task: I have content type which have 100+ different mostly numeric fields (big questionnaire for NGO with yearly reports). For one field I can use Views module to let user select which reports include (for example one year) and display it as nice graph (using for example Views+Charts). I would have to define about 100+ nearly identical views, which differs only by what field data they use.
My Question: Is there any way how to reuse one view definition and just change data from which field id display?
Solutions so far: I found two not really good solutions:
Create one view, export it (using Features or similar way) and then clone this export, rewrite field it uses as source and than add. But this just speed up creating one view for each 100+ fields.
Use module Views Dynamic Fields - it allows user to select which fields to display. But I would still have separate definition how to display for each field, so not much better than add one view for each 100+ fields.
I suggest writing your own Views field display plugin! This is actually all documented within the Views module folder: views/docs/views.api.php. Depending on your fields I'm not sure how you would exactly connect the data to the view.
Another alternative would be to just use a PHP Code field, and figure out a way to programmatically display the data from the field you wanted. The downside to this is that you wont be able to use that field to sort/search on with any filters as far as I know.
I have about 20 different tables that each have a different parent / child relationship built into them. I've recently been asked to create a breadcrumb and Site Map for our website based off of all of these tables.
One idea I had, was to remove the parent / child relationship from each of these tables and create basically one table that holds the id and parentId and whenever I need to pull the parent child relationship I would just join the parent_child_relationships table to whatever table I was pulling from specifically.
Does this make sense?
Anyway, the problem with this idea is that i don't like it. haha.
Does anyone else have any other ideas of how this could be done? Or what the correct way of building a breadcrumb and sitemap based off of a site comprised of 20 tables or so?
If it helps, my site is comprised of asp.net, ColdFusion and uses a MSSQL database.
Thanks!
Do not let the implementation of the UI effect the design of your model and especially not your DB. Prototype the front end, involve your customer(s), give them a voice. Build your breadcrumbs and site map without it initially tied into your actual DB. Once your customer says "thats what we want, just like that", then freeze the prototype, then work on the actual implementation - how will your app request the data, what type of dataobject will you use AND THEN build your db,
"One idea I had, was to remove the parent / child relationship from each of these tables and create basically one table that holds the id and parentId"
This is not a very scalable solution, do not *reverse normalize your db. Follow standard relation database modeling/normalization techniques. Lots of small cohensive tables with lots of association tables.