Hi! I''m planning a booking system in rails, and I have the following issue: There will be room_types. I can implement this with STI in the rooms table, or with a separate table room_types. Each room type will have its special features. For example, a double room can be: -- Posted via http://www.ruby-forum.com/.
Hi! I''m planning a booking system in rails, and I have the following issue: There will be room_types. I can implement this with STI in the rooms table, or with a separate table room_types. Each room type will have its special features. For example: Room::SingleRoom # For 1 person Room::DoubleRoom # Simply for 2 people Room::DoubleRoom::SingleDoubleRoom # If only for 1 person will be cheaper Room::DoubleRoom::ExtraBedDoubleRoom # 3 people can use it (more expensive) Room::Apartment # For example, between 4-6 people, with different prices each etc... There is another approach, with a room_types table. It can take care of the capacities of the different rooms, allowing the customers to search. The table structure can be something like: name: the RoomType name default_capacity: The mainly used capacity (2 In case of ExtraBedDoubleRoom) maximum_capacity: The room allows more people (3 In case of ExtraBedDoubleRoom) minimum_capacity: If the customer uses this type of room but with a value lesser than this, will pay the price assigned to this minimum (2 In case of ExtraBedDoubleRoom) Remember that the system must be searchable, so the typical STI solution doesn''t fit well, since I must then specify the capacities in the code! Some kind of hybrid makes more sense to me. Is there any other approach? How do you would do it? Thanks! -- Posted via http://www.ruby-forum.com/.
Sorry, but I used ruby-forum to post, and used the TAB key and then space, so i submitted by accident :S. Please, read the 10.minutes.from_now post ^^ -- Posted via http://www.ruby-forum.com/.
Rodrigo What about using tags? Alain
Rodrigo Alvarez wrote:> Hi! > > I''m planning a booking system in rails, and I have the following issue: > >i remembered seeing this (http://www.solunas.org) when I saw your question - might be worth a look -- Mike Gilbert email : mike@xlcrs.com Technical Director fax : +353 68 470 01 XL CRS mobile: +353 87 677 2055 Lisselton phone : +353 68 470 10 Listowel Co. Kerry MSM : mikegilbert@hotmail.com Ireland Y!M : mike_j_gilbert@yahoo.com
I am about to embark on a project to implement an entire Information system underpinning the entire operations of a company. In order to heavily enforce security (be strictly defining what a model can do in one app, and not in another) I am planning to implement two rails apps. One will be the customer facing website with booking engine, the other will be a secure administration area (probably over HTTPS) with a lot more functionality but less of the fancy graphics. Can I put these two apps on top of the same database without causing any massive problems? Does anyone have any experience of this? David
David Smalley wrote:> I am about to embark on a project to implement an entire Information > system underpinning the entire operations of a company. > > In order to heavily enforce security (be strictly defining what a > model can do in one app, and not in another) I am planning to > implement two rails apps. One will be the customer facing website > with booking engine, the other will be a secure administration area > (probably over HTTPS) with a lot more functionality but less of the > fancy graphics. > > Can I put these two apps on top of the same database without causing > any massive problems?Assuming that one application is read-only (mostly) and the other read-write, which seems to be what you are indicating this shouldn''t have any more problems than a single app system. I''m not sure if the decision to split the project into two apps is really a good one. You could build a single app with multiple front ends depending on who is accessing the site. I''ve built an online shop before, in PHP, where the system had three independant front-ends, anonymous browsing, trade customer, administrator. I imagine if I had built that site in Rails it would have been a lot easier too :)> Does anyone have any experience of this? > > David > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
On 17 Feb 2006, at 14:37, Dominic Marks wrote:> Assuming that one application is read-only (mostly) and the other > read-write, which seems to be what you are indicating this shouldn''t > have any more problems than a single app system.The problem will come in that users can edit their details/make a booking etc. in one app. but staff could be accessing the same data simultaneously (theoretically), although due to the number of customers and the frequency of their interaction this might not happen a lot.> > I''m not sure if the decision to split the project into two apps is > really a good one.The problem is that it is critical that features exposed to one set of users are never even possibly accessible by the other users. This is because the app is *running* their business. The customer facing app is literally for bookings and marketing information. I guess in *theory* if i was using acts_as_authenticated with a Role based authentication systems then I could ensure that end users were never able to receive a "staff" role.
David Smalley wrote:> > On 17 Feb 2006, at 14:37, Dominic Marks wrote: >> Assuming that one application is read-only (mostly) and the other >> read-write, which seems to be what you are indicating this shouldn''t >> have any more problems than a single app system. > > The problem will come in that users can edit their details/make a > booking etc. in one app. but staff could be accessing the same data > simultaneously (theoretically), although due to the number of > customers and the frequency of their interaction this might not > happen a lot.How do you manage the possibility that two staff could be modifying the same data in the admin app? Concurrent access of data is a problem even if you have a single app.>> >> I''m not sure if the decision to split the project into two apps is >> really a good one. > > The problem is that it is critical that features exposed to one set > of users are never even possibly accessible by the other users. This > is because the app is *running* their business. The customer facing > app is literally for bookings and marketing information. > > I guess in *theory* if i was using acts_as_authenticated with a Role > based authentication systems then I could ensure that end users were > never able to receive a "staff" role. > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Dominic
> > How do you manage the possibility that two staff could be modifying > the same data in the admin app? Concurrent access of data is a problem > even if you have a single app.Does anyone know of a way that rails can handle this? Is it possible to lock a record and then rescue any other attempt to access with a custom error and redirect? David
http://ar.rubyonrails.com/classes/ActiveRecord/Locking.html On 2/17/06, David Smalley <david.smalley.lists@googlemail.com> wrote:> > > > How do you manage the possibility that two staff could be modifying > > the same data in the admin app? Concurrent access of data is a problem > > even if you have a single app. > > Does anyone know of a way that rails can handle this? Is it possible > to lock a record and then rescue any other attempt to access with a > custom error and redirect? > > David > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
On Feb 17, 2006, at 6:30 AM, David Smalley wrote:> I am about to embark on a project to implement an entire > Information system underpinning the entire operations of a company. > > In order to heavily enforce security (be strictly defining what a > model can do in one app, and not in another) I am planning to > implement two rails apps. One will be the customer facing website > with booking engine, the other will be a secure administration area > (probably over HTTPS) with a lot more functionality but less of the > fancy graphics. > > Can I put these two apps on top of the same database without > causing any massive problems? > > Does anyone have any experience of this? > > DavidDavid- I do this for the newspaper web site I built. The public facing app is read only. There are three other rails apps on our intranet that connect to the same db and models for admin tasks. One for our survey system, one for the cms admin system and one for the circulation admin system. I haven''t run into any problems doing it this way at all yet. It works great because the three internal admin apps are not available outside out office LAN and so they have an extra layer of security right there. The model files are in the main public facing applications app/ models directory. the other admin apps symlink the model definitions they need into their own apps tree. This way i only make changes to the models in one place to share between all four apps. You should use a lock_version column in all your shared database tables that can get accessed by multiple apps. This way you don''t get stale objects. This technique actually works very well. You could also put this all in one application, but my app got too big and I found it much easier to develop a standalone rails app for each specific admin section then putting it all in one app tree. Here is the site: http://yakimaherald.com Cheers- -Ezra Zygmuntowicz Yakima Herald-Republic WebMaster http://yakimaherald.com 509-577-7732 ezra@yakima-herald.com
You could also package the shared code as a plugin or engine, and use SVN externals to share that package between both applications. - james On 2/17/06, Ezra Zygmuntowicz <ezra@yakima-herald.com> wrote:> > On Feb 17, 2006, at 6:30 AM, David Smalley wrote: > > > I am about to embark on a project to implement an entire > > Information system underpinning the entire operations of a company. > > > > In order to heavily enforce security (be strictly defining what a > > model can do in one app, and not in another) I am planning to > > implement two rails apps. One will be the customer facing website > > with booking engine, the other will be a secure administration area > > (probably over HTTPS) with a lot more functionality but less of the > > fancy graphics. > > > > Can I put these two apps on top of the same database without > > causing any massive problems? > > > > Does anyone have any experience of this? > > > > David > > > David- > > I do this for the newspaper web site I built. The public facing app > is read only. There are three other rails apps on our intranet that > connect to the same db and models for admin tasks. One for our survey > system, one for the cms admin system and one for the circulation > admin system. I haven''t run into any problems doing it this way at > all yet. It works great because the three internal admin apps are not > available outside out office LAN and so they have an extra layer of > security right there. > > The model files are in the main public facing applications app/ > models directory. the other admin apps symlink the model definitions > they need into their own apps tree. This way i only make changes to > the models in one place to share between all four apps. You should > use a lock_version column in all your shared database tables that can > get accessed by multiple apps. This way you don''t get stale objects. > This technique actually works very well. You could also put this all > in one application, but my app got too big and I found it much easier > to develop a standalone rails app for each specific admin section > then putting it all in one app tree. > > Here is the site: http://yakimaherald.com > > Cheers- > -Ezra Zygmuntowicz > Yakima Herald-Republic > WebMaster > http://yakimaherald.com > 509-577-7732 > ezra@yakima-herald.com > > > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- * J * ~
On 17 Feb 2006, at 17:39, Ezra Zygmuntowicz wrote:> > The model files are in the main public facing applications app/ > models directory. the other admin apps symlink the model > definitions they need into their own apps tree. This way i only > make changes to the models in one place to share between all four > apps.I was thinking about using the model security plugin to protect models that would never need write access to the db, so I''d probably have to keep my models seperate. I wouldn''t anticipate this this would be an issue (but might slightly violate DRY)> You should use a lock_version column in all your shared database > tables that can get accessed by multiple apps. This way you don''t > get stale objects. This technique actually works very well.Can Rails handle an attempt to edit a locked object before someone tries to hit save. ie. when someone opens up an object that someone else is already editing, can they be notified via a flash or just not permitted to edit. Or will I have to handle the stale object error and inform the user what has happened? In an ideal world, the app would inform the user trying to edit a locked object that the current object was read only and they would get a button to attempt a reload of the page. David
Dominic Marks wrote:> David Smalley wrote: > >>I am about to embark on a project to implement an entire Information >>system underpinning the entire operations of a company. >> >>In order to heavily enforce security (be strictly defining what a >>model can do in one app, and not in another) I am planning to >>implement two rails apps. One will be the customer facing website >>with booking engine, the other will be a secure administration area >>(probably over HTTPS) with a lot more functionality but less of the >>fancy graphics. >> >>Can I put these two apps on top of the same database without causing >>any massive problems? > > > Assuming that one application is read-only (mostly) and the other > read-write, which seems to be what you are indicating this shouldn''t > have any more problems than a single app system.Another thing you can do for some added security is check the IP address of the user and only allow local users to access a page with something like if ((@request.remote_addr =~ /^192\.168\./) != false) then < do stuff > else < error page > end in ether the controllers or in the views.> > I''m not sure if the decision to split the project into two apps is > really a good one. You could build a single app with multiple front > ends depending on who is accessing the site. I''ve built an online shop > before, in PHP, where the system had three independant front-ends, > anonymous browsing, trade customer, administrator. > > I imagine if I had built that site in Rails it would have been a lot > easier too :) > > >>Does anyone have any experience of this? >> >>David
On Feb 19, 2006, at 3:20 PM, Neil Dugan wrote:> Dominic Marks wrote: >> David Smalley wrote: >>> I am about to embark on a project to implement an entire Information >>> system underpinning the entire operations of a company. >>> >>> In order to heavily enforce security (be strictly defining what a >>> model can do in one app, and not in another) I am planning to >>> implement two rails apps. One will be the customer facing website >>> with booking engine, the other will be a secure administration area >>> (probably over HTTPS) with a lot more functionality but less of the >>> fancy graphics. >>> >>> Can I put these two apps on top of the same database without causing >>> any massive problems? >> Assuming that one application is read-only (mostly) and the other >> read-write, which seems to be what you are indicating this shouldn''t >> have any more problems than a single app system. > > Another thing you can do for some added security is check the IP > address of the user and only allow local users to access a page > with something like > > if ((@request.remote_addr =~ /^192\.168\./) != false) then > < do stuff > > else > < error page > > endWouldn''t it make more sense to use an application.rb helper (available everywhere): def request_is_local? @request.remote_addr =~ /^192\.168\./) end Then the controllers can simply use: if request_is_local? < do stuff > else < error page > end DRY + readability == the right way Another improvement would be to use before_filter to make the call to request_is_local? Perhaps even better is to override the built-in local_request? then use that in the before_filter, which gives you the advantage of Rails knowing a request is local and responding appropriately in the case of errors. Overriding a built-in is a bit much for a list response, so here''s the URL to learn more: http://api.rubyonrails.com/classes/ActionController/Rescue.html#M000043> I''m not sure if the decision to split the project into two apps is > really a good one. You could build a single app with multiple front > ends depending on who is accessing the site.Yes, I''d agree here. No need for separate applications. Put the secure stuff in it''s own controllers and own view, protect it in several ways (user/password/role), HTTPS, IP verification, etc. and DRY on the however you choose to protect it via before_filter so that nothing in the administration controller(s) "slips through the cracks." -- -- Tom Mornini
On 17 Feb 2006, at 10:05 am, Rodrigo Alvarez wrote:> I''m planning a booking system in rails, and I have the following > issue: > > There will be room_types. I can implement this with STI in the rooms > table, or with a separate table room_types. > > Remember that the system must be searchable, so the typical STI > solution > doesn''t fit well, since I must then specify the capacities in the > code! > Some kind of hybrid makes more sense to me. Is there any other > approach? > How do you would do it?I''d go with your room_types idea:> name: the RoomType name > default_capacity: The mainly used capacity (2 In case of > ExtraBedDoubleRoom) > maximum_capacity: The room allows more people (3 In case of > ExtraBedDoubleRoom) > minimum_capacity: If the customer uses this type of room but with a > value lesser than this, will pay the price assigned to this minimum (2 > In case of ExtraBedDoubleRoom)There''s no reason that these different room types have to be different classes in your Ruby code. As you point out, you would end up hard-coding the room types and capacities into the application. If they ever want to change the room types, or add/delete one (and you know they will!), you''ll have to change the code. Using a room_types table makes this kind of thing easy. The other way to think about is this: you only need to use STI if the different classes are going to behave in different ways. The classic example is ''Employee < Person'' and ''Manager < Person''. These things are both obviously people, so they''ll have some common things like full_name(). But in the day-to-day activities of your application, they''ll be *doing* fundamentally different things (your Managers might manage() some projects, while your Employees might carry_out() some Tasks and be managed_by(pointy_haired_boss).) That''s why you want different Ruby classes for them. With Rooms, on the other hand, each of your different ''types'' of room (double rooms, single rooms, double rooms with an extra bed, etc.) will have a few *properties* that are different (i.e. max_capacity of 1 or 2 or 3), but they will all *behave* in basically the same way. They''ll have_many bookings placed against them, they''ll be available? (tomorrow), etc. There''s no benefit to having different classes for the different types of room. Chris