I've spotted such project at github. Looks like way to go in this
particular case.
--
MK
I have just ported this little CMS from Rails
(http://openkh.rubyforge.org/svn/trunk/) to Merb
(http://openkh.rubyforge.org/svn/branches/merb-activerecord/). It was
very painful and time-consuming. I have to rewrite everything because
of the incompatability between:
* Merb::Controller and ActionController::Base (a little painful)
* merb_helpers and ActionView (<- very painful!)
I think you are paying too much attention to one option naming.
First off, I am all for changing it to whatever it should be for "compatibility"
but I cannot agree on the tone. It seems like Merb should do everything to be
like Rails? Then why develop Merb, use Rails.
> - foster migration of users to merb
Merb needs no world domination. If people use Rails instead, they make
their choice.
> - easier to re-use existing codebase of plugins, snippets, etc.
Controller plugins are incompatible anyway. Reuse with copy-paste
can be complemented by find-and-replace.
> - applicability of existing docs, tutorials and other support
Other difference make them pretty irrelevant anyway.
> - easier to find/compare differences in implementation
People who do hack on internals won't have problems finding
differences in it, trust me. Others do not care.
> - less confusion for ppl working with both frameworks simultaneously
I do. I have no confusion and you won't after you find the difference for the
first time.
> - no need to reinvent the wheel when it comes to carefully thought out
> names and apis
It is not reinventing the wheel, it is just one option naming.
Come on, it is one option, not core concept, not
completely different conventions, one option of method
not every controller uses.
> i for one, wouldn't mind if you guys broke the api for more rails
> compatibility in 1.0. i think this is an internal philosophy issue
> which can't be addressed with a compatibility gem. it would be like
> trying to hit two moving targets at the same time. i think the main
> reason ppl won't switch over is due to rails maturity and larger code/
> support base.
Until they find ActiveRecord doing
crazy number of queries while walking down tree structures.
> compatibility on top of performance would definitely be a big carrot.
> i would go so far as to say the two communities should work together
> when planning new features/releases.
Again, they have different sense of value. No power in this Universe
convince Michael Koziarski
that alias method chain is insane and 5 CGI wrappers in dispatch process, too.
--
MK
You cannot use Rails controller plugins out of the box in 99% of
cases. So it does not matter
what's the option name.
I am +10/-10, I don't mind updating one option in my own applications,
I don't mind not doing it :)
--
MK
Would you say Django should use Rails helpers and stuff?
If you would rewrite it using Django, it is so much more pain.
--
MK
If framework X is worth using it, (s)he will tell friends anyway or at
least continue using it.
This is the goal to chase.
I think you can stop convincing people that "maximum Rails
compatibility" is so extremely important. If it is, why waste time? Go
and create
local branch, make changes you want to see and submit patches. It is
much easier to make decision when most of work is already done.
You can get that method use both :except and :exclude to satisfy
people who prefer the way it works now.
Even if you won't have your patches applied, you will learn a lot
about framework you use.
--
MK
I think you can stop convincing people that "maximum Rails
compatibility" is so extremely important.
I am all for it, I did say it, didn't I? I just don't
agree on the tone. Rails compatibility is not top priority. Noisy
mailing list messages
will pop up anyway. If you need Rails compatibility today, go
do it, it is as easy as a few lines patch in this particular case.
One thing makes me wonder. We have problems with inflector. We have some
code duplications with DataMapper core. Merbful authentication is so
ActiveRecord
oriented I could not port Merbums to DM0.9 today without rewriting it.
There are
specs missing in -more/-plugins. Merb-more rakefiles are not not well organized.
And there are lots of other things to care about much more.
Still people care about naming of options "like in Rails"
and "code reuse" (with copying and pasting obviously, Merb controllers
are different
so much you cannot use 95% of Rails controller plugins out of the box).
Think about it next time you want to mention "faster adoption" or
something like this.
--
MK
Web Frameworks really need something that will generate flash-like
functionality easily.
I say flash-like because Flash really sucks, and so does the whole
host of flash-like things that have sprung up around it.
The reason is mostly that:
1. They're big to code, and big to download.
2. They don't allow their source to be seen inside of.
3. They're proprietary.
4. They are difficult to code in.
5. They often require downloading things to work.
We need something that will make us happy on the view side.
Julian.
1: will someone please start a page on the wiki for 'common gotchas
for rails devs' or something equivalent.
2: please keep in mind that merb and rails have different target
'markets'; it is kinda assumed that if you're using merb, you're going
to read the docs and the source.
3: I think a case could be made that 'except' is the more correct
choice. If someone wants to make that case, a patch would be welcome.
I don't think 'because it will make it easier for rails folks' has
positive or negative weight for 'correctness' ... let's just use the
best names and APIs and not focus so much on Rails at all.
Sent from my iPhone
On May 25, 2008, at 8:51 PM, "Michael Klishin" <michael....@gmail.com
Sent from my iPhone
If people are really annoyed by the except, exclude thing I have no
problems adding support for except and wither leaving or removing
exclude. But I am not going to go down the rabbit hole of going
through the whole api and trying to make it more rails like. That is
not going to fly as merb is not rails.
So for now let's add support for :except while still
supporting :Exclude as I do not want to break everyones apps right now.
If anyone has any other parts of the API they want to speak up about
do it now or forever hold your piece ;)
Cheers-
-Ezra
- Ezra Zygmuntowicz
-- Founder & Software Architect
-- ez...@engineyard.com
-- EngineYard.com