Some thinks will be adapted because I just want to have a standard look of how some things will look like.

jamesw wrote:

You should design your views with the best user experience in mind. If you do that then, the controllers and actions you needt will become clearer and you will find the controllers and actions you need will just flow.Focus on the user experience rather than the code, write the code to make the uer experience work rather than making the user experience fit how you want to write the code.

Yes, I just want that my user has his selection criteria at the left hand side:If chosen a category:x Electricx Category A

And so on, so they have a nice structured way of looking into the products.

In my main content area, on the first page there will be the selection of Electric/Motoric, some recent products the customer has looked at or ordered and a little history of his orders.

At the right hand side, there will be his accout info and his current order list.

So this will be the user experience normally. I will look where for I need a controller, but I'm still having some trouble with those controllers and how to use them correctly. After all, I will get along with everything I hope because I like the RoR framework. It's a matter of time and learning the basics + advanced things.

They should be partials rendered from your main layout positioned using css

That is also my intention! I already have (now in my sessions folder):_accountinfo.html.erb --> right sidebar account info_classeswidget.html.erb --> main page (showed when selecting electric/motoric)_login.html.erb --> Explains itself _prodgroupwidget.html.erb --> main page (showed when selecting a category within classeswidget.html.erb)_startwidget.html.erb --> main page (when logged in, this will be shown)

Re: What is the best modelstructure and routes?

Sounds like you are on the right track.I typically have a url like mysite/welcomeOnce a user is logged in they get redirected to the welcome url which would mean a welcome controller with just an index route, action and view.each entry following / in a url is either a name space or a controller or an action within the controlllermysite/admin/welcome would indicate an admin name space with a welcome controller inside the admin name spaceRemeber that you don;t need to specify index. browsers will look for an index page inside a path automaticallyhence

mysite/admin/welcome

is exactly equivalent to

mysite/admin/welcome/index

You can overide the way a url looks by adding a route to match a controller and action. A typical example of this is logging in.A session controller is typically used to log in with but it is typical to add a login route and disable the session route.So you navigate to mysite/login which would call the session controllers new action.The form then gets posted back to the sessions create action which if successfull redirects to the welcome urlso from mysite/login you end up at mysite/welcome

In website terms a url is a path to a file in a folder.so navigating to mysite/welcome/index.html would render a file called index.html inside a folder called welcome. In Rails a folder is exactly equivalent to a route. The routes.rb file has the job of matching a url and it's paramaters with a specific action in a controller. Keep the controller names consistent with the paths for the urls and you will feel a lot more comfortable. It really is that simple.

In an html only website you would create folders and files within those folders. In rails terms you create controllers and actios within those controllers.

What you want and what you need are too often not the same thing!When your head is hurting from trying to solve a problem, stop standing on it. When you are the right way up you will see the problem differently and you just might find the solution.(Quote by me 15th July 2009)

That is just wrong._accountinfo.html.erb --> right sidebar account info - This should be rendered from your layout.html.erb view inside an if logged_in? condition

_classeswidget.html.erb --> main page (showed when selecting electric/motoric)Should be rendered from the welcome page (possibly)

_login.html.erb --> Explains itself smilefair enough

_prodgroupwidget.html.erb --> main page (showed when selecting a category within classeswidget.html.erb)Not sure where that belongs. It would be clearer once you have the landing page sorted but probably rendered from the welcome page.

_startwidget.html.erb --> main page (when logged in, this will be shown)Perhaps this would be better rendered from a header partial? Not sure what this does

What you want and what you need are too often not the same thing!When your head is hurting from trying to solve a problem, stop standing on it. When you are the right way up you will see the problem differently and you just might find the solution.(Quote by me 15th July 2009)

for expediency Ryan has mapped the root_url to the new action in the sessions controller using

root :to => "users#new"

in the routes.rb file as he is not developing a full site, just an example of how to log in.This would be where you would use the welcome_url (or whatever path you want to set up for your landing page after logging in

What you want and what you need are too often not the same thing!When your head is hurting from trying to solve a problem, stop standing on it. When you are the right way up you will see the problem differently and you just might find the solution.(Quote by me 15th July 2009)

Re: What is the best modelstructure and routes?

_accountinfo.html.erb --> right sidebar account info -This should be rendered from your layout.html.erb view inside an if logged_in? condition

Good to know... and logical!

jamesw wrote:

_classeswidget.html.erb --> main page (showed when selecting electric/motoric)Should be rendered from the welcome page (possibly)

This is the partial where all product categories are being showed when clicked on Electric/Motoric (which is shown on the startwidget partial)

jamesw wrote:

_prodgroupwidget.html.erb --> main page (showed when selecting a category within classeswidget.html.erb)Not sure where that belongs. It would be clearer once you have the landing page sorted but probably rendered from the welcome page.

This is the partial that is being showed when a category has been selected (so al productgroups go in here when for example category A has been chosen)

jamesw wrote:

_startwidget.html.erb --> main page (when logged in, this will be shown)Perhaps this would be better rendered from a header partial? Not sure what this does

This is the widget showing Electric/Motoric. The first selection criteria.

Also, customers that aren't logged in, won't be able to search for products! It's a customer portal, so no outsiders (without any credentials linked to the company) will be able to access the page.

------------------------As for your last post (on routing):I understand the basic routing examples, I also have a routing to a root_url, but for my website at the moment, the root_url is the sessions_path --> So this one will be changed to the welcome page

Re: What is the best modelstructure and routes?

The only thing now is that I have the following and don't know if it is right to do so:

Looks fine to me.But then I don't know your requirements.Perhaps you could expand on what it is you are not sure about?

What you want and what you need are too often not the same thing!When your head is hurting from trying to solve a problem, stop standing on it. When you are the right way up you will see the problem differently and you just might find the solution.(Quote by me 15th July 2009)

I have no idea if that gets you the actual results you need. It's the principle that I'm talking about herethen you just have to call

Product.electric_product_groups

Keep the scopes and other defs as they are as you will most likely need each of them individually for various other things at some point.

What you want and what you need are too often not the same thing!When your head is hurting from trying to solve a problem, stop standing on it. When you are the right way up you will see the problem differently and you just might find the solution.(Quote by me 15th July 2009)

Re: What is the best modelstructure and routes?

Re: What is the best modelstructure and routes?

I'm still having trouble finding the right way to show my product selector.

So:I understand how to make custom methods and routes to the controller and route.rb, but not how to create only and only that controller and accessing it within the routes. Or did you mean anything else by stating I had to put them in another controller.

Entering the website:

root :to => "sessions#index"

--> On this page, I have a partial named "_login.html.erb", which logically will have te option to login or to sign_up.

Once logged in:

session[:customer_id] = @customer.id
redirect_to root_path

--> As you notice, I redirect to the sessions#index method. So you are now saying I have to create a (for example) welcome_controller which has an index.

A landing page is shown with company logo, a login link and whatever else you think would make the site look proffesionalThe login link ahould take the visitor, bot or user to the login page

Use case 2 :-A user successfully logs inUser is taken to the landing pageThe landing page shows a log out link, company logo etc... plus additional menu and partials that only logged in users are allowed to see

Use Case 3 :-A logged in user revisits the site after a browser crash.The logged in user should see the welcome url as if they had successefully logged in.

Now you have the route, controller, action, view and tests for the welcome controller index action and you have set your site up to always load the welcome page as first port of callYou could change Use case 1 to automatically redirect to the log in url in a before_filter which redirects non logged in users to the login url and once logged in you can redirect them to the welcome page.

The index view for the welcome page may need to show additional information but most of the work for this would be in the application.html.erbWhatever options are then chosen should take the user to different url's appropriate to the chsen action.

Hope that makes sense.

The railscast I linked to showing authentication from scratch should be followed to set up your login views and urls - I know you have that working but you seem to be referring to login partials when you really should be talking about a new.html.erb

What you want and what you need are too often not the same thing!When your head is hurting from trying to solve a problem, stop standing on it. When you are the right way up you will see the problem differently and you just might find the solution.(Quote by me 15th July 2009)

Re: What is the best modelstructure and routes?

You really need to nail your design and use cases before you cut your code!

What you want and what you need are too often not the same thing!When your head is hurting from trying to solve a problem, stop standing on it. When you are the right way up you will see the problem differently and you just might find the solution.(Quote by me 15th July 2009)

Re: What is the best modelstructure and routes?

errrm! You need a spec. Do you have one?

What you want and what you need are too often not the same thing!When your head is hurting from trying to solve a problem, stop standing on it. When you are the right way up you will see the problem differently and you just might find the solution.(Quote by me 15th July 2009)

Re: What is the best modelstructure and routes?

As in pieces of paper with user requirements and use cases, sketches of screens etc...

What you want and what you need are too often not the same thing!When your head is hurting from trying to solve a problem, stop standing on it. When you are the right way up you will see the problem differently and you just might find the solution.(Quote by me 15th July 2009)

Re: What is the best modelstructure and routes?

Cutting code is easy when you know what you need to achieve. It's no good just having it all in your head! Well it's fine when you have 20 years coding experience but not when you are starting out. But even then you still need basic user requirements writing down.TBDD (Test Behavioural Driven Development) is usually where I start. It defines the spec for me and I just then need to write the code until all the tests pass.It makes cutting the code dead easy.

What you want and what you need are too often not the same thing!When your head is hurting from trying to solve a problem, stop standing on it. When you are the right way up you will see the problem differently and you just might find the solution.(Quote by me 15th July 2009)

Re: What is the best modelstructure and routes?

I don't have a spec, because I don't understand why I need it. I believe a spec is a test-environment, right?I'm sure I don't get a viewpoint of you and a lot of other rails-programmers (and probably other language-programmers) who are writing these test-codes.

Please tell me where my thoughts are wrong so that I see the benefits of using a test-environment.

In rails, you just write extra code to do what a user would do to look if it's working, but why don't you test it by going to like the localhost and try it out yourself? I always just go to the login section, where I end up automatically. I do a signup or a login and then, I get some errors. On the base of that, I look at the errors and try to solve them. Afterwards I refresh and see if it works.

I have made a design with GIMP to see the structure of the site and what I need and what I have to do. That's what you mean right?I was thinking that working with different widgets made by myself, it would benefit the view of the page for me as developer. Am I thinking wrong, or just thinking to early on it? I just don't want to end up with chunks of code where I have to re look what they are meant for.

Re: What is the best modelstructure and routes?

I believe a spec is a test-environment, right?

No.A spec is what an analyst gives you so that you understand what the database design and the business logic is. It is essential when dealing with customers that specifications are agreed to show that both the developer and the customer fully understands the business. Without this you will achieve missed dead lines, over budget code and the sort of bugs that are known as "features".

When working on your own, you need to understand the full project life cycle from conception to deliver and then on to support. How can you charge a customer for more work if the spec doesn't exist. The won't understand the need for an extra weeks coding because you "misunderstood" their requirements.

Consider how a £250,000 project works from conception to completion. It starts with a requirement, gets turned into a spec, code gets written, tests are run, Quality control passes and code gets delivered, support requests come in and so it goes on.

It doesn't matter what language, or technologies are used or the size of the project, it's always the same. Some might use UML as a spec, others use flow charts but whatever is used the business logic MUST be nailed and tests MUST be written. I've worked on multi million pound projects and 1,000 pound projects, I've worked for many different software houses, I've worked in-house and as a freelancer. I've used dozerns of different technologies, languages, databases and design techniques and worked on many different types of project from major financial institutions, telecoms companies to small factories to satelite systems. It doesn't matter. The difference between success and failure is a well defined specification so that both parties fully understand exactly what is needed, how the screens will flow and what the rules are.

It all boils down to one word COMMUNICATION. Many companies are bad at that and that's why they either fail or go badly over budget and time scales.

Tests are also incredibly important. They PROVE that your code works. Not just once but every time your code changes. On small scale projects and with the correct testing suite (as in the how I test railscast) tests can also act as a specification. There is nothing wrong with delivering tests to your user. It helps them see your progress as they see the tests start to pass and gives them confidence that you are on target and are actually doing what they have asked you to do and helps define clear milestones.

Also, Rails needs tests more than the vast majority of languages because it's interpreted rather than compiled. Typos are picked up by compilers and you need to fix them before you can produce an executable. With Rails the only way you will pick up on a typo is if you run the code or you have an incredibly good IDE, but you shouldn;t rely on an IDE and it's not possible to run every single line of code every time you make a coding change unless you have a test that does it for you.It's so much nicer and quicker running

rake test

and watching everything go green than having to run through the same forms, pressing the same links, looking at the same data time after time.

Yes, you will still hit the browser and run through the views, but this becomes more of a cursory check to see what things look like than a test. If you find something wrong, write a test for it and you know it will never go wrong again without you knowing about it. I can not recommend that railscast strongly enough http://railscasts.com/episodes/275-how-i-test - It's what everybody should be doing.

When you just have a login screen and one page, tests don't seem to be so relevant but add more than a couple more screens, options and functions and you soon find yourself just hitting the new stuff and ignoring the old stuff coz it works, right? I can guarantee that at some point it will stop working! There are bugs in all software that is not tested thoroughly and when writing code, every single full swtop, comma or space can be the cause of a bug. It might sound pedantic (To those that are not in the game it is incredibly pedantic) but the best programmers are pedantic beyond belief.

I have made a design with GIMP to see the structure of the site and what I need and what I have to do. That's what you mean right?

That's one way. GIMP I would consider overkill, pencil and paper sketches are usually good enough. One analyst I know used to write specs on the back of a matchbox, for a multi million pound contract, and wondered why things went wrong!

I was thinking that working with different widgets made by myself, it would benefit the view of the page for me as developer. Am I thinking wrong, or just thinking to early on it? I just don't want to end up with chunks of code where I have to re look what they are meant for.

That's cool! It's an OO approach and OO is very good. Ruby is pure OO and that's what makes it a good language. Rails is is less OO because of the nature of views and HTML but it tries to be OO with the DRY (Don't Repeat Yourlsef) principle which is exactly what you describer you are trying to do. Keeping things small neat and descriptive is a very good approach.

In a professional environment a software department consists of not just developers, there are graphic designers, Quality Control staff, project managers, database gurus, network engineers, hardware engineers, support staff, the list goes on. When you are on your own, you have to wear all those hats and suit them all well. It's a daunting prospect and hard, but great fun

Obviously if you are writing a non mission critical project (Is there such a thing? I can't think of any) you can take a pretty lax approach and not bother with any of the above and get something approaching a usable piece of software but it will take longer than if you do it properly and it won't be as good.

Last edited by jamesw (2012-10-23 13:01:39)

What you want and what you need are too often not the same thing!When your head is hurting from trying to solve a problem, stop standing on it. When you are the right way up you will see the problem differently and you just might find the solution.(Quote by me 15th July 2009)

Re: What is the best modelstructure and routes?

However, the bigger problem is at the other end of the spectrum. We have found that taking the time up front pays dividends down stream. If you don’t have time to specify it up front, you probably don’t have the time to do the project.

Here are some of our guidelines:

Spend time specifying and documenting well software that you plan to keep. Keep documentation to a minimum when the software will only be used for a short time or has a limited number of users. Have separate individuals write the specifications (not the individual who will write the code). The person to write the specification should have good communication skills. Pretty diagrams can help but often tables and charts are easier to maintain and can communicate the same requirements. Take your time with complicated requirements. Vagueness in those areas will come back to bite you later. Conversely, watch out for over-documenting those functions that are well understood by many people but for which you can create some great requirements. Keep the SRS up to date as you make changes. Approximately 20-25% of the project time should be allocated to requirements definition. Keep 5% of the project time for updating the requirements after the design has begun. Test the requirements document by using it as the basis for writing the test plan.

What you want and what you need are too often not the same thing!When your head is hurting from trying to solve a problem, stop standing on it. When you are the right way up you will see the problem differently and you just might find the solution.(Quote by me 15th July 2009)