Alex is spot on with all his points. I agree with all of them.

I'd also like to suggest some sort of implicit module across the whole
app. So an easy configuration value in init.rb
use_namespace "MyApp"

And all controllers, models, and helpers would be automatically
namespaced with MyAppNamespace:: when Merb loads them up. So if I
wanted to define my models/user.rb, I would do it like normal:

class User
end

However the real class name of it would be
MyApp::User

This would automatically allow every app to be able to run in the same
Ruby process with others provided this name is unique. It would also
provide a much nicer upgrade path for existing merb apps, so they dont
have to go in and modify every single class definition (model,
controller, helper) to be namespaced in order to work with other apps.


On Mar 5, 6:57 am, Alex Coles <[email protected]> wrote:
> On Mon, Mar 2, 2009 at 8:44 PM, Matt Aimonetti <[email protected]> 
> wrote:
>
> > I posted a new blog post covering Merb 1.1 roadmap:
> >http://merbist.com/2009/03/02/merb-11-roadmap/
>
> > Note that we definitely need your help specing the mountable apps.
> > Please let us know what's currently frustrating you with the Merb
> > slices, how you would want the mountable apps to work, and any other
> > information you think would be relevant.
>
> > Thanks,
>
> > - Matt
>
> Hi Matt,
>
> I am excited about seeing mountable apps: to me it seems that apps
> that can be run both standalone and be mountable must be a common use
> case.
>
> In fact, I am currently working on an application
> (http://github.com/nedap/locomotive/tree/master) that has such a
> requirement. But its certainly not the only app where I think this
> type of modularity would come in useful (in fact I think I would use
> it in about 90% of distributable apps).
>
> I've actually succeeded in making the above application run both as a
> standalone app and mountable -- but it does currently feel hack-ish:
>  - I started developing as a Merb standalone application (initially
> ported from Rails)
>  - then generated a fresh slice of the same name
>  - and with some time, patience and a good diff tool, overlaid those
> slice files.
>  - then various bits of tweaking: the Feather blog project managed to
> accomplish the same things, and so that gave me some clues as to what
> I needed to do to get it all working.
>
> Here are some of the pain points with the current approach:
>
>  * Duplication of bits of configuration: i.e. config/router.rb,
> config/dependencies.rb (right now, copying and pasting between the two
> -- reuse possible by including the config dir in the slice gem, and
> requiring config/dependencies.rb in my lib/sliceapp.rb)
>
>  * Namespacing:
> this was the biggest pain point for me, especially as I wanted to be
> able to use merb resource routes (I really like the syntax). I
> namespaced my models and controllers, but was unable to get the
> namespace configuration in my config/router.rb to work correctly in
> the standalone app.
>
> After encountering a bunch of "Could not find resource model XXX"
> errors on application startup and having resource url helpers blow up,
> my solution was to explicitly specify full, namespaced model name  for
> each resource in config/router.rb:
>
>  resources :platforms, 'Locomotive::Platform'
>
>  * Helpers:
> css_include_tag and js_include_tag are not slice-aware... This can
> fairly easily be worked around, but not totally elegant 
> (seehttp://github.com/nedap/locomotive/blob/906c3f84747889770fc7acd5cd6d3...)
>
>  * Views:
> Making sure slice controllers inherit from SliceApp::Application not
> Application, and some manual trickery to make sure the views are
> picked up from the right place 
> (seehttp://github.com/nedap/locomotive/commit/4ec622e8d9f3255144148b986ba...).
>
> * Not being able to use Merb.push_path in my config/init.rb after
> overlaying a slice (slice rake tasks get required otherwise) 
> (seehttp://github.com/nedap/locomotive/commit/e54515bcf46a9af13d23931e132...).
>
> That's a brainstorm of things I came across -- I am sure there are
> more. Nothing insurmountable (forgive the word play), but some things
> that I am hoping 1.1/1.2 will resolve.
>
> Alex
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"merb" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [email protected]
For more options, visit this group at http://groups.google.com/group/merb?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to