Where would be the best place to put constants that I need to access in all my views? I have a few arrays like this: PRIORITY = [''Not Set'', ''Highest'', ''High'', ''Medium'', ''Normal'', ''Low''] where the priority field in my model is an int from 0-5 in the actual db. I just want to be able to use this array in my views so I can show the priority instead of the integer stored in the db. Where is the best place to put arrays and other constants like this so they are available in all my views? Thanks- -Ezra
Robert Mannl wrote:> Since RAILS encourages DB Design so much I have a question on > designing databases: > > I have this tables: >What does this have to do with "Where to put Constants?" thread? Why are people replying to a post to start a new thread? Is it so difficult to click the Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org link these days? - Adam
> Now my question: is it correct what DB Designer is trying to do from a > DB normalization perspective? It''d let me check which invoice_items > belong to a customer easily, but I''ve never seen this before. And if it > follows normalization standards: does RAILS support this kind of > normalization?I think you should stop and think. Suppose you''re going to buy a bunch of things at the store, you choose your favourite butter, biscuits and pick up some bottles of milk. You pay them, they release an invoice to you and everybody is happy. Who cares to track you by item? ps. why the invoices table is so empty? -- Lawrence http://www.oluyede.org/blog
Ezra Zygmuntowicz wrote:> Where would be the best place to put constants that I need to access > in all my views? I have a few arrays like this: > PRIORITY = [''Not Set'', ''Highest'', ''High'', ''Medium'', ''Normal'', ''Low''] > where the priority field in my model is an int from 0-5 in the actual > db. I just want to be able to use this array in my views so I can > show the priority instead of the integer stored in the db. Where is > the best place to put arrays and other constants like this so they > are available in all my views?I would put these in a helper. def priority_string( value ) Priorities = %w( Blah blah ) return Priorities[ value ] unless ( value < 0 or value >Priorities.size ) ''Unknown'' end This way if priorities are added or whatever there is just one place to fix them. You can also do checks, etc.. But if I were you, I would make the controller do all of the work and translate the value to a string before passing it on to the view. Of course, if you use @something = Model.find(X), which I don''t agree with, then this might be a little bit more of a problem and the helper way might be the only way :) - Adam
Robert Mannl wrote:>> What does this have to do with "Where to put Constants?" thread? Why are >> people replying to a post to start a new thread? Is it so difficult to >> click the Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org link these days? >> >> - Adam >> >> > I''m new to mailing lists. How did you notice? Does it say that in the > headers somewhere? Didn''t know that sorry. I''ll compose a new mail > from now on. >There is a thread generated. The headers have this for your email, References: <73651C8E-0B2A-4260-97B2-A2D40640FF90-gdxLOakOTQ9oetBuM9ipNAC/G2K4zDHf@public.gmane.org> <42880672.8020908-x0ewNDjvrP1m7dl9lghbdg@public.gmane.org> <42878BE2.3080004-+878OnfSgr5BDgjK7y7TUQ@public.gmane.org> In-Reply-To: <42878BE2.3080004-+878OnfSgr5BDgjK7y7TUQ@public.gmane.org> The References: is the thread, and the other is your position in the thread. Thunderbird (what you seem to be using as well), as well as almost all other mail software, uses this information to know what "conversation" the email belongs to. - Adam
On 16.5.2005, at 06:01, Robert Mannl wrote:>> > Well, maybe it''s something like: "Ohh someone bought a HD-TV > yesterday, who was it?"You can track the customer via invoices table anyway: the HD-TV belongs to an invoice. The invoice belongs to a customer. That''s who the buyer was. There''s no need to tie an item directly to a customer. //jarkko -- Jarkko Laine http://jlaine.net http://odesign.fi _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
On Sunday 15 May 2005 13:23, Ezra Zygmuntowicz wrote:> Where would be the best place to put constants that I need to access > in all my views? I have a few arrays like this: > PRIORITY = [''Not Set'', ''Highest'', ''High'', ''Medium'', ''Normal'', ''Low''] > where the priority field in my model is an int from 0-5 in the actual > db. I just want to be able to use this array in my views so I can > show the priority instead of the integer stored in the db. Where is > the best place to put arrays and other constants like this so they > are available in all my views?You might want to use Priority class and do something such as class MyModel < AR::Base def priority Priority.new(super()) end def priority=(p) super(p.to_i) end end You can use Composites to accomplish the same thing. Priority comparison could be implemented with class Priority def <=>(other) self.to_i <=> other.to_i end end Of course, such an approach may be over building in this case, but I figured I''d point it out... -- Nicholas Seckar aka. Ulysses
Since RAILS encourages DB Design so much I have a question on designing databases: I have this tables: customers - id - name invoices (has_many :invoice_items) - id - customer_id invoice_items (the different products on one invoice; belongs_to :invoice) - id - invoice_id - description (description of one item/product on the invoice) - value (value of the item/product) Now I''m using fabForces'' DBDesigner (great, free tool. check it out), and it insists on adding another foreign key column into the invoice table: "customer_id". So I want to design my invoice_items table like I said above, but DBDesigner wants to do it like this: invoice_items - id - invoice_id - customer_id <------- this is what DBDesigner is adding - description (description of the product) - value (value of the product) Now my question: is it correct what DB Designer is trying to do from a DB normalization perspective? It''d let me check which invoice_items belong to a customer easily, but I''ve never seen this before. And if it follows normalization standards: does RAILS support this kind of normalization? Thanks, Rob
> > >What does this have to do with "Where to put Constants?" thread? Why are >people replying to a post to start a new thread? Is it so difficult to >click the Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org link these days? > >- Adam > >I''m new to mailing lists. How did you notice? Does it say that in the headers somewhere? Didn''t know that sorry. I''ll compose a new mail from now on. Rob
Hi Lawrence,>I think you should stop and think. Suppose you''re going to buy a bunch >of things at the store, you choose your favourite butter, biscuits and >pick up some bottles of milk. You pay them, they release an invoice to >you and everybody is happy. Who cares to track you by item? > > >Well, maybe it''s something like: "Ohh someone bought a HD-TV yesterday, who was it?" But yeah, it doesn''t make so very much sense.>ps. why the invoices table is so empty? >This was just a quick design. What''s missing? The total price? Thanks, Rob
> There''s no need to tie an item directly to a customer.Ok, thanks everyone :) Rob
On 5/15/05, Robert Mannl <ro-x0ewNDjvrP1m7dl9lghbdg@public.gmane.org> wrote:> >What does this have to do with "Where to put Constants?" thread? Why are > >people replying to a post to start a new thread? Is it so difficult to > >click the Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org link these days? > > > I''m new to mailing lists. How did you notice? Does it say that in the > headers somewhere? Didn''t know that sorry. I''ll compose a new mail from > now on.It looks as if mailing list archives, such as Gmane, capture threads by using fields that email users don''t normally pay attention to (probably References: and In-Reply-To:). This is something that I hadn''t personally considered. I''m know that I''ve attempted to start a new thread by choosing to respond to an existing message and then changing the subject. I won''t be doing that again! If the problem is wide-spread, maybe list owners might consider making this fact well known through a FAQ or periodic emails to the list. It''s too bad that the popular email clients don''t warn users about this and allow provide the user with a simple method to remove the offending fields when the subject line is radically changed. - Dennis -- "Thanks to the crew of rocketscientists.ca for the gmail invitation!" http://www.rocketscientists.ca/