Re: [framework-one] Best practice for backend admin

[Matt Quackenbush]

Subsystems won't (I don't think) allow you to use a URL like that, as it's got to have some way of distinguishing the subsystem in use. There are two quick options that I can think of off the top of my head:

1) routes

2) have the root-level FW/1 app ignore /admin, and add a second FW/1 app there

HTH

On Wed, Apr 17, 2013 at 2:46 PM, cf10 guy <igam...@gmail.com> wrote:

What is the best way to create an admin system in FW1?

Subsystems would be my first thought, but I don't like the way the URLs are formatted (ie domain.com/admin:main/ vs domain.com/admin/). Is there a way to implement subsystems with friendlier URLs?

Essentially, I just want a public subsystem (products, services, etc) to show as domain.com/ and an admin subsystem to show as domain.com/admin/.

Any ideas?

--
--
FW/1 on RIAForge: http://fw1.riaforge.org/
 
FW/1 on github: http://github.com/seancorfield/fw1
 
FW/1 on Google Groups: http://groups.google.com/group/framework-one
 
---
You received this message because you are subscribed to the Google Groups "framework-one" group.
To unsubscribe from this group and stop receiving emails from it, send an email to framework-on...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[cf10 guy]

How exactly would the routes option work? I can't find any documentation on how they work with subsystems.

[Matt Quackenbush]

https://github.com/seancorfield/fw1/wiki/Developing-Applications-Manual#url-routes

[Sean Corfield]

On Wed, Apr 17, 2013 at 12:01 PM, cf10 guy <igam...@gmail.com> wrote:
> How exactly would the routes option work? I can't find any documentation on
> how they work with subsystems.

They work exactly the same as without subsystems. Routes just
preprocess the incoming URLs and rewrite them inside the app.
Subsystems are nothing special.
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

[Jim Priest]

Routes is probably the easiest. 

I have something like the following configured:

/admin = admin:admin =  myapp.com/index.cfm/admin

/docs = admin:main  = myapp.com/index.cfm/docs

I've not implemented url rewriting...

Jim

[cf10 guy]

Is there a way to use a wildcard?

/admin = /admin:*

[Sean Corfield]

I believe so. Someone contributed wildcard support to routes a while
back although it hasn't found its way into the documentation.

Perhaps something like:

/admin(.*) = /admin:\1

Based on an example from Marcin:
https://github.com/marcins/cfobjective2012/blob/master/demos/routes/application.cfc

> --
> --
> FW/1 on RIAForge: http://fw1.riaforge.org/
>
> FW/1 on github: http://github.com/seancorfield/fw1
>
> FW/1 on Google Groups: http://groups.google.com/group/framework-one
>
> ---
> You received this message because you are subscribed to the Google Groups
> "framework-one" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to framework-on...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[cf10 guy]

In case anyone else is curious, this worked for me: '/admin/*' = '/
admin:\1'

Also, is there a way to get the buildurl function to output more
friendly URLs? If I use #buildurl('main')#, the output is admin:main.
Is there any way to change this to simply /admin without hardcoding
the value?

[Marcin Szczepanski]

Unfortunately buildUrl doesn't take routes into account.  I had the same question awhile back, and wondered whether it would be possible but Sean (correctly) pointed out some edge cases where it wouldn't work.

Oh, turns out the issue is still open and I created it :)

https://github.com/framework-one/fw1/issues/145

--
--
FW/1 on RIAForge: http://fw1.riaforge.org/

FW/1 on github: http://github.com/seancorfield/fw1

FW/1 on Google Groups: http://groups.google.com/group/framework-one

---
You received this message because you are subscribed to the Google Groups "framework-one" group.
To unsubscribe from this group and stop receiving emails from it, send an email to framework-on...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
M.

[Sean Corfield]

If anyone can come up with a patch for buildURL() to add reasonable
support for routes in a sane way that isn't going to surprise users
nor break anyone's code, please submit a patch - with plenty of unit
tests! - but it's not a puzzle that I plan to work on because I don't
feel sufficient pain from the lack of route support in buildURL() :)

Sean

[Marcin Szczepanski]

I was just reading something about Django and it reminded me about something both Django and Rails do with routes - have the concept of "named" routes. So say your /product/:id => product.view?id=:id route has a name "product_view", then you could do buildUrl(route=product_view, queryString="id=1") - it's now explicit which route buildUrl refers to. Rails at least auto-generates 

I guess that doesn't solve the problem of making it transparent though - if you always refer to the action you don't care if routes are "on" or "off",  but if you start using names you HAVE to be using routing, but it does solve the problem of ambiguous mapping from action/params to route.

Also what those other platforms actually do is actually give you a helper for the url and path - so for the product_view route you could do in your view <a href="#product_view_path(1)#">View Product</a> rather than using buildUrl.

So you can see how this looks in practice, here is the routing table from a rails app I am currently working on (you can always generate this for a rails app with "rake routes"):

https://gist.github.com/marcins/ffc115dcebb8e5d4a426

Columns are name, method, route, controller#method

Just throwing the thoughts out there, not suggesting this is the right way to go.

[Marcin Szczepanski]

Oops, just noticed I cut off a sentence - where I said " Rails at least auto-generates " I meant to say Rails auto-generates the names for your routes based on (namespace)_method_controller.  If you look at the gist some routes don't have names - non get/post ones don't, but not sure off the top of my head why some others don't end up "auto-named". You can always add an explicit name though.

--
M.

[Marcin Szczepanski]

FYI - I've put this together into something a bit more coherent on the aforementioned github issue about buildUrl supporting routes:

https://github.com/framework-one/fw1/issues/145#issuecomment-16693983

I posted the comment and I thought "This seems complex, why would I do this instead of just a regular URL if I know the route?" - I think the advantage is that buildUrl knows about the base path, SES path, etc.. that's really the use case for buildUrl with routes. You can move your app around and not have to worry about that stuff all over your views.

--
M.

[cf10 guy]

Would it be possible to change the output of the buildURL function based on a simple variable? For example, if buildSubsystemSES is true, then buildURL will output admin/section/item instead of admin:section/item. Of course, this still requires routes to be set up correctly, but a rather simple approach if it's possible.

Can anyone offer any guidance on how to make this change for personal use?

[Chris Blackwell]

fw/1 won't let you use / as a subsystem delimiter, not sure why, there's probably a very good reason. 

so to achieve what you're after you could do this.

1. setup your routes so that you map each subsystem explicitly.  for example

framework.routes = [

{'/admin/*' = '/admin:\1'}

]

2. override buildUrl in your Application.cfc

  public function buildUrl() {

return replace(super.buildUrl(argumentCollection=arguments), ":","/");

  }

You'll need to be careful here though as your mapped subsystem names must not clash with any section names in your default subsystem,otherwise you're going to make them inaccessible

Chris

[Sean Corfield]

On Wed, May 15, 2013 at 6:45 AM, Chris Blackwell <ch...@team193.com> wrote:
> fw/1 won't let you use / as a subsystem delimiter, not sure why, there's
> probably a very good reason.

...

> You'll need to be careful here though as your mapped subsystem names must
> not clash with any section names in your default subsystem,otherwise you're
> going to make them inaccessible

That's the reason.