Alternative to rails engines and merb-slices?

[di3go]

Rails have rails engines, merb have merb-slices, ramaze have something
similar or a way to do it?

Thanks :)

[James Britt]

di3go wrote:
> Rails have rails engines, merb have merb-slices, '

What are they?

--
James Britt

www.happycamperstudios.com - Wicked Cool Coding
www.jamesbritt.com - Playing with Better Toys
www.ruby-doc.org - Ruby Help & Documentation
www.rubystuff.com - The Ruby Store for Ruby Stuff

[Ben]

Slices/Engines are extractions of functionality that can comprise
models, views, controllers. Django has them as apps, and Nitro has
something called parts, I believe.

E.g. you could have a an authentication slice that is basically a full
auth app, but it's packaged in a way that you can trivially hook it
into your other code.

e.g.

module Auth
class AuthModel
end

class AuthController
end
end

packaged as:

/auth
/auth.rb # the module above
/public
/view
/login.rhtml
/register.rhtml

Then you could just dump this directory tree in your existing ramaze
project, and require it.

Short answer:

Ramaze doesn't have slices (yet). I have my personal repository of
slices I wrote for my own projects, but they're not production-ready
or released (too busy to get to releasable state atm).

Long answer:

I've written and asked before about this topic (on this ML), but
without much response. I think the productivity gains from slices are
huge, and it's one reason why people flock to rails and merb.

Overall, the Ramaze community is very cautious about adopting (too
many) conventions (even though the ramaze "proto" is one, and I'd
argue it's not the best one. Imho, everything should be a slice, so
you can grow projects easily extract functionality, easily maintain it
through git submodules e.g. and add new stuff without namespace
collisions).

Then again, this is open source, and I'll be the last one to complain
about something other people have created for themselves and are
giving away for free. :)

Cheers,
Ben

On Dec 5, 3:39 pm, James Britt <james.br...@gmail.com> wrote:
> di3go wrote:
> > Rails have rails engines, merb have merb-slices, '
>
> What are they?
>
> --
> James Britt
>

> www.happycamperstudios.com  - Wicked Cool Codingwww.jamesbritt.com          - Playing with Better Toyswww.ruby-doc.org            - Ruby Help & Documentationwww.rubystuff.com           - The Ruby Store for Ruby Stuff

[di3go]

merb-slices was the main reason that make me learn merb, its just
amazing, really nice!

i mainly work with rails and i like merb alot but again, im looking to
something smaller, simpler and nicer, so im here again, but i still
miss slices :P

well, ramaze is very modular, maybe i could implement something and
submit, i don't think that could be very difficult, who knows...

thanks alot!

[di3go]

[Arne Brasseur]

I'm guessing Ramaze people don't feel the need for any special feature to do this. You can easily write models and controllers that are reusable, for the views I suppose you'd have to add a search path somewhere.

So perhaps the real question is, first, what does "rails/merb slices" offer that makes it so much more convenient. And second, how are people currently writing reusable chunks of functionality?

Perhaps we can come up with some "best practice tips" or a "reusable chunck mini-howto"?

regards,
Arne


Ben 写道:

[di3go]

Here is a list of some slices user have made to merb,
http://github.com/search?q=merb+slices

Here one presentation about merb-slices, http://www.slideshare.net/hassox/merb-slices-presentation

"merb-slices are “Little slices of MVC cake”. These are self contained
merb apps with models, controlers, views and assets that you can
distribute as rubygems. You can mount a merb-slice at a specific point
in your router definition and you can override any part of the slice
up in your main app. So in a way these are similar to what Rails-
Engines promise, except merb-slices are built into the framework and
will not break when merb itself is updated." ezra

On Dec 7, 4:18 am, Arne Brasseur <Arne.Brass...@gmail.com> wrote:
> I'm guessing Ramaze people don't feel the need for any special feature
> to do this. You can easily write models and controllers that are
> reusable, for the views I suppose you'd have to add a search path somewhere.
>
> So perhaps the real question is, first, what does "rails/merb slices"
> offer that makes it so much more convenient. And second, how are people
> currently writing reusable chunks of functionality?
>
> Perhaps we can come up with some "best practice tips" or a "reusable
> chunck mini-howto"?
>
> regards,
> Arne
>

> Ben ??:

[James Britt]

di3go wrote:

> "merb-slices are “Little slices of MVC cake”. These are self contained
> merb apps with models, controlers, views and assets that you can
> distribute as rubygems. You can mount a merb-slice at a specific point
> in your router definition and you can override any part of the slice
> up in your main app. So in a way these are similar to what Rails-
> Engines promise, except merb-slices are built into the framework and
> will not break when merb itself is updated." ezra
>
>
> On Dec 7, 4:18 am, Arne Brasseur <Arne.Brass...@gmail.com> wrote:
>> I'm guessing Ramaze people don't feel the need for any special feature
>> to do this. You can easily write models and controllers that are
>> reusable, for the views I suppose you'd have to add a search path somewhere.
>>

Idle speculation:

If I gem up some classes that define some controllers and models, and
require gem that in my Ramaze start.rb in another app, would Ramaze not
treat them the same as if they were local files on a relative path? Is
it correct that Ramaze doesn't care where you put your controllers and
models? (A quick test with an app that loads some controllers from a
directory in another app suggests this is true.)

I think rendering views would be an issue, on the assumption that a
Ramaze app *does* seem to assume a local relative path (I'm guessing
there's a call to IO.read(view_path_thing) or similar in the libs).

If Ramaze knew to look in a gem's own directories, though, then it might
work fine. (I'm curious, though, if using a third-party view would be
so ideal. I think I'd rather be able to ask a Ramaze-slice gem to write
out it's view files locally so I could then edit them to suit my apps
look and feel.)

Perhaps if the gem'ed slice set the template root using a reference to
__FILE__ or __DIR__ then the controlling app would know where to look.

--
James Britt

www.happycamperstudios.com - Wicked Cool Coding

www.jamesbritt.com - Playing with Better Toys
www.ruby-doc.org - Ruby Help & Documentation

[sam carr]

Yes, I think it's really only the arrangement of the view pieces that
makes it hard, and particularly benefits from help from the framework
itself. I've tried to do this sort of things myself with Ramaze -
making a self-contained add-on that is easily included, but its the
view stuff that got really bogged down, especially since I wanted the
user to easily be able to override any of the individual view pieces
that I supplied by default.

[jesusisramaz...@geoshell.com]

2008/12/9 sam carr:

It seems to me that a good approach may be to package up only the
model and controller portions, and provide bare bones view material by
way of example that is meant to be copied and adjusted to fit within
an existing app.

One issue, though, is that packaging up model code as well may mean
yoking to a particular ORM -- unless support for more than one were
put into the package?

--
Pistos
http://blog.purepistos.net

[Michael Fellinger]

Well, that's the main reason I never made conventions for this kind of
thing... templating engines may differ, ORMs may differ, names may
differ...
The best way to share functionality in absence of conventions is still
by rack middleware and controller helpers.
If you guys want to define some kind of "Common Ramaze" that's fine by
me btw, but i doubt we'll get much agreement.

^ manveru

>
> --
> Pistos
> http://blog.purepistos.net
>
> >
>