As well as discussions and questions I've seen on this group so far.
Controllers
----------------------------------------
1. Merb.logger.debug - recommend dropping the "Merb.", it's repetitive
to look at and type
2. before/after - recommend using before_filter/after_filter since the
functionality is the same
3. This looks awkward
def index
render('', :layout => :application)
end
Can we add a render() keyword for clarity?
render :nothing, :layout => :application
4. The provides() vs only_provides() difference is confusing, just
because of the method inconsistency vs the rest of Merb. I don't have
a suggestion yet that would be a workable method signature.
Helpers
----------------------------------------
1. I'm not sure if Ngoc's port is accurate, but why are the helpers
injecting into Merb's GlobalHelpers? Seems monkey-patchy. If Ngoc's
port is accurate, can't Merb do this under the covers, rather than
exposing it? That would clean up the interface, and offer protection
for Merb in case Merb's internal API needs to change in the future.
Views
----------------------------------------
1. Provide a url_for wrapper around url().
2. Provide a heckuva Wiki page for everything else :-)
Configuration
----------------------------------------
1. Add support for the Rails-style initializers/ directory. This is a
simple nicety that will be a "Why don't my initializers work?"
question otherwise (already popped up in this google group)
2. Standardize the "merb more" and "merb plugin" names to all use "_",
ie, "merb_assets", "merb_cache", etc. Otherwise it'll be another
support timesink of answering, "No, it's merb *dash* cache, but merb
*underscore* paginate".
3. Change the default router.rb file to use "|map|" like Rails.
Everyone's used to "map.resources". Yes, people can change it
themselves, but providing it the same as people are used to will save
support questions.
> As well as discussions and questions I've seen on this group so far.
> Controllers > ---------------------------------------- > 1. Merb.logger.debug - recommend dropping the "Merb.", it's repetitive > to look at and type
> 2. before/after - recommend using before_filter/after_filter since the > functionality is the same
> 3. This looks awkward
> def index > render('', :layout => :application) > end
> Can we add a render() keyword for clarity?
> render :nothing, :layout => :application
> 4. The provides() vs only_provides() difference is confusing, just > because of the method inconsistency vs the rest of Merb. I don't have > a suggestion yet that would be a workable method signature.
> Helpers > ---------------------------------------- > 1. I'm not sure if Ngoc's port is accurate, but why are the helpers > injecting into Merb's GlobalHelpers? Seems monkey-patchy. If Ngoc's > port is accurate, can't Merb do this under the covers, rather than > exposing it? That would clean up the interface, and offer protection > for Merb in case Merb's internal API needs to change in the future.
> Views > ---------------------------------------- > 1. Provide a url_for wrapper around url().
> 2. Provide a heckuva Wiki page for everything else :-)
> Configuration > ---------------------------------------- > 1. Add support for the Rails-style initializers/ directory. This is a > simple nicety that will be a "Why don't my initializers work?" > question otherwise (already popped up in this google group)
> 2. Standardize the "merb more" and "merb plugin" names to all use "_", > ie, "merb_assets", "merb_cache", etc. Otherwise it'll be another > support timesink of answering, "No, it's merb *dash* cache, but merb > *underscore* paginate".
> 3. Change the default router.rb file to use "|map|" like Rails. > Everyone's used to "map.resources". Yes, people can change it > themselves, but providing it the same as people are used to will save > support questions.
> 1. Merb.logger.debug - recommend dropping the "Merb.", it's repetitive > to look at and type
Then if someone has logger method or variable in the app, it will clash. If you want to save yourself some typing, use ctags/etags, Merb textmate bundle or IDE.
Wrappers IMO go into plugin — not every app our there, not every developer out there would need it.
I want to stress it again in this very same thread: if you want to make transition from Rails simple for people, write in depth tutorial and post it on Merbunity and help fix bugs. This is what's important, not making API exactly as in Rails. People who get off the rails hook usually know what they do and what they need.
I don't know if I was nice, this "lets make Rails out of Merb" thing seems insignificant to me. -- MK
I fully agree with Michael and Julian. Merb shouldn't feel like a Rails drop-in, just because it isn't.
I actually prefer render('') above render(:nothing), because you aren't returning nothing, you are returning an empty string, which looks a bit awkward because it is a bit awkward to return an empty response.
<michael.s.klis...@gmail.com> wrote: > 2008/5/28 Nate Wiger <nwi...@gmail.com>: >> 1. Merb.logger.debug - recommend dropping the "Merb.", it's repetitive >> to look at and type
> Then if someone has logger method or variable in the app, it will clash. > If you want to save yourself some typing, use ctags/etags, Merb textmate > bundle or IDE.
> Wrappers IMO go into plugin -- not every app our there, > not every developer out there would need it.
> I want to stress it again in this very same thread: if you want to > make transition from Rails simple for people, write in depth > tutorial and post it on Merbunity and help fix bugs. This is what's > important, not making API > exactly as in Rails. People who get off the rails hook usually know > what they do and what they need.
> I don't know if I was nice, this "lets make Rails out of Merb" thing > seems insignificant to me. > -- > MK
> 4. The provides() vs only_provides() difference is confusing, just > because of the method inconsistency vs the rest of Merb. I don't have > a suggestion yet that would be a workable method signature.
There are 3 methods: provides, only_provides, and does_not_provide. They each do exactly what they say. Obviously, I'm biased, since I wrote them, but I think they're perfect. :)
The nice thing about provides not overwriting the list is that you can do "provides :foo" in a parent class, then only "provides :bar" in the controllers that do :bar.
> 1. Provide a url_for wrapper around url().
I don't get this one. What would url_for do?
> 1. Add support for the Rails-style initializers/ directory. This is a > simple nicety that will be a "Why don't my initializers work?" > question otherwise (already popped up in this google group)
This one is a good example of a real philosophy difference. If you want to split up your application load process, you have complete control over init.rb ... Merb doesn't push you to do it any particular way. It would be trivial to add a few lines to support an initializers/ directory ... so since it's trivial, we choose not to do it. Trivial patches are sometimes a code smell...if it's trivial, maybe we don't need it at all.
> 2. Standardize the "merb more" and "merb plugin" names to all use "_", > ie, "merb_assets", "merb_cache", etc. Otherwise it'll be another > support timesink of answering, "No, it's merb *dash* cache, but merb > *underscore* paginate".
I think we need to have 1 final revisit of this one, and if we decide not to change, make a wiki page that explains why it is this way, and why we're not changing it.
> I'm not sure if Ngoc's port is accurate, but why are the helpers injecting into Merb's GlobalHelpers? Seems monkey-patchy.
Hi.
I am doing this because of the module architecture of this CMS, I want all the helpers to be horizontal: views of a controller/helper can call helpers of others. Notice that helpers of module xxx are prefixed with xxx_, ex: users_gravatar(user)
On Thu, May 29, 2008 at 12:03 AM, Jed Hurt <jed.h...@gmail.com> wrote: > On Wed, May 28, 2008 at 8:47 AM, Michael D. Ivey <michael.i...@gmail.com> > wrote:
>> It would be trivial to add a few lines to support an >> initializers/ directory ...
Sure. But it probably took more time to mention it in this thread than
it would just to integrate that into Merb.
Here's a scenario: Some people using Merb like "initializers", but
others decide "startups" is better. Now, some Merb plugins use a
startups/ directory, whereas others use initializers/. So now you have
two (or more!) ways that people have to learn... that have to be
documented, Wiki'ed, and answered in mailing lists such as this.
> I want to stress it again in this very same thread: if you want to
> make transition from Rails simple for people, write in depth
> tutorial and post it on Merbunity and help fix bugs.
I think you are underestimating the amount of a time that superficial
compatibility can save - in development, documentation, and support.
Writing a new framework is the fun part, but supporting it can be
hell, and your support timesinks are almost always seemingly inane
differences ("before" instead of "before_filter").
Putting on my manager hat, I'm a bit concerned by the tone of the
responses in this thread, and whether Merb will be properly
supported. I'm not trying to throw stones, but if you haven't had the
"joy" of supporting a large piece of software, used in ways you never
intended or even forsaw, I would urge you to rethink some of the
suggestions I made above.
4. The provides() vs only_provides() difference is confusing, just because of the method inconsistency vs the rest of Merb. I don't have a suggestion yet that would be a workable method signature.
Each of these methods are called with a list of symbols representing the formats to operate on.
2. before/after - recommend using before_filter/after_filter since the
> functionality is the same
I personally don't like before_filter I think before and after are easier to use. If it doesn't affect the code complexity and performances, I don't see a problem with adding an alias tho.
1. Provide a url_for wrapper around url().
url_for is really not something we have in Merb since we don't guess urls based on the attributes passed. Our url method isn't as smart but is very efficient.
2. Provide a heckuva Wiki page for everything else :-)
Totally agree on that one!
3. Change the default router.rb file to use "|map|" like Rails. Everyone's used to "map.resources". Yes, people can change it themselves, but providing it the same as people are used to will save support questions.
I think the reason because we use Merb::Router.prepare do |r| is because you are passing the router (r) not a map. Your routes will end up looking like that:
Merb::Router.prepare do |r| # RESTful routes
r.namespace :admin do |admin| admin.resources :content_owners admin.resources :publishers do |publisher| publisher.resources :assets publisher.resources :content_partners end admin.resources :users admin.resources :stats end end
it personally makes more sense to me. But maybe I didn't understand what you meant.
2. Standardize the "merb more" and "merb plugin" names to all use "_", ie, "merb_assets", "merb_cache", etc. Otherwise it'll be another support timesink of answering, "No, it's merb *dash* cache, but merb *underscore* paginate".
Yeah that became a bit of a mess. underscore was reserved to "not core" plugin and dash was for core supported stuff.... we might want to review that soon.
> As well as discussions and questions I've seen on this group so far.
> Controllers > ---------------------------------------- > 1. Merb.logger.debug - recommend dropping the "Merb.", it's repetitive > to look at and type
> 2. before/after - recommend using before_filter/after_filter since the > functionality is the same
> 3. This looks awkward
> def index > render('', :layout => :application) > end
> Can we add a render() keyword for clarity?
> render :nothing, :layout => :application
> 4. The provides() vs only_provides() difference is confusing, just > because of the method inconsistency vs the rest of Merb. I don't have > a suggestion yet that would be a workable method signature.
> Helpers > ---------------------------------------- > 1. I'm not sure if Ngoc's port is accurate, but why are the helpers > injecting into Merb's GlobalHelpers? Seems monkey-patchy. If Ngoc's > port is accurate, can't Merb do this under the covers, rather than > exposing it? That would clean up the interface, and offer protection > for Merb in case Merb's internal API needs to change in the future.
> Views > ---------------------------------------- > 1. Provide a url_for wrapper around url().
> 2. Provide a heckuva Wiki page for everything else :-)
> Configuration > ---------------------------------------- > 1. Add support for the Rails-style initializers/ directory. This is a > simple nicety that will be a "Why don't my initializers work?" > question otherwise (already popped up in this google group)
> 2. Standardize the "merb more" and "merb plugin" names to all use "_", > ie, "merb_assets", "merb_cache", etc. Otherwise it'll be another > support timesink of answering, "No, it's merb *dash* cache, but merb > *underscore* paginate".
> 3. Change the default router.rb file to use "|map|" like Rails. > Everyone's used to "map.resources". Yes, people can change it > themselves, but providing it the same as people are used to will save > support questions.
I prefer xxx_filter. If it is a filter then why not call it a filter? If you look at the log output, for every request you will see something like: {:action_time=>0.011294, :before_filters_time=>0.00018, :after_filters_time=>4.5e-05, :dispatch_time=>0.011568}
> underscore was reserved to "not core" plugin and dash was for core supported stuff.... we might want to review that soon
In Merb 2.0, things might go into or out of the core (who knows? :D). This might cause renaming problems.
On Thu, May 29, 2008 at 1:59 AM, Matt Aimonetti <mattaimone...@gmail.com> wrote: > Good listing Nate, thanks a lot.
> 4. The provides() vs only_provides() difference is confusing, just > because of the method inconsistency vs the rest of Merb. I don't have > a suggestion yet that would be a workable method signature.
> There's a number of methods to help make this not only easy, but flexible.
> provides - provides each of the given formats + :html > only_provides - only provides the supplied formats. It does not include the > default of :html or any other previously set formats. > does_not_provide - turns off responses for this format > clear_provides removes all response formats. You won't get very far in your > app if you use this in a controller. But it can be a handy spec'ing tool > reset_provides - resets the provided formats to the defaults. :html
> Each of these methods are called with a list of symbols representing the > formats to operate on.
>> 2. before/after - recommend using before_filter/after_filter since the >> functionality is the same
> I personally don't like before_filter I think before and after are easier to > use. If it doesn't affect the code complexity and performances, I don't see > a problem with adding an alias tho.
> 1. Provide a url_for wrapper around url().
> url_for is really not something we have in Merb since we don't guess urls > based on the attributes passed. Our url method isn't as smart but is very > efficient.
>> 2. Provide a heckuva Wiki page for everything else :-)
> Totally agree on that one!
> 3. Change the default router.rb file to use "|map|" like Rails. > Everyone's used to "map.resources". Yes, people can change it > themselves, but providing it the same as people are used to will save > support questions.
> I think the reason because we use Merb::Router.prepare do |r| is because you > are passing the router (r) not a map. Your routes will end up looking like > that:
> Merb::Router.prepare do |r| > # RESTful routes
> r.namespace :admin do |admin| > admin.resources :content_owners > admin.resources :publishers do |publisher| > publisher.resources :assets > publisher.resources :content_partners > end > admin.resources :users > admin.resources :stats > end > end
> it personally makes more sense to me. But maybe I didn't understand what you > meant.
> 2. Standardize the "merb more" and "merb plugin" names to all use "_", > ie, "merb_assets", "merb_cache", etc. Otherwise it'll be another > support timesink of answering, "No, it's merb *dash* cache, but merb > *underscore* paginate".
> Yeah that became a bit of a mess. underscore was reserved to "not core" > plugin and dash was for core supported stuff.... we might want to review > that soon.
> -Matt
> On 5/28/08, Nate Wiger <nwi...@gmail.com> wrote:
>> Based on the previous Merb / Rails compatibility thread here:
>> As well as discussions and questions I've seen on this group so far.
>> Controllers >> ---------------------------------------- >> 1. Merb.logger.debug - recommend dropping the "Merb.", it's repetitive >> to look at and type
>> 2. before/after - recommend using before_filter/after_filter since the >> functionality is the same
>> 3. This looks awkward
>> def index >> render('', :layout => :application) >> end
>> Can we add a render() keyword for clarity?
>> render :nothing, :layout => :application
>> 4. The provides() vs only_provides() difference is confusing, just >> because of the method inconsistency vs the rest of Merb. I don't have >> a suggestion yet that would be a workable method signature.
>> Helpers >> ---------------------------------------- >> 1. I'm not sure if Ngoc's port is accurate, but why are the helpers >> injecting into Merb's GlobalHelpers? Seems monkey-patchy. If Ngoc's >> port is accurate, can't Merb do this under the covers, rather than >> exposing it? That would clean up the interface, and offer protection >> for Merb in case Merb's internal API needs to change in the future.
>> Views >> ---------------------------------------- >> 1. Provide a url_for wrapper around url().
>> 2. Provide a heckuva Wiki page for everything else :-)
>> Configuration >> ---------------------------------------- >> 1. Add support for the Rails-style initializers/ directory. This is a >> simple nicety that will be a "Why don't my initializers work?" >> question otherwise (already popped up in this google group)
>> 2. Standardize the "merb more" and "merb plugin" names to all use "_", >> ie, "merb_assets", "merb_cache", etc. Otherwise it'll be another >> support timesink of answering, "No, it's merb *dash* cache, but merb >> *underscore* paginate".
>> 3. Change the default router.rb file to use "|map|" like Rails. >> Everyone's used to "map.resources". Yes, people can change it >> themselves, but providing it the same as people are used to will save >> support questions.
> I prefer xxx_filter. If it is a filter then why not call it a filter? > If you look at the log output, for every request you will see > something like: > {:action_time=>0.011294, :before_filters_time=>0.00018, > :after_filters_time=>4.5e-05, :dispatch_time=>0.011568}
> > underscore was reserved to "not core" plugin and dash was for core > supported stuff.... we might want to review that soon
> In Merb 2.0, things might go into or out of the core (who knows? :D). > This might cause renaming problems.
> Ngoc.
> On Thu, May 29, 2008 at 1:59 AM, Matt Aimonetti <mattaimone...@gmail.com> > wrote: > > Good listing Nate, thanks a lot.
> > 4. The provides() vs only_provides() difference is confusing, just > > because of the method inconsistency vs the rest of Merb. I don't have > > a suggestion yet that would be a workable method signature.
> > There's a number of methods to help make this not only easy, but > flexible.
> > provides - provides each of the given formats + :html > > only_provides - only provides the supplied formats. It does not include > the > > default of :html or any other previously set formats. > > does_not_provide - turns off responses for this format > > clear_provides removes all response formats. You won't get very far in > your > > app if you use this in a controller. But it can be a handy spec'ing tool > > reset_provides - resets the provided formats to the defaults. :html
> > Each of these methods are called with a list of symbols representing the > > formats to operate on.
> >> 2. before/after - recommend using before_filter/after_filter since the > >> functionality is the same
> > I personally don't like before_filter I think before and after are easier > to > > use. If it doesn't affect the code complexity and performances, I don't > see > > a problem with adding an alias tho.
> > 1. Provide a url_for wrapper around url().
> > url_for is really not something we have in Merb since we don't guess urls > > based on the attributes passed. Our url method isn't as smart but is very > > efficient.
> >> 2. Provide a heckuva Wiki page for everything else :-)
> > Totally agree on that one!
> > 3. Change the default router.rb file to use "|map|" like Rails. > > Everyone's used to "map.resources". Yes, people can change it > > themselves, but providing it the same as people are used to will save > > support questions.
> > I think the reason because we use Merb::Router.prepare do |r| is because > you > > are passing the router (r) not a map. Your routes will end up looking > like > > that:
> > Merb::Router.prepare do |r| > > # RESTful routes
> > r.namespace :admin do |admin| > > admin.resources :content_owners > > admin.resources :publishers do |publisher| > > publisher.resources :assets > > publisher.resources :content_partners > > end > > admin.resources :users > > admin.resources :stats > > end > > end
> > it personally makes more sense to me. But maybe I didn't understand what > you > > meant.
> > 2. Standardize the "merb more" and "merb plugin" names to all use "_", > > ie, "merb_assets", "merb_cache", etc. Otherwise it'll be another > > support timesink of answering, "No, it's merb *dash* cache, but merb > > *underscore* paginate".
> > Yeah that became a bit of a mess. underscore was reserved to "not core" > > plugin and dash was for core supported stuff.... we might want to review > > that soon.
> > -Matt
> > On 5/28/08, Nate Wiger <nwi...@gmail.com> wrote:
> >> Based on the previous Merb / Rails compatibility thread here:
> >> As well as discussions and questions I've seen on this group so far.
> >> Controllers > >> ---------------------------------------- > >> 1. Merb.logger.debug - recommend dropping the "Merb.", it's repetitive > >> to look at and type
> >> 2. before/after - recommend using before_filter/after_filter since the > >> functionality is the same
> >> 3. This looks awkward
> >> def index > >> render('', :layout => :application) > >> end
> >> Can we add a render() keyword for clarity?
> >> render :nothing, :layout => :application
> >> 4. The provides() vs only_provides() difference is confusing, just > >> because of the method inconsistency vs the rest of Merb. I don't have > >> a suggestion yet that would be a workable method signature.
> >> Helpers > >> ---------------------------------------- > >> 1. I'm not sure if Ngoc's port is accurate, but why are the helpers > >> injecting into Merb's GlobalHelpers? Seems monkey-patchy. If Ngoc's > >> port is accurate, can't Merb do this under the covers, rather than > >> exposing it? That would clean up the interface, and offer protection > >> for Merb in case Merb's internal API needs to change in the future.
> >> Views > >> ---------------------------------------- > >> 1. Provide a url_for wrapper around url().
> >> 2. Provide a heckuva Wiki page for everything else :-)
> >> Configuration > >> ---------------------------------------- > >> 1. Add support for the Rails-style initializers/ directory. This is a > >> simple nicety that will be a "Why don't my initializers work?" > >> question otherwise (already popped up in this google group)
> >> 2. Standardize the "merb more" and "merb plugin" names to all use "_", > >> ie, "merb_assets", "merb_cache", etc. Otherwise it'll be another > >> support timesink of answering, "No, it's merb *dash* cache, but merb > >> *underscore* paginate".
> >> 3. Change the default router.rb file to use "|map|" like Rails. > >> Everyone's used to "map.resources". Yes, people can change it > >> themselves, but providing it the same as people are used to will save > >> support questions.
> You're also missing the point that "logger.debug" is not only easier > on the eyes, but One Less Thing to have to explain is different.
"One Less Thing to have to explain is different" isn't a compelling argument for the core team. I understand that you wish it were, but it just isn't. We're not building Merb to be a "Better Rails" or any kind of "n Rails" (for your favorite values of n).
We're building Merb to be the awesomeness. So arguments based on "Do X and Merb will be more awesome" will be well received. Let's focus on those things, and stop worrying about the Rails comparisons.
> Putting on my manager hat, I'm a bit concerned by the tone of the > responses in this thread, and whether Merb will be properly > supported. I'm not trying to throw stones, but if you haven't had the > "joy" of supporting a large piece of software, used in ways you never > intended or even forsaw, I would urge you to rethink some of the > suggestions I made above.
One of the biggest advantages that Merb has is its comprehensibility. If you need someone else to "support" your software, you should be using a bigger framework like Rails, or possibly Struts. I chose Merb because using Merb meant I didn't need to depend on someone for support. If Merb-the-community disappeared tomorrow, I would still have a chunk of well-written, easy-to-understand code underlying my application. At any given point, I could stop following the changes coming from upstream, and simply treat the Merb code as part of my application that someone saved me the trouble of writing myself. Merb is (and hopefully will remain) a hacker's framework, not a manager's framework. Having said that, I was also pretty disappointed by the tone of this thread. I don't think it's representative of the core team's attitude in general.
> As well as discussions and questions I've seen on this group so far.
> Controllers > ---------------------------------------- > 1. Merb.logger.debug - recommend dropping the "Merb.", it's repetitive > to look at and type
Add your own helper method if you want this to be shorter:
def logger Merb.logger end
> 2. before/after - recommend using before_filter/after_filter since the > functionality is the same
Definitely *not* going to happen. I always hated before_filter when before/after is plenty good enough. This definitely will not change.
> 3. This looks awkward
> def index > render('', :layout => :application) > end
> Can we add a render() keyword for clarity?
> render :nothing, :layout => :application
Why do you want to render an empty layout with nothing inside? I don't see a good reason to add yet another magic keyword here. Merb's render philosophy is completely different from rails since return values of merb actions are sent to the browser.
> 4. The provides() vs only_provides() difference is confusing, just > because of the method inconsistency vs the rest of Merb. I don't have > a suggestion yet that would be a workable method signature.
I don't see any confusion here, these methods always made perfect sense to me. Maybe we just need more docs but this is not going to change either, it is one of merb's nicer features.
> Helpers > ---------------------------------------- > 1. I'm not sure if Ngoc's port is accurate, but why are the helpers > injecting into Merb's GlobalHelpers? Seems monkey-patchy. If Ngoc's > port is accurate, can't Merb do this under the covers, rather than > exposing it? That would clean up the interface, and offer protection > for Merb in case Merb's internal API needs to change in the future.
I don't know what know what you are talking about here.
> Views > ---------------------------------------- > 1. Provide a url_for wrapper around url().
Merb does not have url_for so this makes no sense
> 2. Provide a heckuva Wiki page for everything else :-)
We're working on this, the wiki is starting to get a lot of content.
> Configuration > ---------------------------------------- > 1. Add support for the Rails-style initializers/ directory. This is a > simple nicety that will be a "Why don't my initializers work?" > question otherwise (already popped up in this google group)
I'm still on the fence on this one. I might be swayed to add it but it's so trivial that it's easy for folks to add themselves.
> 2. Standardize the "merb more" and "merb plugin" names to all use "_", > ie, "merb_assets", "merb_cache", etc. Otherwise it'll be another > support timesink of answering, "No, it's merb *dash* cache, but merb > *underscore* paginate".
This is probably a good idea to cleanup soon.
3. Change the default router.rb file to use "|map|" like Rails.
> Everyone's used to "map.resources". Yes, people can change it > themselves, but providing it the same as people are used to will save > support questions.
Merb's router is fundamentaly a different beast then rails router. It is not a map so map has no meaning here. You are free to change this if you want but you are not passing a map to the block you are passing a route set.
I'm happy to see people thinking about these things but merb is not rails and never will be. Some of these changes need to be made but most of them are just rails habits that need to be retrained.
> Putting on my manager hat, I'm a bit concerned by the tone of the > responses in this thread, and whether Merb will be properly > supported. I'm not trying to throw stones, but if you haven't had the > "joy" of supporting a large piece of software, used in ways you never > intended or even forsaw, I would urge you to rethink some of the > suggestions I made above.
Merb will be properly supported because it is *way* simpler to support than rails. The code base is simple and that is a huge advantage. I've supported many large pieces of software and I will take maintaining merb over rails any day of the week. You have nothing to worry about here.
The thing to keep in mind is that merb is not rails, there are some fundamental differences in opinion and that is ok, you just have to learn to accept it. Merb will pay huge dividends whenever you have to peek under the hood and I cannot stress enough how much of an advantage this is
1. one could argue caches_page/caches_action (instead of cache_page/
cache_action) are more correct in the sense that "to cache" (the verb)
is not actually caching anything at that moment but rather setting up
something to be cached.
2. i think before_filter/after_filter should be aliased and deprecated
down the road (btw, what happened to around?). like ms does, embrace
and extend.
3. render file doesn't work in views, i've had to rewrite a lot of
those.
4. i like js_include_tag, css_include_tag, but i still think the old
ones could be aliased and deprecated. you'd be surprised at how many
ppl a couple of lines can help. remember, ppl's rails apps are like
their babies too--they wanna get their feet wet before diving in.
5. sometimes it's not the syntax but rather the behavior. ex, if i do
partial('p', :foo=>'funny') and in my partial: foo ||= 'not funny' (i
expect: funny, but get: not funny).
i think the key is to have the most elegant/concise syntax while
aliasing/deprecating the close calls (i don't believe there are that
many). what ez needs are the names and numbers rather then full-on
debates over each (let him be the decider). no need to search for
them, just report em if you come across em. hopefully by 1.0 this
group will have logger.silence do again; end.
Dudley, I agree with your comments. I think it's good to acknowledge realize that there have been a lot of tension lately caused by a lot of people migrating from Rails to Merb and some hardcore Merbists.
Rails is very opinionated (which is totally ok) but so is Merb ;) In a different way tho. Merb's philosophy is that we don't want to force you to do things one way because we think it's the best thing ever and that will make your life easier. Generally, things are a bit harder in Merb, often different than Rails but we can "usually" find a valid justification and that's why Merb is faster/leaner.
Because we want to keep things flexible, the Merb framework doesn't have all the easy tools Rails would provide you with... but at the same time, it's quite easy to maintain Merb's fresh, simple and clean code compared to Rails, older/crustier code.
Anyway, to come back to the tone of the thread, I think some people are getting a bit upset by the newcomers who want to change Merb to be more like Rails. I personally think it's totally normal to want some similarities when you never had any issues with Rails. Same thing happens with people coming from Django. However instead of just saying no, we probably should justify a bit better why we are saying no ;)
A potential solution would be to have a wiki page explaining some of the decisions so we wouldn't constantly have to repeat the same things over and over. ( plus we could get quotes from some of the core team members ;) )
-Matt
On 5/28/08, Dudley Flanders <dud...@misnomer.us> wrote:
> > Putting on my manager hat, I'm a bit concerned by the tone of the > > responses in this thread, and whether Merb will be properly > > supported. I'm not trying to throw stones, but if you haven't had the > > "joy" of supporting a large piece of software, used in ways you never > > intended or even forsaw, I would urge you to rethink some of the > > suggestions I made above.
> One of the biggest advantages that Merb has is its comprehensibility. > If you need someone else to "support" your software, you should be > using a bigger framework like Rails, or possibly Struts. I chose Merb > because using Merb meant I didn't need to depend on someone for > support. If Merb-the-community disappeared tomorrow, I would still > have a chunk of well-written, easy-to-understand code underlying my > application. At any given point, I could stop following the changes > coming from upstream, and simply treat the Merb code as part of my > application that someone saved me the trouble of writing myself. Merb > is (and hopefully will remain) a hacker's framework, not a manager's > framework. > Having said that, I was also pretty disappointed by the tone of this > thread. I don't think it's representative of the core team's attitude > in general.
didn't see your post ez (was writing mine). all your points are valid
and i wouldn't dare disagree. with all due respect tho,
def logger
Merb.logger
end
is three locs for merb and 3 * (who knows how many apps) locs for
something as common/short/sweet/as/logger. i can totally see where
you're coming from tho..i just don't wanna dirty my babies up either
man! hmmm merb_is_not_rails gem is not sounding so bad after all.
cheers.
> > i still think the old ones could be aliased and deprecated
> The key point to take away here is that there are no old ones.
> Merb != (Rails += 1)
Hi Michael and other core contributors,
I understand what you are saying above. And it certainly is up to you, as framework heavyweights, to decide what is important and what isn't.
I don't want to belabor this point further. I just want to say that like the English language, the Rails "language" is a common set of symbols that many of us understand. As merb's popularity grows - and it will! - this community is going to be inundated with programmers migrating from Rails. Design of any sort - architecture, web interface, and framework API - is about the relationship between whatever it is that you're designing and the people using it.
Yes it is just a few lines, but the bigger issue is that to make this 'logger' method available everywhere we would have to add it to Kernel which makes it effectively global. So if any other gems or piece of code you use defines a logger method then things break.
Merb very much so wants to play nice with *any* ruby code you may want to run in your app, so I'd like to avoid adding more methods to Kernel, we have too many already. Maybe we could add it to the application controller or a mixin that you could explicitely mixin. I'm up for ideas here, but don;t want to make another global method.
I don't want anyone to think that Merb is not open for new ideas. But I really think all of these make merb more like rails requests belong in plugins. Merb id definitely *not* rails and the sooner you can stop leaning on rails crutches the sooner you will become one with the merb codebase.
I have a fundamental difference of opinion in merb, in rails hardly any users ever go into the framework code. In merb I don't want this to be the case, merb is a hackers framework, It is not and never will be batteries and training wheels included like rails is.
But the upside of all this is that merb is extremely easy to extend to make it do whatever you want. It would be very easy for some enterprising individual to make a merb_acts_like_rails_with_training_wheels plugin that makes the life of folks porting their rails apps to merb easier. But merb does not exist as a rails alike that is only meant for porting apps to.
Fundamentally, Merb is a platform rather then a full stack framework. Use the pieces you want, leave the rest alone. This makes merb a more scalable solution for the future as we can leave all the bloat out of the core and plugins have clearly defined API's for hooking into the framework.
I think the best solution for all of this is for folks who really want this stuff to make the merb_as_rails plugin and use that. But I highly encourage folks to only do something like that if they have a large app to port. If you start with merb from scratch or are porting a small app, it may take you a few hours extra but you will be better off using the real merb idioms that have a lot of thought and experience put into them.
> didn't see your post ez (was writing mine). all your points are valid > and i wouldn't dare disagree. with all due respect tho,
> def logger > Merb.logger > end
> is three locs for merb and 3 * (who knows how many apps) locs for > something as common/short/sweet/as/logger. i can totally see where > you're coming from tho..i just don't wanna dirty my babies up either > man! hmmm merb_is_not_rails gem is not sounding so bad after all. > cheers.
> > i still think the old ones could be aliased and deprecated
> The key point to take away here is that there are no old ones.
> Merb != (Rails += 1)
> Hi Michael and other core contributors,
> I understand what you are saying above. And it certainly is up to > you, as framework heavyweights, to decide what is important and what > isn't.
> I don't want to belabor this point further. I just want to say that > like the English language, the Rails "language" is a common set of > symbols that many of us understand. As merb's popularity grows - and > it will! - this community is going to be inundated with programmers > migrating from Rails. Design of any sort - architecture, web > interface, and framework API - is about the relationship between > whatever it is that you're designing and the people using it.
> Ben
Ben-
I don't want anyone to think that merb core folks are resistant to change and are just downplaying folks concerns. We hear you loud and clear. But if merb just copies everything rails does then what is the point? Merb is an evolution of rails it is not a port or copy. I do not want to hinder merb's clean api with concerns about porting apps from rails. If merb just adopts all of rails apis it will be no better off then rails itself is.
So I think the best thing for folks all around is to make a plugin that is a rails compatibility shim that folks porting apps can use. Also we should add a few wiki pages with descriptions of why and how merb's api's differ from Rails apis to help folks coming from rails to merb.
I understand how people fresh off the rails boat may get confused about some of this stuff, but we will just have to document the differences and why they exist. Rails IMHO has grown *way* to big for a framework, this is why people run into the wall when they need to do something that is not "on the golden path". I will not make this same mistake in merb.
> I don't want to belabor this point further. I just want to say that like > the English language, the Rails "language" is a common set of symbols that > many of us understand.
Ben,
As person who can read 4 (natural) languages I should say nothing benefits your brain as much as learning a new language or living in a country that has different culture from your home land.
It even makes you understand your mother tongue better in some ways. This is just another point of keeping Merb's "post Rails" decision around for years. -- MK
> Having said that, I was also pretty disappointed by the tone of this > thread. I don't think it's representative of the core team's attitude > in general.
Attitude of most active Merb contributors is to keep Merb's philosophy in place => keep Merb's benefits for those who need it. Nothing else.
To keep your ideas in place you have to give up on some of the opposite ideas. And it pisses someone off.
What's I especially like about that thread is that no one from people who need "Rails compatibility" so bad they spend hours arguing actually submitted a few lines patch, kicked off merb plugin project at github or ever asked what *they* can do about it.
People didn't submit patches because they wanted to know why we were not doing things the way they expected us to do it. Now that they have a clearer answer from Ezra, I'm sure we will see few patches and hopefully a rails idioms plugin for Merb.
I actually thought that the people asking for the Rails syntax were quite nice about it. I do disagree with the reasoning, but I really appreciated Ezra's reply explaining the reasons why things are the way they are right now.
I'm off to the Rails Conf, I know for a fact that at least Yehuda and Ezra should be around if you have any questions regarding Merb. I think Yehuda also has a Merb BoF talk scheduled.
Finally, we'll more than likely announce the first Merb Camp planned for October 08 (planning on 10-11) in San Diego California. So if you couldn't make it to Rails Conf, plan a trip to Southern California!
-Matt
On 5/28/08, Michael Klishin <michael.s.klis...@gmail.com> wrote:
> > Having said that, I was also pretty disappointed by the tone of this > > thread. I don't think it's representative of the core team's attitude > > in general.
> Attitude of most active Merb contributors is to keep Merb's philosophy > in place => keep Merb's benefits for those who need it. Nothing else.
> To keep your ideas in place you have to give up on some of the > opposite ideas. And it > pisses someone off.
> What's I especially like about that thread is that no one from people > who need "Rails compatibility" > so bad they spend hours arguing actually submitted a few lines patch, > kicked off merb plugin project > at github or ever asked what *they* can do about it.
|
