nested resource update action && no dashboard without namespace

[panva]

i encountered issue with nested resource while having

# active_admin.rb
default_namespace :admin
# images.rb
belongs_to :article

After submiting the edit form for Image active_admin tries to redirect me to article_image_path instead of admin_article_image_path

i needed to continue development so i tried to set no namespace and this works fine, however now i do not get my dashboard loaded properly

(active_admin master branch, rails 3.0.8)

[panva]

Also, with everything default except for

# active_admin.rb
config.default_namespace = false

you generate wrong logout path in the layout

/false/logout instead of /admin_users/logout
and the logout path is generated as /false instead of just /

[brunoarueira]

I had a same problem about the config.default_namespace = false with rails 3.0.3.

[DougPuchalski]

I've been wrestling with namespaces for weeks. You might want to try :root instead of false, but there are still issues. I think it just hasn't really been tested as of yet.

[jocubeit]

I'm having the same issues here using config.default_namespace = false. None of the Devise routes work anymore, in fact I end up in an endless loop error:

Too many redirects occurred trying to open...

Dashboard doesn't work no matter where you put it, what you call it, or what routes you create.

Is there an estimated timeframe on milestone 0.3.0? I'm trying to decide if I need the lack of namespace enough to fix it myself because I want to roll this app out by weeks end.

[DougPuchalski]

Personally I have had to abandon all immediate hopes of using this gem in anything other than the /admin namespace, and regret it took me so long to make that decision. I've spent many hours trying to get around limitations only to bump up against another every time. It's also hard to justify the risk of time given that the master branch might diverge even further from what I might expect.

The architecture of this gem is quite clever and I like a lot about it, including the arbre library (which I would love to see extracted for use externally). But, as an example, I think the choice to use a DSL to generate an application layout assumes a very narrow use-case, diverges too far from the Rails Way and makes it very difficult (or at least non-DRY) to integrate into, at least, my projects and leverage a consistent user experience. The master branch focus has some basic assumptions that don't yet allow for as much flexibility as my projects require, and I think there are still some critically hooks as well. I do expect that to improve, but, the layout issue still troubles me a lot and prevents me from confidently embracing it as a key component of my apps.

So, I assume the present goals of the project are for it to be a sidelined admin interface. Best use is to not fight the defaults, and wait for the it to mature.

[fro]

@aceofspades " I think the choice to use a DSL to generate an application layout assumes a very narrow use-case, diverges too far from the Rails Way and makes it very difficult (or at least non-DRY) to integrate into, at least, my projects and leverage a consistent user experience. "

I agree... indeed, AA is a nice choice for really simple Apps admin created in a breeze.
I'm struggling with it because my project have a lot nested resources... I can't find an elegant solution to handle these case...