Forum: Ruby on Rails Simple ecommerce site using rails ????

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
singh (Guest)
on 2006-12-31 01:40
(Received via mailing list)
Hi All,

I am new to ruby and rails. I have good experience in C/C++ in other
areas of software. But first time trying hands on Ecommerce site.

Can anybody let me know how much time it may take me to do first
ecommerce site in ruby on rails. Its simply to sell 5 products. I don't
knwo ABC of ruby and rails yet.

It might seem to be stupid question but I seriosuly want to know time
it will take before getting into it as I have Three Months.

It will be great if you can point me to resources/books I can go
through for quick start.

Thanks in advance for your answers.

Thanks
Singh
boboroshi (Guest)
on 2006-12-31 05:59
(Received via mailing list)
Well if you have three solid months to dedicate you could probably get
pretty close to a finished product. Especially if you understand
programming in general. Rails is powerful, but the power lies in Ruby
and extending things on your own.

I would recommend the following books:

Agile Web D. with Rails 2nd Edition (pragprog.com) - this is
your reference manual, but the step by step tutorial is around an
online book store. The basics, but gives you a good idea.

Then I would try Beginning Ruby on Rails E-Commerce
(http://apress.com/book/bookDisplay.html?bID=10178) - this is slightly
more difficult to follow. I found some points in the book where the
code in the example had changed without them telling me to change it,
and I'd have to jump to the downloadable code for that chapter. This
dives in a bit more into the specifics of ecommerce and also is written
from a test-driven development point of view.

Finally, you need the Pick Axe. The Ruby reference. Buy version 2
(pragprog.com) or browse the online version 1:
http://www.rubycentral.com/book/

Good luck!

-John
www.boboroshi.com | www.meticulous.com
Benjamin C. (Guest)
on 2006-12-31 06:55
(Received via mailing list)
Some resources...

1. Use the link in my signature to learn about building e-commerce
sites with Rails. :)
2. Check out the substruct project for a starting point.

--
Building an e-commerce site with Rails?
http://www.agilewebdevelopment.com/rails-ecommerce
nick (Guest)
on 2006-12-31 14:21
boboroshi wrote:
> Then I would try Beginning Ruby on Rails E-Commerce
> (http://apress.com/book/bookDisplay.html?bID=10178) - this is slightly
> more difficult to follow. I found some points in the book where the
> code in the example had changed without them telling me to change it,
> and I'd have to jump to the downloadable code for that chapter. This
> dives in a bit more into the specifics of ecommerce and also is written
> from a test-driven development point of view.
>



I've found also some little problem, the first is that they wrote this:

  def list
    @page_title = 'Listing books'
    sort_by = params[:sort_by]
    @book_pages, @books = paginate :books, :order => sort_by, :per_page
=> 10
  end

i think it's quite dangerous because the sort_by expose you to a sql
injection... ^_^

another that i've not understood is this:

  def show
    @book = Book.find(params[:id]) rescue nil
    return render(:text => "Not found", :status => 404) unless @book
    @page_title = @book.title
  end

why do a rescue nil and then a return unless.. ?
I think it's better this:

  def show
    @book = Book.find(params[:id])
  rescue
    render(:text => "Not found", :status => 404)
  else
    @page_title = @book.title
  end

What do you think?
Benjamin C. (Guest)
on 2006-12-31 17:52
(Received via mailing list)
On Dec 31, 2006, at 4:21 AM, nick wrote:

>> from a test-driven development point of view.
> sort_by, :per_page => 10
>    @page_title = @book.title
>    @page_title = @book.title
>  end
>
> What do you think?

Actually, just let Rails do the work:

def show
   @book = Book.find(params[:id])
   @page_title = @book.title
end

Rails will raise the RecordNotFound exception, which by default is
handled by rendering the 404 page.

--
Building an e-commerce site with Rails?
http://www.agilewebdevelopment.com/rails-ecommerce
nick (Guest)
on 2006-12-31 18:03
Benjamin C. wrote:
> On Dec 31, 2006, at 4:21 AM, nick wrote:
> Actually, just let Rails do the work:
>
> def show
>    @book = Book.find(params[:id])
>    @page_title = @book.title
> end
>
> Rails will raise the RecordNotFound exception, which by default is
> handled by rendering the 404 page.
>


Yeah, also...but i think that the 404 page is horrible :)
so if you have to redirect to a better page which inform you that there
isn't any product with that id, i think I'll use the 2nd and not the 1st
code.
Another thing that I've found horrible about the book is that they save
the cart+items in the database for each user (with a before filter in
the catalog), they're crazy (with a really lot of people that see the
site there's a query for each plus for each item (add/remove)...i think
it's better the solution on agile web with rails, they use just an
instance variable for the cart and not a database)
Dave T. (Guest)
on 2006-12-31 21:19
(Received via mailing list)
On Dec 31, 2006, at 10:03 AM, nick wrote:

> Another thing that I've found horrible about the book is that they
> save the cart+items in the database for each user (with a before
> filter in the catalog), they're crazy (with a really lot of people
> that see the site there's a query for each plus for each item (add/
> remove)...i think it's better the solution on agile web with rails,
> they use just an instance variable for the cart and not a database)

Well, to be fair.... you have to store the cart somewhere. In AWDwR,
I store the cart in the session, just because I want to illustrate
how to do that. But session data is still persisted between requests,
typically in the database in a production application. So there's
still a database access on each incoming request to fetch this
session data.


Dave
nick (Guest)
on 2007-01-01 01:40
Dave T. wrote:
> On Dec 31, 2006, at 10:03 AM, nick wrote:
>
> Well, to be fair.... you have to store the cart somewhere. In AWDwR,
> I store the cart in the session, just because I want to illustrate
> how to do that. But session data is still persisted between requests,
> typically in the database in a production application. So there's
> still a database access on each incoming request to fetch this
> session data.
>
>
> Dave

i thought that the session data was stored in the pc ram and not
directly in a database :|
seth b. (Guest)
on 2007-01-01 02:46
(Received via mailing list)
I'd echo most people's comments on this thread.

Grab the Ruby "pickaxe" book and the Agile book, and read through those.

Grab a copy of Substruct, and go through the source...

http://dev.subimage.com/projects/substruct


On 12/29/06, singh <removed_email_address@domain.invalid> wrote:
>
>
>
> >
>


--
--------------------
seth at subimage interactive
-----
http://www.subimage.com
http://sublog.subimage.com
-----
http://www.getcashboard.com
http://dev.subimage.com/projects/substruct
Dave T. (Guest)
on 2007-01-01 02:48
(Received via mailing list)
On Dec 31, 2006, at 5:40 PM, nick wrote:

>> Well, to be fair.... you have to store the cart somewhere. In AWDwR,
>> I store the cart in the session, just because I want to illustrate
>> how to do that. But session data is still persisted between requests,
>> typically in the database in a production application. So there's
>> still a database access on each incoming request to fetch this
>> session data.
>> Dave
>
> i thought that the session data was stored in the pc ram and not
> directly in a database :|


There is an option to store sessions in memory, but it's generally a
bad idea. In particular, it limits you to running just one
application process, and you lose session data if you restart that
process.


Dave
singh (Guest)
on 2007-01-01 15:35
(Received via mailing list)
Thanks all for your very valuable comments. I have decided to dive in
and study things you pointed at. Hope everything works out fine.

Thanks

Singh
nick (Guest)
on 2007-01-01 15:47
Dave T. wrote:
>
> There is an option to store sessions in memory, but it's generally a
> bad idea. In particular, it limits you to running just one
> application process, and you lose session data if you restart that
> process.
>
>
> Dave


Ok, thanks...now I've to remember that every access to session is a
query to the db... :)
Dave T. (Guest)
on 2007-01-01 16:27
(Received via mailing list)
On Jan 1, 2007, at 7:47 AM, nick wrote:

>
> Ok, thanks...now I've to remember that every access to session is a
> query to the db... :)

No, that's not the case.

At the start of the processing of a request, if that request contains
a session key, then session data corresponding to that key will be
read from the database. At most one database read per incoming
request will occur to load up session data. These will be a
corresponding write to save the session data away at the end of
request processing. (All this assumes you're using the database to
store session information.)

This generally isn't something to worry about: it just happens. If
you get to the point where these two database accesses are a
bottleneck (and you'd probably have to have a seriously heavily used
application for this to be the case) then you can switch session
storage strategies very easily.


Regards


Dave T.
nick (Guest)
on 2007-01-01 16:39
Dave T. wrote:
> On Jan 1, 2007, at 7:47 AM, nick wrote:
>
> No, that's not the case.
>
> At the start of the processing of a request, if that request contains
> a session key, then session data corresponding to that key will be
> read from the database. At most one database read per incoming
> request will occur to load up session data. These will be a
> corresponding write to save the session data away at the end of
> request processing. (All this assumes you're using the database to
> store session information.)
>
> This generally isn't something to worry about: it just happens. If
> you get to the point where these two database accesses are a
> bottleneck (and you'd probably have to have a seriously heavily used
> application for this to be the case) then you can switch session
> storage strategies very easily.
>
>
> Regards
>
>
> Dave T.


clear :)
now 2 more queries it's acceptable, and i think also in the future ;)
thanks
Benjamin C. (Guest)
on 2007-01-01 17:45
(Received via mailing list)
On Dec 31, 2006, at 8:03 AM, nick wrote:

>
> they use just an instance variable for the cart and not a database)
>

Of course you can redefine the handling of the RecordNotFound
exception per controller, so you could have a custom 404 message for
products not being found and still use the short method I suggested.

--
Building an e-commerce site with Rails?
http://www.agilewebdevelopment.com/rails-ecommerce
This topic is locked and can not be replied to.