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, icepa...@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, icepa...@lavabit.com
>> (mailto:icepa...@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@rubyforge.org (mailto:Camping-list@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@rubyforge.org (mailto:Camping-list@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@rubyforge.org (mailto:Camping-list@rubyforge.org)
>> > http://rubyforge.org/mailman/listinfo/camping-list
>> >
>>
>>
>>
>>
>> _______________________________________________
>> Camping-list mailing list
>> Camping-list@rubyforge.org (mailto:Camping-list@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@rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>
_______________________________________________
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list
