The merb equivalents are much more brief, and better.
If people want rails compatibility, why not offer a merb_rails plugin
solely for this purpose.
Julian.
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 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.
The other changes just don't matter.
On Wed, May 28, 2008 at 4:22 PM, Michael Klishin
<michael....@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,
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.
It would be trivial to add a few lines to support aninitializers/ directory ...
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)
Ngoc.
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.
By default, all actions provide :html
There's a number of methods to help make this not only easy, but flexible.
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
1. Provide a url_for wrapper around url().
2. Provide a heckuva Wiki page for everything else :-)
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.
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".
> 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.
"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.
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.
:dudley
On May 28, 2008, at 6:31 AM, Nate Wiger wrote:
>
> Based on the previous Merb / Rails compatibility thread here:
>
> http://groups.google.com/group/merb/browse_thread/thread/2327341145a4cb66/bdd3621131191c78
>
> Ezra asked for a list of API nitpicks, pre-1.0. So I'm establishing
> this thread to do so.
>
> Here is my list. Most are simple suggestions that can avoid potential
> support timesinks. I can help with patching if needed.
>
> If others have recommendations, please post them here as well. A
> couple guidelines: (1) Be clear, (2) Be succinct, (3) Be nice.
> Thanks.
>
> =
> =
> =
> =
> =
> ======================================================================
> I'm basing this on Ngoc's blog/wiki port to Merb here:
>
> http://openkh.rubyforge.org/svn/branches/merb-activerecord/app/controllers/users.rb
>
> 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.
Cheers-
- Ezra Zygmuntowicz
-- Founder & Software Architect
-- ez...@engineyard.com
-- EngineYard.com
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
> 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)
> i still think the old ones could be aliased and deprecatedThe key point to take away here is that there are no old ones.
Merb != (Rails += 1)
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.
Cheers-
-Ezra
- Ezra Zygmuntowicz
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.
Cheers-
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
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.
They just give recommendations.
--
MK
> 2008/5/28 Dudley Flanders <dud...@misnomer.us>:
>> 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.
I said "core team", not "active Merb contributors".
> 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.
Most of these API changes are technically trivial. Implementing them
is easy, deciding whether they're a good idea is the harder part.
:dudley
what is core team other than active contributors? buzzword from
Rails world? with git everyone is on the core team.
> Most of these API changes are technically trivial. Implementing them
> is easy, deciding whether they're a good idea is the harder part.
It is much easier to convince people by doing change first, then showing
it to them. Rails core team (c) (tm) once made a decision that all
change requests
that have no patches are closed as invalid right away. It was back in
2006 I think.
Think why.
--
MK
>> Most of these API changes are technically trivial. Implementing them
>> is easy, deciding whether they're a good idea is the harder part.
>
> It is much easier to convince people by doing change first, then
> showing
> it to them. Rails core team (c) (tm) once made a decision that all
> change requests
> that have no patches are closed as invalid right away. It was back in
> 2006 I think.
> Think why.
You're saying it's right because Rails does it? I'm getting some mixed
signals here ;-) You're absolutely right that it's easier to convince
people with code, but that doesn't make discussion without code
"invalid" or "insignificant".
:dudley
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,
Michael
On May 28, 2008, at 1:15 PM, Ben Nevile wrote:
I do not use Rail's logger method because it does not work everywhere,
and I do not want to have multiple idioms, so I use
RAILS_DEAULT_LOGGER which is quite a keyboard full, but always works.
I like having Merb provided services tagged with Merb and not
magically available. It makes it easier for a new person to know
where to look for docs and info on the code and it makes name clashes
impossible.
Michael
Michael
Merb is clean, simple and easy to build your own thing on top of it. It works
nice with DataMapper => you won't have to fight with ActiveRecord when
you work with something that it was not developed for. It does not
consume 60 megs per app
server when all you need is one-feature application. It proven that
Ruby tools can be very fast and
frameworks can be very modular while staying simple. I know it is
nothing from manager's perspective.
We are not all managers, thankfully.
> If Merb is going to be successful, it will do so by
> being a couple-hour port from Rails with a 20% speed boost. Otherwise
> people won't care, or spend the time, or both.
So what? Merb does a great job for some people. Nothing does great job
for everyone.
Including Rails. Sorry that it wasn't developed for Playstation team
needs from the ground up.
You can build Ruby on RailsStation on top of Merb and make it 100%
Ruby on Rails API compatible.
--
MK
If all Merb offered was a speed boost it would be dead already. That
may be your pain point, but I doubt that would justify an entirely new
framework and code base. Better performance is a caret, but to get
better performance requires approaching things differently.
If it looks too much like Rails people are going to "port" their code
using all the old thinking and bad habits, and find they do not get
the performance benefit. For most of the issues raised in this thread
a gem for rails compatibility could easily add aliases and such,
without forcing that compatibility "crap" on newly built Merb apps. I
would rather build Merb apps using Merb as it was intended and have a
lean framework to maintain and support. The more ways there are to do
things the more cost there is in learning, maintaining, and training.
For those with large existing code bases the death of a thousand cuts
could be a real issue, and a compatibility gem makes sense. But, I
doubt the Merb core team cares about that. Some largish project is
going to need to do that gem and share.
Michael
I think the root of the issue, however, is in a lack of a prominent
document that clearly maps Rails idioms onto Merb ones (like the
Test::Unit => Rspec document).
> It's all about setting expectations - if you come in with the
> mindset Merb != Rails, then life gets a lot easier.
I think this is a really good point, and maybe something someone
should blog about.
I think the real disconnect here is that I, and I assume others, do
not believe that Rails has established expectations for all
programmers. It's established expectations for *Rails* programmers,
just as Spring has established expectations for Spring programmers and
Maypole has established expectations for Maypole programmers.
We're never going to do something just to be different, but I really
hope we never add a single line of code that can only be justified by
"Because Rails does it that way". "Because Rails does it and it's
awesome" is a great justification, though.
So let's argue these things on the merits of them.
> Like it or not, Rails has ingrained certain idioms. The few that
> we're talking about here (logger, initializers) are exceedingly
> simplistic - which is all the more reason Merb should just cut-and-
> paste the 3 lines of code into core and call it done.
No code is faster than no code. I don't object to initializers
because of some NIH feeling. I object to them because it's
unnecessary code that doesn't belong in merb-core. "Its simple, so we
should do it" is a strategy that will always lead to bloat. Many
things are simple, but that doesn't mean they're good.
As a compromise on initializers, what if we put the 1 line snippet to
add initializers into the default generated init.rb, commented out, so
people can see how to do it if they need it? That would fit with the
Merb philosophy of less behind-the-scenes magic and more explicit Ruby
code, but would also make it easy to turn on for people who feel they
need it. Plus, it's in merb-more and not merb-core.
I think wycats is going to comment more on the philosophy about why we
don't have a logger() method in Kernel, so I'll just say it really is
a philosophical point. It's not arbitrary. We're not just trying to
be jerks.
On Wed, May 28, 2008 at 8:47 AM, Michael D. Ivey <michae...@gmail.com> wrote:It would be trivial to add a few lines to support aninitializers/ directory ...That's what Collective does. No Big Deal. http://github.com/meekish/collective/tree/master/config/init.rb#L40-43