My app has windows that are components. In my case, now I have 2 components that have a drop down list that show the current logged user lists. So when I use one component for the first time it make a request to database, save data in model, and load data from model, but when the second component opens, it will just load data from model. Easy for now:
ListModel: this contains the current user lists.
Now I have another component but this needs the lists of another user. Where do I save these lists? I can't put in the ListModel as then will mix up with current user.
Just a remind: there is not just 2 users. It might have more users, so it should be scalable.
Then another problem that will solve both:
Each list has items. They will be saved in ListItemModel?
How to make to not mix between lists. So items from ListX doens't mix up with items from ListY?
thanks
Don't be timid with the models. Use as many as you need to model your data for effective use. You can model the same data in several different ways. If you find commonality between models, extract a base class for them to use
Related
Does anyone have any pointers on how to go about creating a "wizard interface" using Access 2010? I need a sequential set of forms that will be capable of branching the flow based on answers from the user and data found in the database. I have used Access before for some CRUD/Reports type of applications, but in this case I can't seem to wrap my head around how to get started on such a complex machine.
Before anyone suggests it, I cannot use anything but Access due to client requirements.
I feel your pain ... working with Access gets so difficult where there are complex requirements.
Gather and document the requirements
Make sure you've teased out every possible wrinkle and contingency from the client, and put it into a flow chart or something.
Extract the models
Figure out what models are being used -- customers, addresses, vendors, products, etc. These will have to be created as tables or adapted to existing ones.
Extract other variables
What could potentially change over time and/or what will the client want to be able to change via an admin screen? You'll have to decide which of these variables to put into tables, and which are ok in the code (form logic and/or VBA).
Design the tables for the wizard views
I imagine you'll want a wizard screens table, where each row corresponds to a step; each should have (other than an id column) a previous screen column, and a form name or form template name column. You'll need a second table choices with a many-to-one foreign key linking back to screens; each row here will correspond to a possible outcome of the view, and the target next step in the wizard.
Design the forms
Finally, design the forms corresponding to each wizard step or template, pulling data from the structures in 1-4 as needed.
I am making a semi-simple web application for my mother using php, mysql, and javascript.
She is a teacher, and this wil allow her to manage various components of her lesson plans.
For each component there is a table, and for each component that can contain another component there is another table that holds the relationship. (That table type has two columns each has a foreign key to the related tables)
I am nearly done, but she now wants to allow her friends to use this, I don't care too much about sql injection, but I would like to implement User Control so that only users that create a component can view and edit that component.
I also want them to be able to make public components, so that users can copy components to their own dataset.
My question To implement the user control should I have each user have there own database instant, or should each table have an owner column and column for public/private status, or is there another alternative that I have not thought of.
An issue that I see is that it would require additional mysql query when creating the relations between components because I would need to check that both components user tag matches the current user.
Any feedback/suggestions are helpful
Update The only people using/accessing this will be other teachers, that will be developing their own lesson plans
I would certainly implement this within the same database. Having a different database for each user is not a good solution in this case. Think, for example, how you would build a search function if each user's data is in a separate database will clashing UIDs. It would be a nightmare. Separate databases work where each database serves a separate application and there are precisely zero relations between the data in different databases.
So that brings you on to how to implement it. This will depend on your model. Will each lesson plan only ever have, for example, one and only one owner? If so, then adding that info to the components table might work. Or else you might need a separate table to define ownership and hence access to the different components. Either way, I would make sure the access logic is decoupled and encapsulated in your application to make sure you can change it in the future. Imagine for example you start with a simple, single-owner model but the site grows and grows and soon groups of people all need ownership/edit access to components.
I'm building medium sized business web application, data is being saved on a MySQL database.
I'm trying to think of a way of adding certain selectable "widgets" to that application (e.g. a currency widget - which will show user specified currencies when the web app is visible) but having an hard time deciding how to save the widget data and settings per user since the widgets do not have a common base.
For example, the currency widget's settings is totally different than say, a weather widget.
One will require a list of desired currencies, and one would require the weather's target location.
I thought of solving the above by keeping all the widget's settings data encoded in the "widgetData" column of a db table which will contain the userId, widgetId and widgetData.
I chose JSON as my way of encoding, and each time a user tries to load it's page, I have to decode it's settings and hand the user the desired data based on the settings.
The same is true for saving the widget's actual data which does not have a common base itself.
Hopefully I can solve this by using a NO-SQL data structure next time, but this is not the case for the current project.
The Entity Attribute Value database model would be useful very to you in this scenario.
It's much more flexible than JSON or XML or other types of formats because it works within your standard SQL data storage, albeit in a different manner.
I voted up the EAV solution because this is one of the valid reasons for using it, but don't fall in love with it. An advantage of EAV is that it is database-native to the extent that you can write queries in SQL to query it (find me all widgets missing some setting and then add it), while most engines do not have JSON support.
On the other hand, if you want/need to query within a column which contains structured data, XML is a better option than JSON (right now): http://dev.mysql.com/doc/refman/5.1/en/xml-functions.html#function_extractvalue
If your widgets are rendered via Javascript in the browser, then your solution is perfectly fine. Your widgetData remains a JSON string, in Javascript you use JSON.parse() to turn it into an object and render it, and JSON.stringify() to turn it back into a string before posting it back to your server.
I have a lookup list that is used in a custom solution to provide information about a specific location. This list includes columns of type People and Groups.
Given the quantity of locations that will be available I'd be very keen that the list is maintained and imported from an Access database. I do something similar with my configurations list which works great. It just means I can rapidly deploy all configurations across different environments.
The problem I have encountered is that it doesn't seem to handle columns of data type People and Groups. The lookup is not available in Access. From what little i have found online, I'd not even sure if this is possible. This article suggests that Access automatically creates a link to the USerInfo table. Even with this link, I cannot look up values.
Can someone please let me know if this is possible or a limitation and cannot be achieved when linking a list to Access?
This absolutely possible, and MS Access should automatically link any dependent lists when you import a parent list that has lookups.
Check to make sure you don't have multiple UserInfo lists linked, like UserInfo1, UserInfo2, etc. If so, delete all your linked SP lists and relink.
I've implemented the repository pattern on the data access layer of our current service layer.
We have an object model where the same class "historical notes" is mapped on mutiple objects (currently 6 but soon to be more!)
Part of the best practices for the use of linq to sql is not to have one dbml file for every table in the db, but instead to break it down, this way it doesn't have a huge performance hit when the context is created.
Unfortunately the logical places to separate the objects leaves the historical notes in 5 different DBML files. When the linq generator creates the classes it generates a different class in the different namespace.
I have a historical note object in the domain model, but I don't want to re-map the domain object model into the data model for every time we use the historical notes.
One of the things I don't want to do is break the "reading" of the data into multiple queries.
Is there a way I can map the historical note into multiple data models but only write the mapping once?
Thanks
Pete
Solution
Thanks for the help, I think I'm going to move back to one data context for all the data tables.
The work arounds involved in setting up the multiple models isn't worth the extra complexity and potential fragility of the code. Having to write the same left hand, right hand code to map the historical notes is all too much work and too many places to keep the code in sync.
Thanks guys for the input
Part of the best practices for the use
of linq to sql is not to have one dbml
file for every table in the db, but
instead to break it down, this way it
doesn't have a huge performance hit
when the context is created.
Where did you hear that? I don't agree. The DataContext is generally a fairly lightweight object, regardless of the number of tables.
See here for an analysis of the issues involving multiple data contexts:
LINQ to SQL: Single Data Context or Multiple Data Contexts?
http://craftycodeblog.com/2010/07/19/linq-to-sql-single-data-context-or-multiple/
In my opinion, you should have one datacontext per database. This would also solve your mapping problems.
See also LINQ to SQL: Multiple / Single .dbml per project?
One option could be to put the historical notes in their own datacontext, and keep the relationships between this object and the rest of your model as 'ids' (so just foreign keys in the db). That's how I would do it anyway.