Discussion Forums
- Topic List
- Most Recent Posts
- Sign In for more options
Thanks for the reply, and apologies for the delay in responding. I had to stop with the Rails redevelopment (and learning) when things got interesting at work. It's all quietened down again and I'll be trying out your help once I get my head back into Rails speak.
Thanks for the reply.
I am experimenting with the DB design, trying to come up with the best fit I can within my limited expertise. The main issue I am running into is that (using an extremely reduced example set of fields) a form for a lost cat may have the following fields: Name, Colour, Age, Breed and a truck may have: Registration Year, Registration Number, Colour, Manufacturer. The only similarity is colour! My main confusion lies in how to create this in Rails. I have been reading and digesting several books (AWDR, Programming Ruby, & Rails Social Networking Sites to name a few) all give examples of sites where the entry form uses exactly the same information/fields for every single posting. Would I need to create a model and view for each category (seems wasteful and not very DRY) or have a model which picks and chooses between fields and tables to power a generic form dependant upon the chosen category? If anyone knows of examples which have this type of problem, please let me know! edit After posting this reply, I had an idea that the answer may well lie in the use of partials, building up the form dependant upon the information required. Going to go away and experiment. I will report back in case someone is interested :)
The database design seems to be poor unless you have only limited categories( say posts only related to lost cat,dog etc) . But as per your post it seems anyone can post any information ,so creating a table for each category will not be a good idea , what i would suggest is to have a master table to store the category name/code/id in it and then have a separate table for comments where you can save the category to which this post belongs and the post details, there by u can limit the number of tables as well as increase the performance.
Hi people, only signed up today and already looking for help! Don't worry, I'm not asking for a step by step guide, just an opinion from more experienced developers.
My situation is this - I am thinking of re-writing a website I am currently working on and looking for initial clarification on how MVC would work in this instance. Brief outline: It's a lost/found website, where people can post appeals for anything that has gone missing, been found or stolen. There is no discrimination as to what the item that has been found/gone missing is. It can be anything from a cat, to a dog, a car, a person, a truck, antiques, etc. Visitors can post replies to an appeal, which are only visible to the original poster. Currently, you choose the type of item you are posting about from a list of categories and are taken to a form tailored for that type of item.
What I am trying to get my head around is how I would program it in a Rails/MVC way. Seeing as most information relevant to a lost dog would be completely different to that for a stolen truck, would there be a separate MVC for each type of appeal, or would there be one for all types and then modify the post/edit view dependant upon the information required? I personally understand from what I have read and learned from various Ruby/Rails books it would be the latter, but they tend to show items that are related and require the same structure and information.
The db I inherited was not professionally designed and is currently split into categories - i.e a table for cats, one for dogs, one for vehicles, etc, each holding address details, etc. The way I understand this would cause many issues for a Rails implementation. I am looking at a complete re-write, so a fresh, properly structured DB, coupled with properly formed HTML, CSS layout, etc is planned.
Any hints for a proper, well structured approach would be appreciated. Thank you for your help, apologies for such a long initial post and I look forward to offering what I know in return!
