Re: Mab: The tiny Markaby-alternative
2011/12/18 Bartosz Dziewoński matma@gmail.com: I don't have time to look thru now, but it doesn't seem to support boolean attributes (e.g. `input checked:true` should render input checked=checked /)? I was very much missing this feature in old Markaby, and finally even wrote a patch, as you might remember[1]. That's actually supported. If an attribute is `true` it will use the attribute name as the value. (so checked: true is the same as checked: checked). Also, false and nil attributes won't be included. It'd probably be quite easy to add, and after all it was included in the latest 0.7.2 version. [1] https://github.com/markaby/markaby/commit/999c418e3c096d2007d18c0a118390bd07d40eb0 -- Matma Rex ___ 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
Re: setting controllers etc
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 ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: setting controllers etc
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
Re: Markaby license issue
On Mon, Dec 19, 2011 at 19:10, Dave Everitt dever...@innotts.co.uk wrote: Magnus: this commit implements a tiny and fast Markaby-alternative (called Mab) ... it's completely inline in camping/mab.rb, but it should be fairy easy to create another Rubygem where we could implement for advanced features (indentation, AJAX-stuff, whatever). (git pull https://github.com/camping/camping mab || https://github.com/camping/camping/pull/50) How do Rumble/Mab square up regarding -XHTML +HTML4/5? Mab only supports HTML in the sense that it creates tags like br instead of br /. It has a list of tag names it supports, which includes pretty much everything in HTML4 and 5. ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Plan for 2.2
- I've been rewriting the Reloader/Server code a bit to support rackup-files too. I want to merge that. - Resolve the Markaby-thingie. - Figure out how to deal with static files (see other thread). - Figure out how to handle extensions to Camping (see other thread). Anything else? // Magnus Holm ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Camping Server: automatically serve static files from public/
I've been thinking about adding static files support for the Camping Server, but I'm wondering how it should work. Alternative 1: app.rb public public/style.css # example Alternative 2: app.rb app/public app/public/style.css # example And secondly, how would it work if you have multiple applications? camping app.rb app2.rb And should files be served from where it's located or where it's run? app.rb # = contains `require app2` app/public/foo.html app2.rb # = the actual app app2/public/foo.html Should /foo.html be served from app/public or app2/public? // Magnus Holm ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Mab: The tiny Markaby-alternative
Stick with the way we're doing it. I only use markaby when it's easier/prettier to use then HAML (quick one-line helpers and the like). Dave On Mon, Dec 19, 2011 at 4:26 PM, Magnus Holm judo...@gmail.com wrote: On Mon, Dec 19, 2011 at 21:34, Isak Andersson icepa...@lavabit.com wrote: My suggestion would be to make it Markaby 2.0 (of course, once it's running and mostly backwards-compatible), keeping the old gem name, and to develop on a branch in markaby repo. Yeah, we should more or less do a rewrite and make it properly open source. You are allowed to make something with the same name aren't you? I mean there is songs with the same names after all. So what we would have wouldn't exactly be Markaby but it would be used exactly like Markaby. We could make it smaller/faster and more up to date :) Just so everyone knows: Camping doesn't depend on Markaby today. It's only loaded when you actually try to use it. Would you suggest that we switch to a hard dependency on Markaby, or should we continue what we're doing today? ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list -- Dave ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Camping Server: automatically serve static files from public/
Plus people familiar with - or switching from ;-) - Rails and other frameworks would also feel at home. On 12/19/2011 3:46 PM, Jenna Fox wrote: Mmm that's true. Lets stick with that. --- Jenna Fox On Tuesday, 20 December 2011 at 9:37 AM, Magnus Holm wrote: On Mon, Dec 19, 2011 at 23:26, Jenna Fox a...@creativepony.com mailto:a...@creativepony.com wrote: 'public' is a weird word which has special meaning in the context of web development for legacy reasons. I think we could find a better word. 'Resources', 'web', 'files'? Phusion Passenger uses 'public' to run a Rack-application, so it certainly makes things easier if we use the same convention. ___ 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 http://rubyforge.org/mailman/listinfo/camping-list ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Markaby license issue
XHTML5 is a fancy name for the way the HTML5 spec grudgingly allows the use of XML-like syntax, allowing for XML Builders like current markaby to be technically allowable as valid HTML. It's not 'real' in that they don't provide validators for it and browsers aren't supposed to parse it as XML or support any XML features. The HTML spec suggests it be avoided if possible, and I agree, on the grounds that XML-style syntax gives people the incorrect impression that a document maybe valid XML. In most cases, that's not true. It might also give people the impression that they could use XML features, which is also not true. XHTML is a dead standard. Long live HTML with XML-style boolean attributes and self closing tags permitted! And long live Nokogiri/Beautiful Soup - the easy and friendly way to parse any sort of document, regardless if it pretends to be XML or is just plain friendly compact HTML. — Jenna Fox On Tuesday, 20 December 2011 at 10:09 AM, Dave Everitt wrote: Small note: XHTML did survive, it's XHTML2 which didn't: there's an XML version of HTML5 called XHTML5. We now return to your regularly scheduled discussion. I didn't know about XHTML5 and can't find any recent information? - DaveE ___ 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 http://rubyforge.org/mailman/listinfo/camping-list
Re: Mab: The tiny Markaby-alternative
So then I'd have to remember it's the opposite of the way it's been? :P Dave On Mon, Dec 19, 2011 at 5:53 PM, Jenna Fox a...@creativepony.com wrote: If no hard dependancies, can we switch it around so core camping is in a camping-seedling gem, and the regular camping gem is actually the one with all the omnibus? I always forget when setting up a new system and end up confused why camping isn't working — Jenna Fox On Tuesday, 20 December 2011 at 9:52 AM, Dave Everitt wrote: switch to a hard dependency on Markaby, or should we continue what we're doing today? no hard dependency, continue as today - DaveE ___ 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 -- Dave ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Mab: The tiny Markaby-alternative
Nah I'd still just think I want camping! I'll install camping! but then it'd just work :P — Jenna Fox On Tuesday, 20 December 2011 at 1:15 PM, David Susco wrote: So then I'd have to remember it's the opposite of the way it's been? :P Dave On Mon, Dec 19, 2011 at 5:53 PM, Jenna Fox a...@creativepony.com (mailto:a...@creativepony.com) wrote: If no hard dependancies, can we switch it around so core camping is in a camping-seedling gem, and the regular camping gem is actually the one with all the omnibus? I always forget when setting up a new system and end up confused why camping isn't working — Jenna Fox On Tuesday, 20 December 2011 at 9:52 AM, Dave Everitt wrote: switch to a hard dependency on Markaby, or should we continue what we're doing today? no hard dependency, continue as today - DaveE ___ 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 -- Dave ___ 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 http://rubyforge.org/mailman/listinfo/camping-list
Re: Markaby license issue
Yep! Granted, if you serve it with an XML MIME type, it must be able to be parsed with an XML parser, so none of that p bthis iis/b insane/i stuff! But still... I actually like XML. There are some of us in Ruby... ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Markaby license issue
I tried to use that crazy stuff recently and it just doesn't work, in webkit at least. — Jenna On 20/12/2011, at 4:34 PM, Steve Klabnik st...@steveklabnik.com wrote: Yep! Granted, if you serve it with an XML MIME type, it must be able to be parsed with an XML parser, so none of that p bthis iis/b insane/i stuff! But still... I actually like XML. There are some of us in Ruby... ___ 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
