True. But for the most part it doesn't make sense from a standpoint of clarity and natural language. Let's say you have model Product and you want a service object that will handle pricing on some complex criteria (geolocation, color, shipping, moonphase, etc). It would be a good candidate for a service object ProductPricingService. You wouldn't just call it Price or Pricing. First of all it's ambigious. Pricing of what? Products that you sell? Pricing you get from vendors? Pricing of gas today? And if you were to argue that this Service object could be used by many models, then you are defeating the purpose of Service Object. I'm exaggerating of course. But the whole point is to create clear and maintainable code. So while you can save some keystrokes by naming it Price, it's much more clear to another person ( and you in 5 months) if you name it ProductPricingService.
Q2
For instance let's say you have model Product. you have methods like :
If this is the only method that deals with labels you have and it's that simple than creating a Service object is an overkill. However if your method becomes complex or you find that you need multiple method for related things:
Here is how I handle Simple_Form errors and foundation 4 ( by default I prefer to use field labels as prepends. Enjoy
Q1
True. But for the most part it doesn't make sense from a standpoint of clarity and natural language. Let's say you have model Product and you want a service object that will handle pricing on some complex criteria (geolocation, color, shipping, moonphase, etc). It would be a good candidate for a service object ProductPricingService. You wouldn't just call it Price or Pricing. First of all it's ambigious. Pricing of what? Products that you sell? Pricing you get from vendors? Pricing of gas today? And if you were to argue that this Service object could be used by many models, then you are defeating the purpose of Service Object. I'm exaggerating of course. But the whole point is to create clear and maintainable code. So while you can save some keystrokes by naming it Price, it's much more clear to another person ( and you in 5 months) if you name it ProductPricingService.
Q2
For instance let's say you have model Product. you have methods like :
If this is the only method that deals with labels you have and it's that simple than creating a Service object is an overkill. However if your method becomes complex or you find that you need multiple method for related things:
You might want to move that into a service like so:
And now just do this
Hope that clears things up a bit
Ryan - first 2 layouts don't work at all of for me. divs are layered on top of each other, and it's impossible to use.
Also everything is aligned to the left ( but according to your video it should be centered). Doesn't matter how I resize my browser.
Here are screenshots of how it looks on my screen:
Skewed Layout 1
Skewed Layout 2
Skewed Layout 3
I'm using FireFox 4 on Windows XP sp3, on a 23 in monitor using 1980 x 1080 resolution.
Other than that I like new design - it's even more convenient than before.
EDIT:
Everything looks fine in latest Chrome & Safari. IE 8 seems to be ok too.