Hey, a few days ago I was having a hard time splitting up my controllers in to different folders. With views you can just do: set :views, *path* in the module App I think it would be nice if we could do the same thing for controllers, models and helpers and whatever. like: set :controllers, *path* I think that would allow for a way better structured app that is easy to manage and it looks cleaner than my (well, Magnus'') solution which is: def self.add (name) filename = File.dirname(__FILE__) + ''/controllers/'' + name +''.rb'' module_eval(File.read(filename), name) end and then having to add every controller in this case. What do you guys think? Isn''t this something that we really should have after all? To me it would be a killer feature. - Isak
I don''t think I understand the problem - can''t you just `require` all the files with controllers? -- Matma Rex
What I am doing now is basically the same as requiring. If I do require with all the files, they don''t become a part of the controllers module. The problem is that having to require (or in my case ''add'') ever controller is *not* a very good way to work. It would be much better to be able to just do: set :controllers, *path to controllers* Because in the long run, that saves you time, and a bunch of boring and tedious work. The problem isn''t that the solution I currently have doesn''t work, this is just a suggestion to make Camping so much better.> I don''t think I understand the problem - can''t you just `require` all > the files with controllers? > > -- Matma Rex > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list > > ____________________________________________________________________________________ > Find aldi jobs Online Get Started Now. > http://click.lavabit.com/db5fe7a9kai9wirqj77kjjiskdphxcqqrdiye5hkpuyeyn1bah8y/ > ____________________________________________________________________________________ >
The regular way of doing this with requires is simply that your
''controller'' files look like this:
module MyApp::Controllers
class PonyX
def get id
.. logic to look up pony with id ..
end
end
end
This can even be generalized further I expect, to
class MyApp::Controllers::PonyX
?
end
This way you totally avoid weird evaling hacks, and are just writing plain old
straight forward ruby code with no magic (as is the Camping way). It works
because camping allows you to reopen modules and classes again and again by
defining them several times, adding new classes or adding new methods to
existing classes.
?
Jenna Fox
On Monday, 19 December 2011 at 8:56 AM, icepapih at lavabit.com wrote:
> What I am doing now is basically the same as requiring. If I do require
> with all the files, they don''t become a part of the controllers
module.
>
> The problem is that having to require (or in my case
''add'') ever
> controller is *not* a very good way to work. It would be much better to be
> able to just do:
>
> set :controllers, *path to controllers*
>
> Because in the long run, that saves you time, and a bunch of boring and
> tedious work.
>
> The problem isn''t that the solution I currently have
doesn''t work, this is
> just a suggestion to make Camping so much better.
>
> > I don''t think I understand the problem - can''t you
just `require` all
> > the files with controllers?
> >
> > -- Matma Rex
> > _______________________________________________
> > Camping-list mailing list
> > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org)
> > http://rubyforge.org/mailman/listinfo/camping-list
> >
> >
____________________________________________________________________________________
> > Find aldi jobs Online Get Started Now.
> >
http://click.lavabit.com/db5fe7a9kai9wirqj77kjjiskdphxcqqrdiye5hkpuyeyn1bah8y/
> >
____________________________________________________________________________________
> >
>
>
>
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org)
> http://rubyforge.org/mailman/listinfo/camping-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/camping-list/attachments/20111219/e995b876/attachment.html>
Sure, but say that you want to have lots and lots of controllers, I don''t think anyone wants to sit there and write a module for each one to be honest. And with that way of thinking we shouldn''t even be able to set :views. We would have to write a module App::Views for every view. set :views is magic, but it is not a bad kind of magic. This is just basic stuff to make a web app pleasant to develop. And I know set :views is partially so we can use any markup engine we want. But not being able to do the same for all the others is silly in my humble opinion. Compared to things found in rails it doesn''t even come close to magic where you have no clue of what''s going on or how it works. It''s not like you have to take it even if you don''t want it either. You have to set it yourself, and that eliminates the feeling of magic for me.> The regular way of doing this with requires is simply that your > ''controller'' files look like this: > > module MyApp::Controllers > class PonyX > def get id > .. logic to look up pony with id .. > end > end > end > > This can even be generalized further I expect, to > > class MyApp::Controllers::PonyX > ??? > end > > This way you totally avoid weird evaling hacks, and are just writing plain > old straight forward ruby code with no magic (as is the Camping way). It > works because camping allows you to reopen modules and classes again and > again by defining them several times, adding new classes or adding new > methods to existing classes. > > > ??? > Jenna Fox > > > On Monday, 19 December 2011 at 8:56 AM, icepapih at lavabit.com wrote: > >> What I am doing now is basically the same as requiring. If I do require >> with all the files, they don''t become a part of the controllers module. >> >> The problem is that having to require (or in my case ''add'') ever >> controller is *not* a very good way to work. It would be much better to >> be >> able to just do: >> >> set :controllers, *path to controllers* >> >> Because in the long run, that saves you time, and a bunch of boring and >> tedious work. >> >> The problem isn''t that the solution I currently have doesn''t work, this >> is >> just a suggestion to make Camping so much better. >> >> > I don''t think I understand the problem - can''t you just `require` all >> > the files with controllers? >> > >> > -- Matma Rex >> > _______________________________________________ >> > Camping-list mailing list >> > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) >> > http://rubyforge.org/mailman/listinfo/camping-list >> > >> > ____________________________________________________________________________________ >> > Find aldi jobs Online Get Started Now. >> > http://click.lavabit.com/db5fe7a9kai9wirqj77kjjiskdphxcqqrdiye5hkpuyeyn1bah8y/ >> > ____________________________________________________________________________________ >> > >> >> >> >> >> _______________________________________________ >> Camping-list mailing list >> Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) >> http://rubyforge.org/mailman/listinfo/camping-list >> >> > > > > > ____________________________________________________________________________________ > Learn How To Get Your Certification & Training As A Radiology Technician. > http://click.lavabit.com/5rmgod5iesh68xxeayxmjfqgo5fc3dqbm7m94shsxktoioehr3cb/ > ____________________________________________________________________________________ > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list >
"sit there and write a module for each one"?
You mean, type ''MyApp::Controllers::''? You could make it
simpler by adding a C = MyApp::Controllers line before your controller requires,
then you could write ''class C::Whatever <
R(''/url'')'' sort of stuff.
I really don''t like the magic of set :views so far as it''s
interaction with markaby. Maybe I objected when it was added. If not, I
mustn''t have been paying much attention. One of Camping''s
major selling points is that it''s just straight forward ruby classes
and modules. No magic. Magic is anything where you don''t immediately
fully grasp how it works. set :controllers is that type of thing. Is it filename
based? Where do you specify URL rules? Can you have one controller inherit from
another? Can you mixin modules to get useful methods? How do helpers work?
None of those things are clear, when writing set :controllers (or set :views for
that matter!), which means explaining them in docs or by reading
camping''s source code, which means memorising more new facts you
don''t really need to know, wasting everyone''s time, and
distracting you from the app you''re intending to build.
?
Jenna Fox
On Monday, 19 December 2011 at 9:50 AM, icepapih at lavabit.com wrote:
> Sure, but say that you want to have lots and lots of controllers, I
don''t
> think anyone wants to sit there and write a module for each one to be
> honest.
>
> And with that way of thinking we shouldn''t even be able to set
:views. We
> would have to write a module App::Views for every view.
> set :views is magic, but it is not a bad kind of magic. This is just basic
> stuff to make a web app pleasant to develop.
>
> And I know set :views is partially so we can use any markup engine we
> want. But not being able to do the same for all the others is silly in my
> humble opinion.
>
> Compared to things found in rails it doesn''t even come close to
magic
> where you have no clue of what''s going on or how it works.
It''s not like
> you have to take it even if you don''t want it either. You have to
set it
> yourself, and that eliminates the feeling of magic for me.
>
> > The regular way of doing this with requires is simply that your
> > ''controller'' files look like this:
> >
> > module MyApp::Controllers
> > class PonyX
> > def get id
> > .. logic to look up pony with id ..
> > end
> > end
> > end
> >
> > This can even be generalized further I expect, to
> >
> > class MyApp::Controllers::PonyX
> > ?
> > end
> >
> > This way you totally avoid weird evaling hacks, and are just writing
plain
> > old straight forward ruby code with no magic (as is the Camping way).
It
> > works because camping allows you to reopen modules and classes again
and
> > again by defining them several times, adding new classes or adding new
> > methods to existing classes.
> >
> >
> > ?
> > Jenna Fox
> >
> >
> > On Monday, 19 December 2011 at 8:56 AM, icepapih at lavabit.com
(mailto:icepapih at lavabit.com) wrote:
> >
> > > What I am doing now is basically the same as requiring. If I do
require
> > > with all the files, they don''t become a part of the
controllers module.
> > >
> > > The problem is that having to require (or in my case
''add'') ever
> > > controller is *not* a very good way to work. It would be much
better to
> > > be
> > > able to just do:
> > >
> > > set :controllers, *path to controllers*
> > >
> > > Because in the long run, that saves you time, and a bunch of
boring and
> > > tedious work.
> > >
> > > The problem isn''t that the solution I currently have
doesn''t work, this
> > > is
> > > just a suggestion to make Camping so much better.
> > >
> > > > I don''t think I understand the problem -
can''t you just `require` all
> > > > the files with controllers?
> > > >
> > > > -- Matma Rex
> > > > _______________________________________________
> > > > Camping-list mailing list
> > > > Camping-list at rubyforge.org (mailto:Camping-list at
rubyforge.org)
> > > > http://rubyforge.org/mailman/listinfo/camping-list
> > > >
> > > >
____________________________________________________________________________________
> > > > Find aldi jobs Online Get Started Now.
> > > >
http://click.lavabit.com/db5fe7a9kai9wirqj77kjjiskdphxcqqrdiye5hkpuyeyn1bah8y/
> > > >
____________________________________________________________________________________
> > > >
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Camping-list mailing list
> > > Camping-list at rubyforge.org (mailto:Camping-list at
rubyforge.org)
> > > http://rubyforge.org/mailman/listinfo/camping-list
> > >
> >
> >
> >
> >
> >
> >
____________________________________________________________________________________
> > Learn How To Get Your Certification & Training As A Radiology
Technician.
> >
http://click.lavabit.com/5rmgod5iesh68xxeayxmjfqgo5fc3dqbm7m94shsxktoioehr3cb/
> >
____________________________________________________________________________________
> > _______________________________________________
> > Camping-list mailing list
> > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org)
> > http://rubyforge.org/mailman/listinfo/camping-list
> >
>
>
>
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org)
> http://rubyforge.org/mailman/listinfo/camping-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/camping-list/attachments/20111219/d66eb0d9/attachment.html>
On Mon, Dec 19, 2011 at 00:47, Jenna Fox <a at creativepony.com> wrote:> "sit there and write a module for each one"? > > You mean, type ''MyApp::Controllers::''? You could make it simpler by adding a > C = MyApp::Controllers line before your controller requires, then you could > write ''class C::Whatever < R(''/url'')'' sort of stuff.You actually need `class C::Whatever < C::R(''/url'')`. Or: module C class Whatever < R ''/url''; end end> I really don''t like the magic of set :views so far as it''s interaction with > markaby. Maybe I objected when it was added. If not, I mustn''t have been > paying much attention.set :views won''t matter when you use Markaby. It''s only there for external templates.> ? > Jenna Fox
> One of Camping''s major selling points is that it''s just straight > forward ruby classes and modules. No magic. Magic is anything where > you don''t immediately fully grasp how it works. set :controllers is > that type of thing.-1 for magic, and +1 for questions like this:> Is it filename based? Where do you specify URL rules? Can you have > one controller inherit from another? Can you mixin modules to get > useful methods? How do helpers work?At least, for mere tinkerers like me... DaveE -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/camping-list/attachments/20111219/09d4a428/attachment.html>
Okay sure, you can make it simpler, but you still have to type a bunch of stuff when you are making a controller. And now that we have ''set :views'' I think it comes with to add the other stuff because you immediately think, oh well then I can set controllers to right? But you can''t. That was actually the first thing I tried when I was gonna solve the problem, which says something. How will it work? The same way that ''set :views'' works of course. And what you kind of have to consider is that you will always have to learn how to use something. I mean if you didn''t want any magic at all you wouldn''t turn to a framework, you would sit there and write you own. You still have to learn how R works when using camping for example.. And how is the relationship between the model, the view and the controller defined? You always have to learn things when turning to a framework. And let''s not forget that this is NOT forced on you, if you wanted to skip all of this and just require ever controller you can do that if you want to. This is just a trick that you can use if you want to. That''s really what I like about Camping, it doesn''t force a bunch of stuff on you. There is things that you can do if you want to. For example when naming your controllers. You CAN name them ''class PageN'' instead of ''class Page < R ''/page/(\d+)''. And that''s also magic. It isn''t magic that you have to use. But you can, that''s what I love Camping for. There''s probably other examples of magic in Camping that I either don''t know of or can think of. Being able to set :views is one of the best things I''ve been able to do since starting Camping. And set :controllers would be just as wonderful. So just consider it.> "sit there and write a module for each one"? > > You mean, type ''MyApp::Controllers::''? You could make it simpler by adding > a C = MyApp::Controllers line before your controller requires, then you > could write ''class C::Whatever < R(''/url'')'' sort of stuff. > > I really don''t like the magic of set :views so far as it''s interaction > with markaby. Maybe I objected when it was added. If not, I mustn''t have > been paying much attention. One of Camping''s major selling points is that > it''s just straight forward ruby classes and modules. No magic. Magic is > anything where you don''t immediately fully grasp how it works. set > :controllers is that type of thing. Is it filename based? Where do you > specify URL rules? Can you have one controller inherit from another? Can > you mixin modules to get useful methods? How do helpers work? > > None of those things are clear, when writing set :controllers (or set > :views for that matter!), which means explaining them in docs or by > reading camping''s source code, which means memorising more new facts you > don''t really need to know, wasting everyone''s time, and distracting you > from the app you''re intending to build. > > > ??? > Jenna Fox > > > On Monday, 19 December 2011 at 9:50 AM, icepapih at lavabit.com wrote: > >> Sure, but say that you want to have lots and lots of controllers, I >> don''t >> think anyone wants to sit there and write a module for each one to be >> honest. >> >> And with that way of thinking we shouldn''t even be able to set :views. >> We >> would have to write a module App::Views for every view. >> set :views is magic, but it is not a bad kind of magic. This is just >> basic >> stuff to make a web app pleasant to develop. >> >> And I know set :views is partially so we can use any markup engine we >> want. But not being able to do the same for all the others is silly in >> my >> humble opinion. >> >> Compared to things found in rails it doesn''t even come close to magic >> where you have no clue of what''s going on or how it works. It''s not like >> you have to take it even if you don''t want it either. You have to set it >> yourself, and that eliminates the feeling of magic for me. >> >> > The regular way of doing this with requires is simply that your >> > ''controller'' files look like this: >> > >> > module MyApp::Controllers >> > class PonyX >> > def get id >> > .. logic to look up pony with id .. >> > end >> > end >> > end >> > >> > This can even be generalized further I expect, to >> > >> > class MyApp::Controllers::PonyX >> > ??? >> > end >> > >> > This way you totally avoid weird evaling hacks, and are just writing >> plain >> > old straight forward ruby code with no magic (as is the Camping way). >> It >> > works because camping allows you to reopen modules and classes again >> and >> > again by defining them several times, adding new classes or adding new >> > methods to existing classes. >> > >> > >> > ??? >> > Jenna Fox >> > >> > >> > On Monday, 19 December 2011 at 8:56 AM, icepapih at lavabit.com >> (mailto:icepapih at lavabit.com) wrote: >> > >> > > What I am doing now is basically the same as requiring. If I do >> require >> > > with all the files, they don''t become a part of the controllers >> module. >> > > >> > > The problem is that having to require (or in my case ''add'') ever >> > > controller is *not* a very good way to work. It would be much better >> to >> > > be >> > > able to just do: >> > > >> > > set :controllers, *path to controllers* >> > > >> > > Because in the long run, that saves you time, and a bunch of boring >> and >> > > tedious work. >> > > >> > > The problem isn''t that the solution I currently have doesn''t work, >> this >> > > is >> > > just a suggestion to make Camping so much better. >> > > >> > > > I don''t think I understand the problem - can''t you just `require` >> all >> > > > the files with controllers? >> > > > >> > > > -- Matma Rex >> > > > _______________________________________________ >> > > > Camping-list mailing list >> > > > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) >> > > > http://rubyforge.org/mailman/listinfo/camping-list >> > > > >> > > > ____________________________________________________________________________________ >> > > > Find aldi jobs Online Get Started Now. >> > > > http://click.lavabit.com/db5fe7a9kai9wirqj77kjjiskdphxcqqrdiye5hkpuyeyn1bah8y/ >> > > > ____________________________________________________________________________________ >> > > > >> > > >> > > >> > > >> > > >> > > >> > > _______________________________________________ >> > > Camping-list mailing list >> > > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) >> > > http://rubyforge.org/mailman/listinfo/camping-list >> > > >> > >> > >> > >> > >> > >> > ____________________________________________________________________________________ >> > Learn How To Get Your Certification & Training As A Radiology >> Technician. >> > http://click.lavabit.com/5rmgod5iesh68xxeayxmjfqgo5fc3dqbm7m94shsxktoioehr3cb/ >> > ____________________________________________________________________________________ >> > _______________________________________________ >> > Camping-list mailing list >> > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) >> > http://rubyforge.org/mailman/listinfo/camping-list >> > >> >> >> >> >> _______________________________________________ >> Camping-list mailing list >> Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) >> http://rubyforge.org/mailman/listinfo/camping-list >> >> > > > > > ____________________________________________________________________________________ > Electronics at Wholesale Prices Stop Paying Retail and Save Now! > http://click.lavabit.com/rapndc7nckabfio8inkeip6dy7n9s4bucqfpmaisep496gauacxy/ > ____________________________________________________________________________________ > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list >
On Mon, Dec 19, 2011 at 19:38, <icepapih at lavabit.com> wrote:> Okay sure, you can make it simpler, but you still have to type a bunch of > stuff when you are making a controller. > > And now that we have ''set :views'' I think it comes with to add the other > stuff because you immediately think, oh well then I can set controllers to > right? But you can''t. That was actually the first thing I tried when I was > gonna solve the problem, which says something. How will it work? The same > way that ''set :views'' works of course.Loading views is more complex than loading plain Ruby files, so this is why it''s> And what you kind of have to consider is that you will always have to > learn how to use something. I mean if you didn''t want any magic at all you > wouldn''t turn to a framework, you would sit there and write you own. You > still have to learn how R works when using camping for example.. And how > is the relationship between the model, the view and the controller > defined? You always have to learn things when turning to a framework. > > And let''s not forget that this is NOT forced on you, if you wanted to skip > all of this and just require ever controller you can do that if you want > to. This is just a trick that you can use if you want to. That''s really > what I like about Camping, it doesn''t force a bunch of stuff on you. There > is things that you can do if you want to. > > For example when naming your controllers. You CAN name them ''class PageN'' > instead of ''class Page < R ''/page/(\d+)''. And that''s also magic. It isn''t > magic that you have to use. But you can, that''s what I love Camping for. > > There''s probably other examples of magic in Camping that I either don''t > know of or can think of. > > Being able to set :views is one of the best things I''ve been able to do > since starting Camping. And set :controllers would be just as wonderful. > > So just consider it.I certainly understand your points, but: 1. Bytes are precious 2. These are just cleverly disguised `require`s 3. You can no longer load the files with a regular `require` Writing `require "app/controllers/foo" 5 times isn''t *that* much more code. Beside, you don''t have to do the one-file-per-controller. It''s perfectly fine with many controllers in one file. I just think it provides too little value for the bytes it takes to implement it. Nothing stops us from implementing it as an extension (or whatever it should be called) though :-)
> Bytes are precious > Nothing stops us from implementing it as an extension (or whatever it > should be called) though :-)Allright, let''s do that when 2.2 is out then :) -- Twitter: http://twitter.com/bitpuffin/ Blog: http://bitpuffin.tumblr.com/ Github: http://github.com/milkshakepanda/