From IcePapih at lavabit.com Tue Dec 6 15:26:19 2011 From: IcePapih at lavabit.com (Isak Andersson) Date: Tue, 06 Dec 2011 21:26:19 +0100 Subject: Riak on Camping Message-ID: Good day, does anyone here have a clue on how to make use of the NoSQL database "Riak" with Camping? I am building my website and Riak seems like pretty much the ultimate database! This would probably ruin every little feature in ActiveRecord, I don't think I'd be able to do any has_many's or belongs_to but I'd LOVE to be proven wrong. As far as I know (but maybe I should do some research before saying it) there isn't any adapter for Riak yet. I want to use it anyways though, connecting nodes around the globe! |m| -Isak Andersson TLB -- Using the Opera email client: http://www.opera.com/mail/ From a at creativepony.com Tue Dec 6 17:23:47 2011 From: a at creativepony.com (Jenna Fox) Date: Wed, 7 Dec 2011 09:23:47 +1100 Subject: Riak on Camping In-Reply-To: References: Message-ID: You can't use ActiveRecord with map-reduce databases anyhow, without loosing a bunch of performance and features. It's best to use a specialised adaptor just for Riak. It looks a bit similar to CouchDB, so you might also like to have a look at that if you can't find any good rubygems for riak. CouchDB supports all that delicious p2p replication stuff too, sans the weird 'enterprise' version with extra withheld features. ? Jenna On 07/12/2011, at 7:26 AM, Isak Andersson wrote: > Good day, does anyone here have a clue on how to make use of the NoSQL database "Riak" with Camping? > > I am building my website and Riak seems like pretty much the ultimate database! > This would probably ruin every little feature in ActiveRecord, I don't think I'd be able to do any has_many's or belongs_to > but I'd LOVE to be proven wrong. As far as I know (but maybe I should do some research before saying it) there isn't any > adapter for Riak yet. > > I want to use it anyways though, connecting nodes around the globe! |m| > > -Isak Andersson > > TLB > > -- > Using the Opera email client: http://www.opera.com/mail/ > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From IcePapih at lavabit.com Tue Dec 6 18:09:41 2011 From: IcePapih at lavabit.com (Isak Andersson) Date: Wed, 07 Dec 2011 00:09:41 +0100 Subject: Riak on Camping In-Reply-To: References: Message-ID: Nah, that's what I imagined. CouchDB indeed seems a lot like Riak but I think I'm gonna stick to Riak as it is attractive somehow! There seems to be some rubygems one that is only 0.0.1 :/ which is an adapter. And another one called "riak-client" which seems to be the most relevant one. Looking in the documentation sure makes it look right. It gave me the impression first that it was some ruby reimplementation of Riak first (which would be kind of dumb) but it's a toolkit. It uses something called "Ripple" which has an "ActiveModel compatible modeling layer inspired by ActiveRecord, DataMapper and MongoMapper". Now I don't know if that means it's possible to go has_many etc. I guess we'll see when I start using it! Thanks for your help! Also (not relevant) I fixed the CSS for whywentcamping.com (at least it should be fixed) to be compatible with Opera browser. It is pushed to the Github repo, all we really need to do is to update the code for the actual site. I have no idea on how to do that, someone who knows should probably look in to that. Then I can finally go to the site without having to switch browser ;) Cheers! Isak Den 2011-12-06 23:23:47 skrev Jenna Fox : > You can't use ActiveRecord with map-reduce databases anyhow, without > loosing a bunch of performance and features. It's best to use a > specialised adaptor just for Riak. It looks a bit similar to CouchDB, so > you might also like to have a look at that if you can't find any good > rubygems for riak. > > CouchDB supports all that delicious p2p replication stuff too, sans the > weird 'enterprise' version with extra withheld features. > > ? > Jenna > > On 07/12/2011, at 7:26 AM, Isak Andersson wrote: > >> Good day, does anyone here have a clue on how to make use of the NoSQL >> database "Riak" with Camping? >> >> I am building my website and Riak seems like pretty much the ultimate >> database! >> This would probably ruin every little feature in ActiveRecord, I don't >> think I'd be able to do any has_many's or belongs_to >> but I'd LOVE to be proven wrong. As far as I know (but maybe I should >> do some research before saying it) there isn't any >> adapter for Riak yet. >> >> I want to use it anyways though, connecting nodes around the globe! |m| >> >> -Isak Andersson >> >> TLB >> >> -- >> Using the Opera email client: http://www.opera.com/mail/ >> >> _______________________________________________ >> Camping-list mailing list >> Camping-list at rubyforge.org >> http://rubyforge.org/mailman/listinfo/camping-list > > > > ____________________________________________________________________________________ > We compare the best offers just for U. Our top 5 selection. Take the > chance to > make a good deal! > http://click.lavabit.com/nu7xj7eg4a6p6obzf97i5765y7qxrprs8m4xuj7zwdcn96x9uu5b/ > ____________________________________________________________________________________ -- Sent from Opera web browser. http://www.opera.com/mail/ From a at creativepony.com Tue Dec 6 19:32:16 2011 From: a at creativepony.com (Jenna Fox) Date: Wed, 7 Dec 2011 11:32:16 +1100 Subject: Riak on Camping In-Reply-To: References: Message-ID: <5166C96C-8DF6-4348-93FF-57CD65F2A3C7@creativepony.com> I can deploy that update to whywentcamping later. ? Jenna On 07/12/2011, at 10:09 AM, Isak Andersson wrote: > Nah, that's what I imagined. CouchDB indeed seems a lot like Riak but I think > I'm gonna stick to Riak as it is attractive somehow! > There seems to be some rubygems one that is only 0.0.1 :/ which is an adapter. > And another one called "riak-client" which seems to be the most relevant one. > Looking in the documentation sure makes it look right. > > It gave me the impression first that it was some ruby reimplementation of > Riak first (which would be kind of dumb) but it's a toolkit. > > It uses something called "Ripple" which has an "ActiveModel compatible modeling layer > inspired by ActiveRecord, DataMapper and MongoMapper". Now I don't know if that means it's possible to go has_many etc. > I guess we'll see when I start using it! > > Thanks for your help! > > Also (not relevant) I fixed the CSS for whywentcamping.com (at least it should be fixed) to be compatible with Opera browser. > It is pushed to the Github repo, all we really need to do is to update the code for the actual site. > I have no idea on how to do that, someone who knows should probably look in to that. > Then I can finally go to the site without having to switch browser ;) > > Cheers! > > Isak > > > > Den 2011-12-06 23:23:47 skrev Jenna Fox : > >> You can't use ActiveRecord with map-reduce databases anyhow, without loosing a bunch of performance and features. It's best to use a specialised adaptor just for Riak. It looks a bit similar to CouchDB, so you might also like to have a look at that if you can't find any good rubygems for riak. >> >> CouchDB supports all that delicious p2p replication stuff too, sans the weird 'enterprise' version with extra withheld features. >> >> ? >> Jenna >> >> On 07/12/2011, at 7:26 AM, Isak Andersson wrote: >> >>> Good day, does anyone here have a clue on how to make use of the NoSQL database "Riak" with Camping? >>> >>> I am building my website and Riak seems like pretty much the ultimate database! >>> This would probably ruin every little feature in ActiveRecord, I don't think I'd be able to do any has_many's or belongs_to >>> but I'd LOVE to be proven wrong. As far as I know (but maybe I should do some research before saying it) there isn't any >>> adapter for Riak yet. >>> >>> I want to use it anyways though, connecting nodes around the globe! |m| >>> >>> -Isak Andersson >>> >>> TLB >>> >>> -- >>> Using the Opera email client: http://www.opera.com/mail/ >>> >>> _______________________________________________ >>> Camping-list mailing list >>> Camping-list at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/camping-list >> >> >> >> ____________________________________________________________________________________ >> We compare the best offers just for U. Our top 5 selection. Take the chance to >> make a good deal! >> http://click.lavabit.com/nu7xj7eg4a6p6obzf97i5765y7qxrprs8m4xuj7zwdcn96x9uu5b/ >> ____________________________________________________________________________________ > > > -- > Sent from Opera web browser. http://www.opera.com/mail/ > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From judofyr at gmail.com Fri Dec 16 15:13:13 2011 From: judofyr at gmail.com (Magnus Holm) Date: Fri, 16 Dec 2011 21:13:13 +0100 Subject: Camping.use Before, Rack::File.new('public') Message-ID: Here's one useful snippet: def (Before="").new(a,*o)Rack::Cascade.new(o< References: Message-ID: I think that's immensely useful. It'll allow me to keep JS/CSS/HTML separate from the app files but still packaged with the app. Dave On Fri, Dec 16, 2011 at 3:13 PM, Magnus Holm wrote: > Here's one useful snippet: > > ?def (Before="").new(a,*o)Rack::Cascade.new(o< > This means that this app: > > ?module App > ? ?use Before, Rack::File.new('public') > ?end > > Will pass all requests through Rack::File.new('public') first, and > only proceed to App if that returns 404. This can be very useful for > serving static stuff in development mode (Rack::File will serve files > from the 'public' directory if it matches the URL; e.g. > ./public/jquery.js will be available at localhost:3301/jquery.js) > > Maybe we should add it to camping.rb? > > // Magnus Holm > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list -- Dave From matma.rex at gmail.com Fri Dec 16 16:31:30 2011 From: matma.rex at gmail.com (=?UTF-8?Q?Bartosz_Dziewo=C5=84ski?=) Date: Fri, 16 Dec 2011 22:31:30 +0100 Subject: Camping.use Before, Rack::File.new('public') In-Reply-To: References: Message-ID: I usually just use Rack::Static: module App use Rack::Static, :urls => ['/static'] end This would serve ./static/jquery.js at localhost:3301/static/jquery.js, though - with the directory included in URL - but will also serve files from subdirectories recursively (I don't know if Rack::File does this). -- Matma Rex From judofyr at gmail.com Sat Dec 17 04:34:05 2011 From: judofyr at gmail.com (Magnus Holm) Date: Sat, 17 Dec 2011 10:34:05 +0100 Subject: Camping.use Before, Rack::File.new('public') In-Reply-To: References: Message-ID: 2011/12/16 Bartosz Dziewo?ski : > I usually just use Rack::Static: > > module App > ?use Rack::Static, :urls => ['/static'] > end > > This would serve ./static/jquery.js at > localhost:3301/static/jquery.js, though - with the directory included > in URL - but will also serve files from subdirectories recursively (I > don't know if Rack::File does this). Yeah, that works, but I hate how /static/ is needed in the URL. The only reason Before is actually needed is because no-one in Rack thought of creating a Rack::File-ish middleware. Rack::Cascade works nice, but it can't be used as a middleware. This simply turns Rack::Cascade into a middleware. From judofyr at gmail.com Sat Dec 17 17:33:21 2011 From: judofyr at gmail.com (Magnus Holm) Date: Sat, 17 Dec 2011 23:33:21 +0100 Subject: Markaby license issue Message-ID: Okay, we might have a slight problem: It doesn't seem that Markaby ever had a specific license. This means that it's currently "Copyright ? _why" and we might not have the right to re-distribute (or contribute to) it. So first of all: if you've ever seen a LICENSE/COPYING-file (or something else that explicitly says the license) related to Markaby, please let us know! If not, I'm wondering what we should do. I don't think that _why would really care if people brought his libraries forward, but I kinda get an uneasy feeling about this. // Magnus Holm From a at creativepony.com Sat Dec 17 18:42:38 2011 From: a at creativepony.com (Jenna Fox) Date: Sun, 18 Dec 2011 10:42:38 +1100 Subject: Markaby license issue In-Reply-To: References: Message-ID: Markaby is kind of bad though. It has problems, like it doesn't cope well with boolean attributes (last I looked anyway), and it's totes out of date with HTML5 and all that. Could we take this opportunity to start a new project, with Markaby compatible syntax (at least optionally) based around modern web standards, with direct straight forward support for html5 syntax, modern tags and attributes, better validation (perhaps by scanning the actual validator files produced by the html5 working group, or at least a format programatically derived from it so we need not maintain tedious lists?), and an explicit widgeting system where you can define your own virtual tags, which emit tags and code to do higher level jobs - for instance a blueprint module, supporting the twitter blueprint framework with nice APIs, allowing it's use almost akin to a desktop windowing toolkit. We could even have extensions for things like ajax, so you could add onclick properties with proc values, such that an ajax call back to the server (or websockets or whatever) lets the server do stuff and mutate the dom or replace the page entirely. Native support for eventsource could be enabled with Shoes-like animate tags, where the server would run code from time to time and stream out updates to the viewer. When Why made the original Hackety Hack atop web tech, the web was immature and buggy for writing apps, and the project failed from a mix of Gecko being really nasty, and the web being a bad platform for that sort of software. I think we have a chance for a do-over. These days it's easy to do things like script a textarea in to being a richly formatted text or code editor (without needing to fuss around with the horrible contentEditable), or use a canvas tag or svg to render fun shapes and animations, or play sounds and videos. CSS can run animations and transitions at a C level, and can do hardware 3d transforms. WebGL is nearing too, and could potentially be interfaced via a websocket, the same way linux apps interface with an X11 server today. Doesn't that sound like a cool thing? ? Jenna Fox On Sunday, 18 December 2011 at 9:33 AM, Magnus Holm wrote: > Okay, we might have a slight problem: > > It doesn't seem that Markaby ever had a specific license. This means > that it's currently "Copyright ? _why" and we might not have the right > to re-distribute (or contribute to) it. > > So first of all: if you've ever seen a LICENSE/COPYING-file (or > something else that explicitly says the license) related to Markaby, > please let us know! > > If not, I'm wondering what we should do. I don't think that _why would > really care if people brought his libraries forward, but I kinda get > an uneasy feeling about this. > > // Magnus Holm > _______________________________________________ > 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: From danbryan at gmail.com Sat Dec 17 18:59:24 2011 From: danbryan at gmail.com (Daniel Bryan) Date: Sun, 18 Dec 2011 10:59:24 +1100 Subject: Markaby license issue In-Reply-To: References: Message-ID: <4691F47A8BC24822999D01A8CC31DBD3@gmail.com> > We could even have extensions for things like ajax, so you could add onclick properties with proc values, such that an ajax call back to the server (or websockets or whatever) lets the server do stuff and mutate the dom or replace the page entirely. I really like this idea, but don't you risk getting into a situation where you're maintaining all your application logic in a view? In an ajax-heavy app you'd end up with a couple of controllers and then heaps of code in your view. I suppose elements could support a property like that's basically like the R() method for building link hrefs, but with semantics that specifically make them useful for defining AJAX handlers. One problem for me with this stuff in any web framework is that the distinction between standard handlers and AJAX ones is (necessarily) foggy. I wonder if there's a clear solution to this that doesn't involve uncomfortably shoehorning handlers into one category of the other. On Sunday, 18 December 2011 at 10:42 AM, Jenna Fox wrote: > Markaby is kind of bad though. It has problems, like it doesn't cope well with boolean attributes (last I looked anyway), and it's totes out of date with HTML5 and all that. Could we take this opportunity to start a new project, with Markaby compatible syntax (at least optionally) based around modern web standards, with direct straight forward support for html5 syntax, modern tags and attributes, better validation (perhaps by scanning the actual validator files produced by the html5 working group, or at least a format programatically derived from it so we need not maintain tedious lists?), and an explicit widgeting system where you can define your own virtual tags, which emit tags and code to do higher level jobs - for instance a blueprint module, supporting the twitter blueprint framework with nice APIs, allowing it's use almost akin to a desktop windowing toolkit. We could even have extensions for things like ajax, so you could add onclick properties with proc values, such that an ajax call back to the server (or websockets or whatever) lets the server do stuff and mutate the dom or replace the page entirely. Native support for eventsource could be enabled with Shoes-like animate tags, where the server would run code from time to time and stream out updates to the viewer. > > When Why made the original Hackety Hack atop web tech, the web was immature and buggy for writing apps, and the project failed from a mix of Gecko being really nasty, and the web being a bad platform for that sort of software. I think we have a chance for a do-over. These days it's easy to do things like script a textarea in to being a richly formatted text or code editor (without needing to fuss around with the horrible contentEditable), or use a canvas tag or svg to render fun shapes and animations, or play sounds and videos. CSS can run animations and transitions at a C level, and can do hardware 3d transforms. WebGL is nearing too, and could potentially be interfaced via a websocket, the same way linux apps interface with an X11 server today. > > Doesn't that sound like a cool thing? > > > ? > Jenna Fox > > > On Sunday, 18 December 2011 at 9:33 AM, Magnus Holm wrote: > > > Okay, we might have a slight problem: > > > > It doesn't seem that Markaby ever had a specific license. This means > > that it's currently "Copyright ? _why" and we might not have the right > > to re-distribute (or contribute to) it. > > > > So first of all: if you've ever seen a LICENSE/COPYING-file (or > > something else that explicitly says the license) related to Markaby, > > please let us know! > > > > If not, I'm wondering what we should do. I don't think that _why would > > really care if people brought his libraries forward, but I kinda get > > an uneasy feeling about this. > > > > // Magnus Holm > > _______________________________________________ > > 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: From steve at steveklabnik.com Sat Dec 17 20:47:11 2011 From: steve at steveklabnik.com (Steve Klabnik) Date: Sat, 17 Dec 2011 20:47:11 -0500 Subject: Markaby license issue In-Reply-To: <4691F47A8BC24822999D01A8CC31DBD3@gmail.com> References: <4691F47A8BC24822999D01A8CC31DBD3@gmail.com> Message-ID: A wild project appears: http://krainboltgreene.github.com/dapper-dan/ From a at creativepony.com Sat Dec 17 20:49:11 2011 From: a at creativepony.com (Jenna Fox) Date: Sun, 18 Dec 2011 12:49:11 +1100 Subject: Markaby license issue In-Reply-To: References: <4691F47A8BC24822999D01A8CC31DBD3@gmail.com> Message-ID: <59CE0076D2794934B664A0F35F0822DF@creativepony.com> Nice! Lets just all use this thing! What say you, everyone? ? Jenna Fox On Sunday, 18 December 2011 at 12:47 PM, Steve Klabnik wrote: > A wild project appears: http://krainboltgreene.github.com/dapper-dan/ > _______________________________________________ > 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: From judofyr at gmail.com Sun Dec 18 03:27:18 2011 From: judofyr at gmail.com (Magnus Holm) Date: Sun, 18 Dec 2011 09:27:18 +0100 Subject: Markaby license issue In-Reply-To: References: <4691F47A8BC24822999D01A8CC31DBD3@gmail.com> Message-ID: On Sun, Dec 18, 2011 at 02:47, Steve Klabnik wrote: > A wild project appears: http://krainboltgreene.github.com/dapper-dan/ Some problems: * It doesn't support CSS proxy (div.wrapper! { ? ] == div(:id => 'wrapper') { ? }) * It doesn't escape stuff * It doesn't specify its dependencies correctly (crack.rb) * It loads awesome_print at runtime * The released version on RubyGems doesn't actually work Everything else than the first issue is easy to fix. CSS proxies might require some bigger refactoring to implement. That said, it's not hard to implement something Markaby-ish. I experimented a bit, and ended up with a fast Markaby-replacement in 130 LoC: https://github.com/judofyr/rumble. We might be able to adapt it. From a at creativepony.com Sun Dec 18 07:19:22 2011 From: a at creativepony.com (Jenna Fox) Date: Sun, 18 Dec 2011 23:19:22 +1100 Subject: Markaby license issue In-Reply-To: References: <4691F47A8BC24822999D01A8CC31DBD3@gmail.com> Message-ID: <0E74E183891A450A9DBA11235FAC6649@creativepony.com> Aw.. That is rather disappointing. But still, I see this problem as a chance to be reborn anew. Fresh and clean of the bad lessons learnt by Markaby. We did learn some lessons, didn't we? ? Jenna Fox On Sunday, 18 December 2011 at 7:27 PM, Magnus Holm wrote: > On Sun, Dec 18, 2011 at 02:47, Steve Klabnik wrote: > > A wild project appears: http://krainboltgreene.github.com/dapper-dan/ > > > Some problems: > > * It doesn't support CSS proxy (div.wrapper! { ? ] == div(:id => > 'wrapper') { ? }) > * It doesn't escape stuff > * It doesn't specify its dependencies correctly (crack.rb) > * It loads awesome_print at runtime > * The released version on RubyGems doesn't actually work > > Everything else than the first issue is easy to fix. CSS proxies might > require some bigger refactoring to implement. > > That said, it's not hard to implement something Markaby-ish. I > experimented a bit, and ended up with a fast Markaby-replacement in > 130 LoC: https://github.com/judofyr/rumble. We might be able to adapt > it. > _______________________________________________ > 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: From IcePapih at lavabit.com Sun Dec 18 07:29:22 2011 From: IcePapih at lavabit.com (Isak Andersson) Date: Sun, 18 Dec 2011 13:29:22 +0100 Subject: Markaby license issue In-Reply-To: <59CE0076D2794934B664A0F35F0822DF@creativepony.com> References: <4691F47A8BC24822999D01A8CC31DBD3@gmail.com> <59CE0076D2794934B664A0F35F0822DF@creativepony.com> Message-ID: <83d224ae-f6ea-44df-8afa-76efeeddde20@email.android.com> Not really sure to be honest. It looks very nice and is basically markaby. But I think we should either create our own, or fork it so we could have our own cool stuff, like the AJAX things someone mentioned. Also, it would be cool if you could also write JS in ruby easily with camping out of the box. I know Coffeescript is similar but does it use ruby syntax? I just think we should have all the good stuff in our own language. So we can make it work well with camping. Like having an optional module for scripts that you can use in any view to make stuff dry. Or you could write scripts in the view. I think we could do something cool -- Skickat fr?n min Android-telefon med K-9 E-post. Urs?kta min f?ordighet. Jenna Fox skrev: Nice! Lets just all use this thing! What say you, everyone? ? Jenna Fox On Sunday, 18 December 2011 at 12:47 PM, Steve Klabnik wrote: A wild project appears: http://krainboltgreene.github.com/dapper-dan/ _______________________________________________ Camping-list mailing list Camping-list at rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list Looking for hosting web? Find it at Www.sandglass.com http://click.lavabit.com/wjq784xbw67pm3h5ryf3kjnsycsihms3uo8gg1qdyuphy7ixobbb/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From matma.rex at gmail.com Sun Dec 18 08:34:45 2011 From: matma.rex at gmail.com (=?UTF-8?Q?Bartosz_Dziewo=C5=84ski?=) Date: Sun, 18 Dec 2011 14:34:45 +0100 Subject: Markaby license issue In-Reply-To: <83d224ae-f6ea-44df-8afa-76efeeddde20@email.android.com> References: <4691F47A8BC24822999D01A8CC31DBD3@gmail.com> <59CE0076D2794934B664A0F35F0822DF@creativepony.com> <83d224ae-f6ea-44df-8afa-76efeeddde20@email.android.com> Message-ID: You can't really write Javascript in Ruby due to the way it (and its libraries like jQuery) handle functions. Sure, it could be done, but the code would be ugly. 2011/12/18, Isak Andersson : > Not really sure to be honest. > It looks very nice and is basically markaby. > > But I think we should either create our own, or fork it so we could have our > own cool stuff, like the AJAX things someone mentioned. > > Also, it would be cool if you could also write JS in ruby easily with > camping out of the box. I know Coffeescript is similar but does it use ruby > syntax? > > I just think we should have all the good stuff in our own language. So we > can make it work well with camping. > Like having an optional module for scripts that you can use in any view to > make stuff dry. Or you could write scripts in the view. > > I think we could do something cool > -- > Skickat fr?n min Android-telefon med K-9 E-post. Urs?kta min f?ordighet. > > Jenna Fox skrev: > > Nice! Lets just all use this thing! > > > What say you, everyone? > > > > ? > > Jenna Fox > > > On Sunday, 18 December 2011 at 12:47 PM, Steve Klabnik wrote: > > A wild project appears: http://krainboltgreene.github.com/dapper-dan/ > > _______________________________________________ > > Camping-list mailing list > > Camping-list at rubyforge.org > > http://rubyforge.org/mailman/listinfo/camping-list > > > Looking for hosting web? Find it at Www.sandglass.com > http://click.lavabit.com/wjq784xbw67pm3h5ryf3kjnsycsihms3uo8gg1qdyuphy7ixobbb/ > > -- -- Matma Rex From ruby at monnet-usa.com Sun Dec 18 09:45:18 2011 From: ruby at monnet-usa.com (Philippe Monnet) Date: Sun, 18 Dec 2011 07:45:18 -0700 Subject: Markaby license issue In-Reply-To: References: <4691F47A8BC24822999D01A8CC31DBD3@gmail.com> Message-ID: <4EEDFC7E.4020106@monnet-usa.com> Rumble seems like a good start. So what else would need to be done? On 12/18/2011 1:27 AM, Magnus Holm wrote: > On Sun, Dec 18, 2011 at 02:47, Steve Klabnik wrote: >> A wild project appears: http://krainboltgreene.github.com/dapper-dan/ > Some problems: > > * It doesn't support CSS proxy (div.wrapper! { ? ] == div(:id => > 'wrapper') { ? }) > * It doesn't escape stuff > * It doesn't specify its dependencies correctly (crack.rb) > * It loads awesome_print at runtime > * The released version on RubyGems doesn't actually work > > Everything else than the first issue is easy to fix. CSS proxies might > require some bigger refactoring to implement. > > That said, it's not hard to implement something Markaby-ish. I > experimented a bit, and ended up with a fast Markaby-replacement in > 130 LoC: https://github.com/judofyr/rumble. We might be able to adapt > it. > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From chneukirchen at gmail.com Sun Dec 18 09:49:43 2011 From: chneukirchen at gmail.com (Christian Neukirchen) Date: Sun, 18 Dec 2011 15:49:43 +0100 Subject: Markaby license issue In-Reply-To: (Jenna Fox's message of "Sun, 18 Dec 2011 10:42:38 +1100") References: Message-ID: <87hb0yq6ig.fsf@gmail.com> Jenna Fox writes: > the same way linux apps interface with an X11 server today. Hey, we've been there, 15 years ago: http://ftp.x.org/pub/X11R6.8.2/doc/libxrx.1.html -- Christian Neukirchen http://chneukirchen.org From icepapih at lavabit.com Sun Dec 18 13:08:51 2011 From: icepapih at lavabit.com (icepapih at lavabit.com) Date: Sun, 18 Dec 2011 19:08:51 +0100 (CET) Subject: setting controllers etc Message-ID: <32126.109.58.29.251.1324231731.squirrel@lavabit.com> 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 From judofyr at gmail.com Sun Dec 18 15:01:18 2011 From: judofyr at gmail.com (Magnus Holm) Date: Sun, 18 Dec 2011 21:01:18 +0100 Subject: Mab: The tiny Markaby-alternative Message-ID: https://github.com/camping/camping/pull/50 Right now 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). // Magnus Holm From matma.rex at gmail.com Sun Dec 18 16:26:16 2011 From: matma.rex at gmail.com (=?UTF-8?Q?Bartosz_Dziewo=C5=84ski?=) Date: Sun, 18 Dec 2011 22:26:16 +0100 Subject: Mab: The tiny Markaby-alternative In-Reply-To: References: Message-ID: 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 )? I was very much missing this feature in old Markaby, and finally even wrote a patch, as you might remember[1]. 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 From matma.rex at gmail.com Sun Dec 18 16:29:44 2011 From: matma.rex at gmail.com (=?UTF-8?Q?Bartosz_Dziewo=C5=84ski?=) Date: Sun, 18 Dec 2011 22:29:44 +0100 Subject: setting controllers etc In-Reply-To: <32126.109.58.29.251.1324231731.squirrel@lavabit.com> References: <32126.109.58.29.251.1324231731.squirrel@lavabit.com> Message-ID: I don't think I understand the problem - can't you just `require` all the files with controllers? -- Matma Rex From icepapih at lavabit.com Sun Dec 18 16:56:11 2011 From: icepapih at lavabit.com (icepapih at lavabit.com) Date: Sun, 18 Dec 2011 16:56:11 -0500 (EST) Subject: setting controllers etc In-Reply-To: References: <32126.109.58.29.251.1324231731.squirrel@lavabit.com> Message-ID: <16876.109.58.120.116.1324245371.squirrel@lavabit.com> 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/ > ____________________________________________________________________________________ > From a at creativepony.com Sun Dec 18 17:19:20 2011 From: a at creativepony.com (Jenna Fox) Date: Mon, 19 Dec 2011 09:19:20 +1100 Subject: setting controllers etc In-Reply-To: <16876.109.58.120.116.1324245371.squirrel@lavabit.com> References: <32126.109.58.29.251.1324231731.squirrel@lavabit.com> <16876.109.58.120.116.1324245371.squirrel@lavabit.com> Message-ID: 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: From icepapih at lavabit.com Sun Dec 18 17:50:11 2011 From: icepapih at lavabit.com (icepapih at lavabit.com) Date: Sun, 18 Dec 2011 17:50:11 -0500 (EST) Subject: setting controllers etc In-Reply-To: References: <32126.109.58.29.251.1324231731.squirrel@lavabit.com> <16876.109.58.120.116.1324245371.squirrel@lavabit.com> Message-ID: <20141.109.58.120.116.1324248611.squirrel@lavabit.com> 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 > From a at creativepony.com Sun Dec 18 18:47:59 2011 From: a at creativepony.com (Jenna Fox) Date: Mon, 19 Dec 2011 10:47:59 +1100 Subject: setting controllers etc In-Reply-To: <20141.109.58.120.116.1324248611.squirrel@lavabit.com> References: <32126.109.58.29.251.1324231731.squirrel@lavabit.com> <16876.109.58.120.116.1324245371.squirrel@lavabit.com> <20141.109.58.120.116.1324248611.squirrel@lavabit.com> Message-ID: <2B27F087ED4F479F9D2B85F60267139F@creativepony.com> "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: From judofyr at gmail.com Mon Dec 19 05:20:21 2011 From: judofyr at gmail.com (Magnus Holm) Date: Mon, 19 Dec 2011 11:20:21 +0100 Subject: setting controllers etc In-Reply-To: <2B27F087ED4F479F9D2B85F60267139F@creativepony.com> References: <32126.109.58.29.251.1324231731.squirrel@lavabit.com> <16876.109.58.120.116.1324245371.squirrel@lavabit.com> <20141.109.58.120.116.1324248611.squirrel@lavabit.com> <2B27F087ED4F479F9D2B85F60267139F@creativepony.com> Message-ID: On Mon, Dec 19, 2011 at 00:47, Jenna Fox 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 From judofyr at gmail.com Mon Dec 19 05:22:15 2011 From: judofyr at gmail.com (Magnus Holm) Date: Mon, 19 Dec 2011 11:22:15 +0100 Subject: Mab: The tiny Markaby-alternative In-Reply-To: References: Message-ID: 2011/12/18 Bartosz Dziewo?ski : > 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 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 at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list From deveritt at innotts.co.uk Mon Dec 19 08:39:01 2011 From: deveritt at innotts.co.uk (Dave Everitt) Date: Mon, 19 Dec 2011 13:39:01 +0000 Subject: setting controllers etc In-Reply-To: <2B27F087ED4F479F9D2B85F60267139F@creativepony.com> References: <32126.109.58.29.251.1324231731.squirrel@lavabit.com> <16876.109.58.120.116.1324245371.squirrel@lavabit.com> <20141.109.58.120.116.1324248611.squirrel@lavabit.com> <2B27F087ED4F479F9D2B85F60267139F@creativepony.com> Message-ID: <3D5CCBAF-226A-4C00-BEB9-23986313122F@innotts.co.uk> > 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: From deveritt at innotts.co.uk Mon Dec 19 13:10:31 2011 From: deveritt at innotts.co.uk (Dave Everitt) Date: Mon, 19 Dec 2011 18:10:31 +0000 Subject: Markaby license issue In-Reply-To: References: Message-ID: Been lurking, so offering an overview response: > Jenna: I see this problem as a chance to be reborn anew. This *does* seem like the opportunity to remake Markaby (continuing the _why legacy) 'for the 21st Century' that generates either optionally indented (n spaces) or minimised: HTML5 (at least what's definite so far) HTML4.01 (strict - no need to allow deprecated markup) but *not* the officially dead XHTML (or - for me - it's syntax e.g. self-closing br tags). > Phillipe: Rumble seems like a good start. (https://github.com/judofyr/rumble) > 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? Being primarily a front-ender who knows HTML/CSS backwards and HTML5 pretty well, I'd happily pitch in with this. > write JS in ruby easily with camping out of the box Not sure about that, as reinventing a (say) CoffeeScript-esque wheel seems redundant - I'd go for minimalism (Camping's strength), not expansion. Rewriting HTML as a 'Ruby DSL' makes sense, but both CSS and Javascript already have Less (plus descendants) and CoffeeScript (and, of course JQuery on top). But then I'd argue that knowing those languages is an essential WebUI skill anyway. DaveE > Okay, we might have a slight problem: > > It doesn't seem that Markaby ever had a specific license. This means > that it's currently "Copyright ? _why" and we might not have the > right to re-distribute (or contribute to) it. > > So first of all: if you've ever seen a LICENSE/COPYING-file (or > something else that explicitly says the license) related to Markaby, > please let us know! > > If not, I'm wondering what we should do. I don't think that _why > would really care if people brought his libraries forward, but I > kinda get an uneasy feeling about this. > > // Magnus Holm > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list From icepapih at lavabit.com Mon Dec 19 13:38:33 2011 From: icepapih at lavabit.com (icepapih at lavabit.com) Date: Mon, 19 Dec 2011 19:38:33 +0100 (CET) Subject: setting controllers etc In-Reply-To: <2B27F087ED4F479F9D2B85F60267139F@creativepony.com> References: <32126.109.58.29.251.1324231731.squirrel@lavabit.com> <16876.109.58.120.116.1324245371.squirrel@lavabit.com> <20141.109.58.120.116.1324248611.squirrel@lavabit.com> <2B27F087ED4F479F9D2B85F60267139F@creativepony.com> Message-ID: <32094.95.209.48.222.1324319913.squirrel@lavabit.com> 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 > From steve at steveklabnik.com Mon Dec 19 14:11:23 2011 From: steve at steveklabnik.com (Steve Klabnik) Date: Mon, 19 Dec 2011 14:11:23 -0500 Subject: Markaby license issue In-Reply-To: References: Message-ID: 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. From judofyr at gmail.com Mon Dec 19 14:14:37 2011 From: judofyr at gmail.com (Magnus Holm) Date: Mon, 19 Dec 2011 20:14:37 +0100 Subject: Markaby license issue In-Reply-To: References: Message-ID: On Mon, Dec 19, 2011 at 19:10, Dave Everitt 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
instead of
. It has a list of tag names it supports, which includes pretty much everything in HTML4 and 5. From matma.rex at gmail.com Mon Dec 19 14:16:24 2011 From: matma.rex at gmail.com (=?UTF-8?Q?Bartosz_Dziewo=C5=84ski?=) Date: Mon, 19 Dec 2011 20:16:24 +0100 Subject: Mab: The tiny Markaby-alternative In-Reply-To: References: Message-ID: 2011/12/19 Magnus Holm : > 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. >> I think this is a little inconsistent now. We're already checking whther a tag can have content according to an arbitrary list (taken from HTML5 standard, I suppose) - we should probably also check whether an attribute must have content, or can be boolean (or, to check neither - it would be cool if it was possible to disable this validation, I sometimes use Markaby for generating XML, or RSS feeds). There might exist valid reasons for passing `true`/`false` as attribute value and expecting it to show up (possibly for value attribute on select list options or radio buttons), as well as passing a truthy value that is not `true` itself (for example, Numeric#nonzero? returns either `false` or `self`, and one might want to have a checkbox checked or not according to it). Both of the above problems can be solved by using respectively `true_or_false.to_s` or `!!integer.nonzero?`, but both of these solutions are kind of ugly. I can change the code myself if you don't feel like it. :) -- Matma Rex From judofyr at gmail.com Mon Dec 19 14:26:09 2011 From: judofyr at gmail.com (Magnus Holm) Date: Mon, 19 Dec 2011 20:26:09 +0100 Subject: Mab: The tiny Markaby-alternative In-Reply-To: References: Message-ID: 2011/12/19 Bartosz Dziewo?ski : > 2011/12/19 Magnus Holm : >> 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. >>> > > I think this is a little inconsistent now. We're already checking > whther a tag can have content according to an arbitrary list (taken > from HTML5 standard, I suppose) - we should probably also check > whether an attribute must have content, or can be boolean (or, to > check neither - it would be cool if it was possible to disable this > validation, I sometimes use Markaby for generating XML, or RSS feeds). I agree. > There might exist valid reasons for passing `true`/`false` as > attribute value and expecting it to show up (possibly for value > attribute on select list options or radio buttons), as well as passing > a truthy value that is not `true` itself (for example, > Numeric#nonzero? returns either `false` or `self`, and one might want > to have a checkbox checked or not according to it). > > Both of the above problems can be solved by using respectively > `true_or_false.to_s` or `!!integer.nonzero?`, but both of these > solutions are kind of ugly. `!interger.zero?` is another way :-) > > I can change the code myself if you don't feel like it. :) The real question here is: Should it be a part of camping/mab.rb or the Mab-gem? I'm definitely for adding many features (indentation, attribute-validation, flow-validation), but not in Camping. The Camping implementation should just be enough to get you started. From IcePapih at lavabit.com Mon Dec 19 14:39:07 2011 From: IcePapih at lavabit.com (Isak Andersson) Date: Mon, 19 Dec 2011 20:39:07 +0100 Subject: Mab: The tiny Markaby-alternative In-Reply-To: References: Message-ID: > The real question here is: Should it be a part of camping/mab.rb or > the Mab-gem? I'm definitely for adding many features (indentation, > attribute-validation, flow-validation), but not in Camping. The > Camping implementation should just be enough to get you started I think mab should install with Camping as a dependency in that case. Otherwise users will think that they are all set, but when they start doing things that you can do with mab that they assume is possible and start getting a bunch of errors. Heads will be scratched. So you should get full functionality out of the box. From matma.rex at gmail.com Mon Dec 19 15:00:09 2011 From: matma.rex at gmail.com (=?UTF-8?Q?Bartosz_Dziewo=C5=84ski?=) Date: Mon, 19 Dec 2011 21:00:09 +0100 Subject: Mab: The tiny Markaby-alternative In-Reply-To: References: Message-ID: 2011/12/19 Magnus Holm : > The real question here is: Should it be a part of camping/mab.rb or > the Mab-gem? I'm definitely for adding many features (indentation, > attribute-validation, flow-validation), but not in Camping. The > Camping implementation should just be enough to get you started. 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. I also don't think it's a good idea to duplicate functionality - a little stub with Camping, richer library elsewhere - just make it a dependency, like Isak says. -- Matma Rex From IcePapih at lavabit.com Mon Dec 19 15:34:47 2011 From: IcePapih at lavabit.com (Isak Andersson) Date: Mon, 19 Dec 2011 21:34:47 +0100 Subject: Mab: The tiny Markaby-alternative In-Reply-To: References: Message-ID: > 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 :) -- Twitter: http://twitter.com/bitpuffin/ Blog: http://bitpuffin.tumblr.com/ Github: http://github.com/milkshakepanda/ From judofyr at gmail.com Mon Dec 19 16:26:35 2011 From: judofyr at gmail.com (Magnus Holm) Date: Mon, 19 Dec 2011 22:26:35 +0100 Subject: Mab: The tiny Markaby-alternative In-Reply-To: References: Message-ID: On Mon, Dec 19, 2011 at 21:34, Isak Andersson 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? From judofyr at gmail.com Mon Dec 19 16:41:06 2011 From: judofyr at gmail.com (Magnus Holm) Date: Mon, 19 Dec 2011 22:41:06 +0100 Subject: Camping Server: automatically serve static files from public/ Message-ID: 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 From dsusco at gmail.com Mon Dec 19 16:49:50 2011 From: dsusco at gmail.com (David Susco) Date: Mon, 19 Dec 2011 16:49:50 -0500 Subject: Mab: The tiny Markaby-alternative In-Reply-To: References: Message-ID: 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 wrote: > On Mon, Dec 19, 2011 at 21:34, Isak Andersson 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 at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list -- Dave From judofyr at gmail.com Mon Dec 19 16:50:07 2011 From: judofyr at gmail.com (Magnus Holm) Date: Mon, 19 Dec 2011 22:50:07 +0100 Subject: Plan for 2.2 Message-ID: - 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 From judofyr at gmail.com Mon Dec 19 16:56:05 2011 From: judofyr at gmail.com (Magnus Holm) Date: Mon, 19 Dec 2011 22:56:05 +0100 Subject: Dealing with extensions Message-ID: Okay, people who want to extend Camping apps, how should they write their code? Because of the many modules/classes in Camping, it can be tiresome if all developers need to re-create all the same included-hooks: module MyExt module Helpers; end def self.included(mod) mod::Helpers.send(:include, Helpers) end end What we can do: * Create some sort of string-eval-API (how ar.rb and mab.rb are implemented now) * Provide a smarter included-hook that developers can include * Provide another method which does more funky stuff (see the old http://equipment.rubyforge.org/) Other suggestions? // Magnus Holm From IcePapih at lavabit.com Mon Dec 19 17:07:54 2011 From: IcePapih at lavabit.com (Isak Andersson) Date: Mon, 19 Dec 2011 23:07:54 +0100 Subject: Plan for 2.2 In-Reply-To: References: Message-ID: > Anything else? Yeah, set :controllers, set :models and set :helpers ;) I won't give up on that -- Twitter: http://twitter.com/bitpuffin/ Blog: http://bitpuffin.tumblr.com/ Github: http://github.com/milkshakepanda/ From a at creativepony.com Mon Dec 19 17:24:27 2011 From: a at creativepony.com (Jenna Fox) Date: Tue, 20 Dec 2011 09:24:27 +1100 Subject: Mab: The tiny Markaby-alternative In-Reply-To: References: Message-ID: <90C1B903080445B6BA9C541FFEE5196D@creativepony.com> I'd like markaby to be a hard dependancy - it's the default, if it isn't installed beginners get terribly confused, and installing one more gem really isn't going to cause problems for people - computers have so much free space these days. If they really (for whatever reason) want to refuse markaby's inclusion, they can ask rubygems to bypass dependancies. ? Jenna Fox On Tuesday, 20 December 2011 at 8:26 AM, Magnus Holm wrote: > On Mon, Dec 19, 2011 at 21:34, Isak Andersson 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 at rubyforge.org (mailto:Camping-list at rubyforge.org) > http://rubyforge.org/mailman/listinfo/camping-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From a at creativepony.com Mon Dec 19 17:26:57 2011 From: a at creativepony.com (Jenna Fox) Date: Tue, 20 Dec 2011 09:26:57 +1100 Subject: Camping Server: automatically serve static files from public/ In-Reply-To: References: Message-ID: <99B78F3C01E24BB2BC1A755A73B17F91@creativepony.com> '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'? ? Jenna Fox On Tuesday, 20 December 2011 at 8:41 AM, Magnus Holm wrote: > 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 at rubyforge.org (mailto:Camping-list at rubyforge.org) > http://rubyforge.org/mailman/listinfo/camping-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From judofyr at gmail.com Mon Dec 19 17:30:12 2011 From: judofyr at gmail.com (Magnus Holm) Date: Mon, 19 Dec 2011 23:30:12 +0100 Subject: setting controllers etc In-Reply-To: <32094.95.209.48.222.1324319913.squirrel@lavabit.com> References: <32126.109.58.29.251.1324231731.squirrel@lavabit.com> <16876.109.58.120.116.1324245371.squirrel@lavabit.com> <20141.109.58.120.116.1324248611.squirrel@lavabit.com> <2B27F087ED4F479F9D2B85F60267139F@creativepony.com> <32094.95.209.48.222.1324319913.squirrel@lavabit.com> Message-ID: On Mon, Dec 19, 2011 at 19:38, 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 :-) From judofyr at gmail.com Mon Dec 19 17:37:22 2011 From: judofyr at gmail.com (Magnus Holm) Date: Mon, 19 Dec 2011 23:37:22 +0100 Subject: Camping Server: automatically serve static files from public/ In-Reply-To: <99B78F3C01E24BB2BC1A755A73B17F91@creativepony.com> References: <99B78F3C01E24BB2BC1A755A73B17F91@creativepony.com> Message-ID: On Mon, Dec 19, 2011 at 23:26, Jenna Fox 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. From a at creativepony.com Mon Dec 19 17:46:31 2011 From: a at creativepony.com (Jenna Fox) Date: Tue, 20 Dec 2011 09:46:31 +1100 Subject: Camping Server: automatically serve static files from public/ In-Reply-To: References: <99B78F3C01E24BB2BC1A755A73B17F91@creativepony.com> Message-ID: 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 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 at rubyforge.org (mailto:Camping-list at rubyforge.org) > http://rubyforge.org/mailman/listinfo/camping-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From deveritt at innotts.co.uk Mon Dec 19 17:52:20 2011 From: deveritt at innotts.co.uk (Dave Everitt) Date: Mon, 19 Dec 2011 22:52:20 +0000 Subject: Mab: The tiny Markaby-alternative In-Reply-To: References: Message-ID: <87487930-9EA8-49B5-80C5-742123A945F2@innotts.co.uk> > switch to a hard dependency on Markaby, or should we continue what > we're doing today? no hard dependency, continue as today - DaveE From a at creativepony.com Mon Dec 19 17:53:59 2011 From: a at creativepony.com (Jenna Fox) Date: Tue, 20 Dec 2011 09:53:59 +1100 Subject: Mab: The tiny Markaby-alternative In-Reply-To: <87487930-9EA8-49B5-80C5-742123A945F2@innotts.co.uk> References: <87487930-9EA8-49B5-80C5-742123A945F2@innotts.co.uk> Message-ID: 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 at rubyforge.org (mailto:Camping-list at rubyforge.org) > http://rubyforge.org/mailman/listinfo/camping-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From deveritt at innotts.co.uk Mon Dec 19 18:09:19 2011 From: deveritt at innotts.co.uk (Dave Everitt) Date: Mon, 19 Dec 2011 23:09:19 +0000 Subject: Markaby license issue In-Reply-To: References: Message-ID: <3CD7C575-DDD2-4DF1-A921-7E2E60AFF860@innotts.co.uk> > 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 From ruby at monnet-usa.com Mon Dec 19 18:24:51 2011 From: ruby at monnet-usa.com (Philippe Monnet) Date: Mon, 19 Dec 2011 16:24:51 -0700 Subject: Camping Server: automatically serve static files from public/ In-Reply-To: References: <99B78F3C01E24BB2BC1A755A73B17F91@creativepony.com> Message-ID: <4EEFC7C3.7020705@monnet-usa.com> 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 > > 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 at rubyforge.org >> http://rubyforge.org/mailman/listinfo/camping-list > > > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From a at creativepony.com Mon Dec 19 18:41:38 2011 From: a at creativepony.com (Jenna Fox) Date: Tue, 20 Dec 2011 10:41:38 +1100 Subject: Markaby license issue In-Reply-To: <3CD7C575-DDD2-4DF1-A921-7E2E60AFF860@innotts.co.uk> References: <3CD7C575-DDD2-4DF1-A921-7E2E60AFF860@innotts.co.uk> Message-ID: <951BDB76264D4BA2A132BB64D7ADB364@creativepony.com> 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 at rubyforge.org (mailto:Camping-list at rubyforge.org) > http://rubyforge.org/mailman/listinfo/camping-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at steveklabnik.com Mon Dec 19 20:48:18 2011 From: steve at steveklabnik.com (Steve Klabnik) Date: Mon, 19 Dec 2011 20:48:18 -0500 Subject: Markaby license issue In-Reply-To: <3CD7C575-DDD2-4DF1-A921-7E2E60AFF860@innotts.co.uk> References: <3CD7C575-DDD2-4DF1-A921-7E2E60AFF860@innotts.co.uk> Message-ID: http://en.wikipedia.org/wiki/HTML5#XHTML5 http://www.whatwg.org/specs/web-apps/current-work/multipage/the-xhtml-syntax.html#writing-xhtml-documents being the specific line in the spec From dsusco at gmail.com Mon Dec 19 21:11:43 2011 From: dsusco at gmail.com (David Susco) Date: Mon, 19 Dec 2011 21:11:43 -0500 Subject: Camping Server: automatically serve static files from public/ In-Reply-To: <4EEFC7C3.7020705@monnet-usa.com> References: <99B78F3C01E24BB2BC1A755A73B17F91@creativepony.com> <4EEFC7C3.7020705@monnet-usa.com> Message-ID: #1 gets my vote. Dave On Mon, Dec 19, 2011 at 6:24 PM, Philippe Monnet wrote: > 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 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 at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list > > > > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list > > > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list -- Dave From dsusco at gmail.com Mon Dec 19 21:15:00 2011 From: dsusco at gmail.com (David Susco) Date: Mon, 19 Dec 2011 21:15:00 -0500 Subject: Mab: The tiny Markaby-alternative In-Reply-To: References: <87487930-9EA8-49B5-80C5-742123A945F2@innotts.co.uk> Message-ID: 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 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 at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list > > > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list -- Dave From a at creativepony.com Mon Dec 19 22:17:48 2011 From: a at creativepony.com (Jenna Fox) Date: Tue, 20 Dec 2011 14:17:48 +1100 Subject: Markaby license issue In-Reply-To: References: <3CD7C575-DDD2-4DF1-A921-7E2E60AFF860@innotts.co.uk> Message-ID: <6AFAA499B6D4480EBEF7630F740B685B@creativepony.com> Oh I didn't realise they had a formal 'use it with xml mime-type' sort of arrangement as well as the polyglot markup. Thanks for schooling me, Steve! :) ? Jenna Fox On Tuesday, 20 December 2011 at 12:48 PM, Steve Klabnik wrote: > http://en.wikipedia.org/wiki/HTML5#XHTML5 > > http://www.whatwg.org/specs/web-apps/current-work/multipage/the-xhtml-syntax.html#writing-xhtml-documents > being the specific line in the spec > _______________________________________________ > 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: From a at creativepony.com Mon Dec 19 22:18:14 2011 From: a at creativepony.com (Jenna Fox) Date: Tue, 20 Dec 2011 14:18:14 +1100 Subject: Mab: The tiny Markaby-alternative In-Reply-To: References: <87487930-9EA8-49B5-80C5-742123A945F2@innotts.co.uk> Message-ID: 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 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 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 > > > > > > > -- > Dave > _______________________________________________ > 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: From steve at steveklabnik.com Mon Dec 19 23:37:58 2011 From: steve at steveklabnik.com (Steve Klabnik) Date: Mon, 19 Dec 2011 23:37:58 -0500 Subject: Markaby license issue In-Reply-To: <6AFAA499B6D4480EBEF7630F740B685B@creativepony.com> References: <3CD7C575-DDD2-4DF1-A921-7E2E60AFF860@innotts.co.uk> <6AFAA499B6D4480EBEF7630F740B685B@creativepony.com> Message-ID: 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

this is insane stuff! But still... I actually like XML. There are some of us in Ruby... From a at creativepony.com Tue Dec 20 00:56:02 2011 From: a at creativepony.com (Jenna Fox) Date: Tue, 20 Dec 2011 16:56:02 +1100 Subject: Markaby license issue In-Reply-To: References: <3CD7C575-DDD2-4DF1-A921-7E2E60AFF860@innotts.co.uk> <6AFAA499B6D4480EBEF7630F740B685B@creativepony.com> Message-ID: <3738446573510511849@unknownmsgid> 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 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 > >

> this is insane > > stuff! But still... > > I actually like XML. There are some of us in Ruby... > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list From judofyr at gmail.com Tue Dec 20 03:36:10 2011 From: judofyr at gmail.com (Magnus Holm) Date: Tue, 20 Dec 2011 09:36:10 +0100 Subject: Mab: The tiny Markaby-alternative In-Reply-To: References: Message-ID: 2011/12/19 Bartosz Dziewo?ski : > 2011/12/19 Magnus Holm : >> The real question here is: Should it be a part of camping/mab.rb or >> the Mab-gem? I'm definitely for adding many features (indentation, >> attribute-validation, flow-validation), but not in Camping. The >> Camping implementation should just be enough to get you started. > > 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. I'm really not sure about keeping the name though. It feels kinda weird to just remove everything and start from scratch. > I also don't think it's a good idea to duplicate functionality - a > little stub with Camping, richer library elsewhere - just make it a > dependency, like Isak says. Okay, no stubs. Either hard or soft dependency. From judofyr at gmail.com Tue Dec 20 03:38:44 2011 From: judofyr at gmail.com (Magnus Holm) Date: Tue, 20 Dec 2011 09:38:44 +0100 Subject: Mab: The tiny Markaby-alternative In-Reply-To: <90C1B903080445B6BA9C541FFEE5196D@creativepony.com> References: <90C1B903080445B6BA9C541FFEE5196D@creativepony.com> Message-ID: On Mon, Dec 19, 2011 at 23:24, Jenna Fox wrote: > I'd like markaby to be a hard dependancy - it's the default, if it isn't > installed beginners get terribly confused, and installing one more gem > really isn't going to cause problems for people - computers have so much > free space these days. If they really (for whatever reason) want to refuse > markaby's inclusion, they can ask rubygems to bypass dependancies. ActiveRecord and SQLite is way more intrusive than Markaby/Mab, so I guess one little dep isn't that bad. Beside, it would only be loaded when you actually try to use it, so you can still use Camping without loading Markaby/Mab. From a at creativepony.com Tue Dec 20 04:00:05 2011 From: a at creativepony.com (Jenna Fox) Date: Tue, 20 Dec 2011 20:00:05 +1100 Subject: Mab: The tiny Markaby-alternative In-Reply-To: References: Message-ID: <495D281A9429429F89380F055D01646F@creativepony.com> Do we want a brand new markaby-like thing to be the grand evolution of Why and Tim's initial creation, or do we want to stand out and say "Hey world, we've made something like Markaby, but heaps better", in the way the Nokogiri clan have. I've changed my mind. I think it should have a new name. Why?s legacy serves only as a distraction, lets move on. I suggest for your consideration: Pagely ? Jenna Fox On Tuesday, 20 December 2011 at 7:36 PM, Magnus Holm wrote: > 2011/12/19 Bartosz Dziewo?ski : > > 2011/12/19 Magnus Holm : > > > The real question here is: Should it be a part of camping/mab.rb or > > > the Mab-gem? I'm definitely for adding many features (indentation, > > > attribute-validation, flow-validation), but not in Camping. The > > > Camping implementation should just be enough to get you started. > > > > > > > > > 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. > > > > > I'm really not sure about keeping the name though. It feels kinda > weird to just remove everything and start from scratch. > > > I also don't think it's a good idea to duplicate functionality - a > > little stub with Camping, richer library elsewhere - just make it a > > dependency, like Isak says. > > > > > Okay, no stubs. Either hard or soft dependency. > _______________________________________________ > 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: From a at creativepony.com Tue Dec 20 04:20:57 2011 From: a at creativepony.com (Jenna Fox) Date: Tue, 20 Dec 2011 20:20:57 +1100 Subject: Mab: The tiny Markaby-alternative In-Reply-To: References: <90C1B903080445B6BA9C541FFEE5196D@creativepony.com> Message-ID: <8AC719D9743B4F378676B3677C5271AF@creativepony.com> Oh yeah, totes BYOORM ? Jenna Fox On Tuesday, 20 December 2011 at 7:38 PM, Magnus Holm wrote: > On Mon, Dec 19, 2011 at 23:24, Jenna Fox wrote: > > I'd like markaby to be a hard dependancy - it's the default, if it isn't > > installed beginners get terribly confused, and installing one more gem > > really isn't going to cause problems for people - computers have so much > > free space these days. If they really (for whatever reason) want to refuse > > markaby's inclusion, they can ask rubygems to bypass dependancies. > > > > > ActiveRecord and SQLite is way more intrusive than Markaby/Mab, so I > guess one little dep isn't that bad. Beside, it would only be loaded > when you actually try to use it, so you can still use Camping without > loading Markaby/Mab. > _______________________________________________ > 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: From danbryan at gmail.com Tue Dec 20 04:29:53 2011 From: danbryan at gmail.com (Daniel Bryan) Date: Tue, 20 Dec 2011 20:29:53 +1100 Subject: Mab: The tiny Markaby-alternative In-Reply-To: References: <90C1B903080445B6BA9C541FFEE5196D@creativepony.com> Message-ID: I think it's just as likely that people would want to use a data modelling alternative to ActiveRecord as it is that they'd want to use a templating language of their choice, so you're already kinda past the point of keeping out dependencies. Speaking as someone who tried Camping after very little other web development & programming experience (and learned a lot because of it), the lack of Markaby in the default gem install seriously held me back several times. On Dec 20, 2011 8:08 PM, "Magnus Holm" wrote: > On Mon, Dec 19, 2011 at 23:24, Jenna Fox wrote: > > I'd like markaby to be a hard dependancy - it's the default, if it isn't > > installed beginners get terribly confused, and installing one more gem > > really isn't going to cause problems for people - computers have so much > > free space these days. If they really (for whatever reason) want to > refuse > > markaby's inclusion, they can ask rubygems to bypass dependancies. > > ActiveRecord and SQLite is way more intrusive than Markaby/Mab, so I > guess one little dep isn't that bad. Beside, it would only be loaded > when you actually try to use it, so you can still use Camping without > loading Markaby/Mab. > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From IcePapih at lavabit.com Tue Dec 20 05:04:02 2011 From: IcePapih at lavabit.com (Isak Andersson) Date: Tue, 20 Dec 2011 11:04:02 +0100 Subject: setting controllers etc In-Reply-To: References: <32126.109.58.29.251.1324231731.squirrel@lavabit.com> <16876.109.58.120.116.1324245371.squirrel@lavabit.com> <20141.109.58.120.116.1324248611.squirrel@lavabit.com> <2B27F087ED4F479F9D2B85F60267139F@creativepony.com> <32094.95.209.48.222.1324319913.squirrel@lavabit.com> Message-ID: > 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/ From IcePapih at lavabit.com Tue Dec 20 05:06:09 2011 From: IcePapih at lavabit.com (Isak Andersson) Date: Tue, 20 Dec 2011 11:06:09 +0100 Subject: Camping Server: automatically serve static files from public/ In-Reply-To: References: Message-ID: I think Alternative 2 makes the most sense. Then you can have multiple apps that don't share the public folder. Plus, you put almost everything in the app folder anyways so there shouldn't be a difference now either. > Alternative 2: > > app.rb > app/public > app/public/style.css # example -- Twitter: http://twitter.com/bitpuffin/ Blog: http://bitpuffin.tumblr.com/ Github: http://github.com/milkshakepanda/ From a at creativepony.com Tue Dec 20 05:12:09 2011 From: a at creativepony.com (Jenna Fox) Date: Tue, 20 Dec 2011 21:12:09 +1100 Subject: Mab: The tiny Markaby-alternative In-Reply-To: References: <90C1B903080445B6BA9C541FFEE5196D@creativepony.com> Message-ID: <0D49999ACE954841AC04FBCF1AE2DCC1@creativepony.com> The trouble is that a markaby-type thing is just a short ruby script - maybe two or three files, but really not much of anything. ActiveRecord is a complicated set of software for interacting with many different kinds of databases, some not even SQL based, which includes or depends on native code. Native code means installation requires a compiler - suddenly complicating things for beginners on non-linux platforms where compilers don't come preinstalled - worse still for users with poor internet connections, where downloading developer tools could be very costly and inconvenient. So that's really the balance which justifies keeping active record as an optional dependancy (and besides, it isn't even really that excellent anyway). It's dependancy effectively includes hundreds of megabytes or even gigabytes of developer tools. ? Jenna Fox On Tuesday, 20 December 2011 at 8:29 PM, Daniel Bryan wrote: > I think it's just as likely that people would want to use a data modelling alternative to ActiveRecord as it is that they'd want to use a templating language of their choice, so you're already kinda past the point of keeping out dependencies. Speaking as someone who tried Camping after very little other web development & programming experience (and learned a lot because of it), the lack of Markaby in the default gem install seriously held me back several times. > On Dec 20, 2011 8:08 PM, "Magnus Holm" wrote: > > On Mon, Dec 19, 2011 at 23:24, Jenna Fox wrote: > > > I'd like markaby to be a hard dependancy - it's the default, if it isn't > > > installed beginners get terribly confused, and installing one more gem > > > really isn't going to cause problems for people - computers have so much > > > free space these days. If they really (for whatever reason) want to refuse > > > markaby's inclusion, they can ask rubygems to bypass dependancies. > > > > ActiveRecord and SQLite is way more intrusive than Markaby/Mab, so I > > guess one little dep isn't that bad. Beside, it would only be loaded > > when you actually try to use it, so you can still use Camping without > > loading Markaby/Mab. > > _______________________________________________ > > 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: From IcePapih at lavabit.com Tue Dec 20 05:14:46 2011 From: IcePapih at lavabit.com (Isak Andersson) Date: Tue, 20 Dec 2011 11:14:46 +0100 Subject: Camping Server: automatically serve static files from public/ In-Reply-To: <4EEFC7C3.7020705@monnet-usa.com> References: <99B78F3C01E24BB2BC1A755A73B17F91@creativepony.com> <4EEFC7C3.7020705@monnet-usa.com> Message-ID: Den 2011-12-20 00:24:51 skrev Philippe Monnet : > Plus people familiar with - or switching from ;-) - Rails and other > frameworks would also feel at home. And switching from Camping to others :) But why would you want to! -- Twitter: http://twitter.com/bitpuffin/ Blog: http://bitpuffin.tumblr.com/ Github: http://github.com/milkshakepanda/ From paul at luon.net Tue Dec 20 05:19:40 2011 From: paul at luon.net (Paul van Tilburg) Date: Tue, 20 Dec 2011 11:19:40 +0100 Subject: Camping Server: automatically serve static files from public/ In-Reply-To: References: Message-ID: <20111220101940.GB3265@density.luon.net> On Tue, Dec 20, 2011 at 11:06:09AM +0100, Isak Andersson wrote: > I think Alternative 2 makes the most sense. Then you can have multiple apps > that don't share the public folder. Plus, you put almost everything in the > app folder anyways so there shouldn't be a difference now either. > > >Alternative 2: > > > > app.rb > > app/public > > app/public/style.css # example I disagree. In most cases there is only one app (at least for most of my apps). So I have an app.rb with stuff under public/. If there are more apps, there is no way of knowing whether they are designed to work together and share the same public data, or they are apps with seperate(d) public data. Since one has to build the URLs in the app anyway, why not let the developer decide the layout of public/ to suit a shared or seperated layout? (One can think of shared stylesheets, but different sets of icons/PDFs/whathaveyou). Kind regards, Paul -- Web: http://paul.luon.net/home/ | Email: paul at luon.net Jabber/GTalk: paul at luon.net | GnuPG key ID: 0x50064181 From IcePapih at lavabit.com Tue Dec 20 06:00:31 2011 From: IcePapih at lavabit.com (Isak Andersson) Date: Tue, 20 Dec 2011 12:00:31 +0100 Subject: Camping Server: automatically serve static files from public/ In-Reply-To: <20111220101940.GB3265@density.luon.net> References: <20111220101940.GB3265@density.luon.net> Message-ID: Den 2011-12-20 11:19:40 skrev Paul van Tilburg : > On Tue, Dec 20, 2011 at 11:06:09AM +0100, Isak Andersson wrote: >> I think Alternative 2 makes the most sense. Then you can have multiple >> apps >> that don't share the public folder. Plus, you put almost everything in >> the >> app folder anyways so there shouldn't be a difference now either. >> >> >Alternative 2: >> > >> > app.rb >> > app/public >> > app/public/style.css # example > > I disagree. In most cases there is only one app (at least for most of > my apps). So I have an app.rb with stuff under public/. > > If there are more apps, there is no way of knowing whether they are > designed to work together and share the same public data, or they are > apps with seperate(d) public data. Since one has to build the URLs in > the app anyway, why not let the developer decide the layout of public/ > to suit a shared or seperated layout? (One can think of shared > stylesheets, but different sets of icons/PDFs/whathaveyou). > > Kind regards, > Paul > Allright, how about making the users set it up themselves? That way they could put it anywhere they want. Just do things in the module App module. Like set :public, File.dirname(__FILE__) + '/epic/find/the/public' will set that to be the public folder. Simple enough? Cheers, Isak -- Twitter: http://twitter.com/bitpuffin/ Blog: http://bitpuffin.tumblr.com/ Github: http://github.com/milkshakepanda/ From a at creativepony.com Tue Dec 20 06:05:22 2011 From: a at creativepony.com (Jenna Fox) Date: Tue, 20 Dec 2011 22:05:22 +1100 Subject: Camping Server: automatically serve static files from public/ In-Reply-To: <20111220101940.GB3265@density.luon.net> References: <20111220101940.GB3265@density.luon.net> Message-ID: <169C54258EC24B449989120DE811E960@creativepony.com> I vote number 2 - it keeps apps separated, so you can pop a whole bunch in a folder and call it a day - Having one big shared public folder is messy and breaks that model of separation entirely. If people like Isak have existing arrangements in place, there aught to be some configurable option to specify any arbitrary folder as the public files. ? Jenna Fox On Tuesday, 20 December 2011 at 9:19 PM, Paul van Tilburg wrote: > On Tue, Dec 20, 2011 at 11:06:09AM +0100, Isak Andersson wrote: > > I think Alternative 2 makes the most sense. Then you can have multiple apps > > that don't share the public folder. Plus, you put almost everything in the > > app folder anyways so there shouldn't be a difference now either. > > > > > Alternative 2: > > > > > > app.rb > > > app/public > > > app/public/style.css # example > > > > > > > > > > I disagree. In most cases there is only one app (at least for most of > my apps). So I have an app.rb with stuff under public/. > > If there are more apps, there is no way of knowing whether they are > designed to work together and share the same public data, or they are > apps with seperate(d) public data. Since one has to build the URLs in > the app anyway, why not let the developer decide the layout of public/ > to suit a shared or seperated layout? (One can think of shared > stylesheets, but different sets of icons/PDFs/whathaveyou). > > Kind regards, > Paul > > -- > Web: http://paul.luon.net/home/ | Email: paul at luon.net (mailto:paul at luon.net) > Jabber/GTalk: paul at luon.net (mailto:paul at luon.net) | GnuPG key ID: 0x50064181 > _______________________________________________ > 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: From judofyr at gmail.com Tue Dec 20 06:14:30 2011 From: judofyr at gmail.com (Magnus Holm) Date: Tue, 20 Dec 2011 12:14:30 +0100 Subject: Remove "camping app.rb app2.rb" support? Message-ID: I think the ability to load multiple Camping apps at once makes things a lot more difficult (e.g. how to deal with static files). Does anyone actually use this feature? // Magnus Holm From judofyr at gmail.com Tue Dec 20 07:17:40 2011 From: judofyr at gmail.com (Magnus Holm) Date: Tue, 20 Dec 2011 13:17:40 +0100 Subject: Topic branch-rules in camping/camping Message-ID: Okay, some new rules for topic branches in camping/camping: - You are free to create topic branches, however: - Anyone are free to commit to them. - After they have been merged/abandoned anyone are free to delete them. If you want to have full ownership and control over your topic branches, please fork and commit there. // Magnus Holm From dsusco at gmail.com Tue Dec 20 08:07:55 2011 From: dsusco at gmail.com (David Susco) Date: Tue, 20 Dec 2011 08:07:55 -0500 Subject: Camping Server: automatically serve static files from public/ In-Reply-To: <169C54258EC24B449989120DE811E960@creativepony.com> References: <20111220101940.GB3265@density.luon.net> <169C54258EC24B449989120DE811E960@creativepony.com> Message-ID: Not sure what other people are doing but I already have my apps in separate folders. Each app has: app/ app/app.rb app/app/ app/config/ app/public/ app/lib/ app/db/ app/log/ When I launch a new one I just add it to the apache conf and restart. Dave On Tue, Dec 20, 2011 at 6:05 AM, Jenna Fox wrote: > I vote number 2 - it keeps apps separated, so you can pop a whole bunch in a > folder and call it a day - Having one big shared public folder is messy and > breaks that model of separation entirely. If people like Isak have existing > arrangements in place, there aught to be some configurable option to specify > any arbitrary folder as the public files. > > > ? > Jenna Fox > > On Tuesday, 20 December 2011 at 9:19 PM, Paul van Tilburg wrote: > > On Tue, Dec 20, 2011 at 11:06:09AM +0100, Isak Andersson wrote: > > I think Alternative 2 makes the most sense. Then you can have multiple apps > that don't share the public folder. Plus, you put almost everything in the > app folder anyways so there shouldn't be a difference now either. > > Alternative 2: > > app.rb > app/public > app/public/style.css # example > > > I disagree. In most cases there is only one app (at least for most of > my apps). So I have an app.rb with stuff under public/. > > If there are more apps, there is no way of knowing whether they are > designed to work together and share the same public data, or they are > apps with seperate(d) public data. Since one has to build the URLs in > the app anyway, why not let the developer decide the layout of public/ > to suit a shared or seperated layout? (One can think of shared > stylesheets, but different sets of icons/PDFs/whathaveyou). > > Kind regards, > Paul > > -- > Web: http://paul.luon.net/home/ | Email: paul at luon.net > Jabber/GTalk: paul at luon.net | GnuPG key ID: 0x50064181 > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list > > > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list -- Dave From dsusco at gmail.com Tue Dec 20 08:09:02 2011 From: dsusco at gmail.com (David Susco) Date: Tue, 20 Dec 2011 08:09:02 -0500 Subject: Remove "camping app.rb app2.rb" support? In-Reply-To: References: Message-ID: I've never found myself working on multiple apps at once in a dev environment. Dave On Tue, Dec 20, 2011 at 6:14 AM, Magnus Holm wrote: > I think the ability to load multiple Camping apps at once makes things > a lot more difficult (e.g. how to deal with static files). > > Does anyone actually use this feature? > > // Magnus Holm > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list -- Dave From IcePapih at lavabit.com Tue Dec 20 09:14:15 2011 From: IcePapih at lavabit.com (Isak Andersson) Date: Tue, 20 Dec 2011 15:14:15 +0100 Subject: Remove "camping app.rb app2.rb" support? In-Reply-To: References: Message-ID: Den 2011-12-20 14:09:02 skrev David Susco : > I've never found myself working on multiple apps at once in a dev > environment. > > Dave I haven't either, but I can definitely see myself using it sometime. -- Twitter: http://twitter.com/bitpuffin/ Blog: http://bitpuffin.tumblr.com/ Github: http://github.com/milkshakepanda/ From judofyr at gmail.com Tue Dec 20 09:41:21 2011 From: judofyr at gmail.com (Magnus Holm) Date: Tue, 20 Dec 2011 15:41:21 +0100 Subject: Remove "camping app.rb app2.rb" support? In-Reply-To: References: Message-ID: On Tue, Dec 20, 2011 at 15:14, Isak Andersson wrote: > Den 2011-12-20 14:09:02 skrev David Susco : > > >> I've never found myself working on multiple apps at once in a dev >> environment. >> >> Dave > > > I haven't either, but I can definitely see myself using it sometime. The new Camping Server will be able to run rackup-files. Would it be good enough if you had to do this? # in both.ru require 'app' require 'app2' map '/app' do run App end map '/app2' do run App2 end $ camping both.ru From dsusco at gmail.com Tue Dec 20 10:36:11 2011 From: dsusco at gmail.com (David Susco) Date: Tue, 20 Dec 2011 10:36:11 -0500 Subject: Remove "camping app.rb app2.rb" support? In-Reply-To: References: Message-ID: Magnus, would that still support the dynamic reloading of the app file that the camping server does now? Dave On Tue, Dec 20, 2011 at 9:41 AM, Magnus Holm wrote: > On Tue, Dec 20, 2011 at 15:14, Isak Andersson wrote: >> Den 2011-12-20 14:09:02 skrev David Susco : >> >> >>> I've never found myself working on multiple apps at once in a dev >>> environment. >>> >>> Dave >> >> >> I haven't either, but I can definitely see myself using it sometime. > > The new Camping Server will be able to run rackup-files. Would it be > good enough if you had to do this? > > ?# in both.ru > ?require 'app' > ?require 'app2' > ?map '/app' do run App end > ?map '/app2' do run App2 end > > $ camping both.ru > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list -- Dave From judofyr at gmail.com Tue Dec 20 11:22:24 2011 From: judofyr at gmail.com (Magnus Holm) Date: Tue, 20 Dec 2011 17:22:24 +0100 Subject: Remove "camping app.rb app2.rb" support? In-Reply-To: References: Message-ID: On Tue, Dec 20, 2011 at 16:36, David Susco wrote: > Magnus, would that still support the dynamic reloading of the app file > that the camping server does now? > > Dave Yes. It will watch both apps. From ruby at monnet-usa.com Tue Dec 20 11:58:00 2011 From: ruby at monnet-usa.com (Philippe Monnet) Date: Tue, 20 Dec 2011 09:58:00 -0700 Subject: Remove "camping app.rb app2.rb" support? In-Reply-To: References: Message-ID: <4EF0BE98.6010703@monnet-usa.com> I have never used that feature either. And for my apps I prefer to keep things compartimentalized / isolated anyway. On 12/20/2011 6:09 AM, David Susco wrote: > I've never found myself working on multiple apps at once in a dev environment. > > Dave > > On Tue, Dec 20, 2011 at 6:14 AM, Magnus Holm wrote: >> I think the ability to load multiple Camping apps at once makes things >> a lot more difficult (e.g. how to deal with static files). >> >> Does anyone actually use this feature? >> >> // Magnus Holm >> _______________________________________________ >> Camping-list mailing list >> Camping-list at rubyforge.org >> http://rubyforge.org/mailman/listinfo/camping-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From judofyr at gmail.com Tue Dec 20 13:33:29 2011 From: judofyr at gmail.com (Magnus Holm) Date: Tue, 20 Dec 2011 19:33:29 +0100 Subject: Remove "camping app.rb app2.rb" support? In-Reply-To: References: Message-ID: On Tue, Dec 20, 2011 at 12:14, Magnus Holm wrote: > I think the ability to load multiple Camping apps at once makes things > a lot more difficult (e.g. how to deal with static files). > > Does anyone actually use this feature? > > // Magnus Holm Just realized that we have a slight problem: How to deal with `camping app.rb` where app.rb is: Camping.goes :App Camping.goes :OtherThing Possible solutions: - Always choose the first/last app - Choose one that matches the filename - Show an error You should always be able to create a "config.ru" which explicitly tells Camping/Rack how to run the app: # config.ru require 'app' run OtherThing Therefore it feels best to choose one that matches the filename, and show an error otherwise if there's no such app. This means that it works as expected for people who name their apps/files correctly, and it shows that something in wrong for those who don't. Of course, if there's just one app that was loaded, we can always use that one. We only need to be picky in multi-app cases. Thoughts? From judofyr at gmail.com Tue Dec 20 13:47:12 2011 From: judofyr at gmail.com (Magnus Holm) Date: Tue, 20 Dec 2011 19:47:12 +0100 Subject: Camping Server: automatically serve static files from public/ In-Reply-To: <20111220101940.GB3265@density.luon.net> References: <20111220101940.GB3265@density.luon.net> Message-ID: On Tue, Dec 20, 2011 at 11:19, Paul van Tilburg wrote: > On Tue, Dec 20, 2011 at 11:06:09AM +0100, Isak Andersson wrote: >> I think Alternative 2 makes the most sense. Then you can have multiple apps >> that don't share the public folder. Plus, you put almost everything in the >> app folder anyways so there shouldn't be a difference now either. >> >> >Alternative 2: >> > >> > ?app.rb >> > ?app/public >> > ?app/public/style.css # example > > I disagree. ?In most cases there is only one app (at least for most of > my apps). ?So I have an app.rb with stuff under public/. > > If there are more apps, there is no way of knowing whether they are > designed to work together and share the same public data, or they are > apps with seperate(d) public data. ?Since one has to build the URLs in > the app anyway, why not let the developer decide the layout of public/ > to suit a shared or seperated layout? ?(One can think of shared > stylesheets, but different sets of icons/PDFs/whathaveyou). > I think this makes most sense too. If you have this config.ru: require 'app' require 'app2' map '/app' do run App end map '/app2' do run App2 It's much easier get a consistent setup in production and development with a single shared public directory. With separate directories you now need to configure your web server to: 1. Serve static files at app/public as /app/ 2. Serve static files at app2/public as /app/2 3. Serve everything else to Thin/Mongrel/WEBrick -- Well, running multiple-apps in one process is kinda broken anyway, because Camping overrides Markaby to prepend the root to all src-, href- and action-attributes: link rel: 'stylesheet', href: '/style.css' If you have mounted that app at /app, then it will actually generate . So you're pretty much stuck within your app anyway? From gravious at jollyrotten.org Wed Dec 28 20:14:18 2011 From: gravious at jollyrotten.org (Anthony Durity) Date: Thu, 29 Dec 2011 02:14:18 +0100 Subject: Markaby license issue In-Reply-To: <3738446573510511849@unknownmsgid> References: <3CD7C575-DDD2-4DF1-A921-7E2E60AFF860@innotts.co.uk> <6AFAA499B6D4480EBEF7630F740B685B@creativepony.com> <3738446573510511849@unknownmsgid> Message-ID: I think people should write HTML in HTML, CSS in CSS, Javascript in Javascript, and Ruby in Ruby. I don't get the fascination with DSLs for existing domains. DSLs for your own stuff is okay, where you need something that is more complex than a bunch of functions and less complex than a full blown language. But DSLs for existing domains. Just write it in the target language already. If you want to integrate with other stuff you can. If you want to switch platforms you can and you don't have to throw awaw or rewrite a ton of stuff. On Tue, Dec 20, 2011 at 6:56 AM, Jenna Fox wrote: > 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 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 > > > >

> > this is insane > > > > stuff! But still... > > > > I actually like XML. There are some of us in Ruby... > > _______________________________________________ > > Camping-list mailing list > > Camping-list at rubyforge.org > > http://rubyforge.org/mailman/listinfo/camping-list > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From IcePapih at lavabit.com Wed Dec 28 20:20:40 2011 From: IcePapih at lavabit.com (Isak Andersson) Date: Thu, 29 Dec 2011 02:20:40 +0100 Subject: Markaby license issue In-Reply-To: References: <3CD7C575-DDD2-4DF1-A921-7E2E60AFF860@innotts.co.uk> <6AFAA499B6D4480EBEF7630F740B685B@creativepony.com> <3738446573510511849@unknownmsgid> Message-ID: I think people who want to write HTML in HTML should write HTML in HTML. I think people who don't want to write HTML in HTML should write it in something they prefer. Just my humble opinion. --Isak Andersson Den 2011-12-29 02:14:18 skrev Anthony Durity : > I think people should write HTML in HTML, CSS in CSS, Javascript in > Javascript, and Ruby in Ruby. > > I don't get the fascination with DSLs for existing domains. DSLs for your > own stuff is okay, where you need something that is more complex than a > bunch of functions and less complex than a full blown language. But DSLs > for existing domains. Just write it in the target language already. If > you > want to integrate with other stuff you can. If you want to switch > platforms > you can and you don't have to throw awaw or rewrite a ton of stuff. > > On Tue, Dec 20, 2011 at 6:56 AM, Jenna Fox wrote: > >> 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 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 >> > >> >

>> > this is insane >> > >> > stuff! But still... >> > >> > I actually like XML. There are some of us in Ruby... >> > _______________________________________________ >> > Camping-list mailing list >> > Camping-list at rubyforge.org >> > http://rubyforge.org/mailman/listinfo/camping-list >> _______________________________________________ >> Camping-list mailing list >> Camping-list at rubyforge.org >> http://rubyforge.org/mailman/listinfo/camping-list >> > > > ____________________________________________________________________________________ > Get The Best Grades With the Least Amount of Time &Effort ! > http://click.lavabit.com/cizxa3hjywnx7odc65c5xxytqdzu49pqyanart1e93c9f68gmb4y/ > ____________________________________________________________________________________ -- Twitter: http://twitter.com/bitpuffin/ Blog: http://bitpuffin.tumblr.com/ Github: http://github.com/milkshakepanda/ From _ at whats-your.name Wed Dec 28 23:38:27 2011 From: _ at whats-your.name (carmen) Date: Thu, 29 Dec 2011 04:38:27 +0000 Subject: Markaby license issue In-Reply-To: References: Message-ID: <20111229043827.GA1360@s.clearwire-wmx.net> > I think people who don't want to write HTML in HTML should write it in something they prefer. i like to write HTML in Ruby, {attr: :val} for elements, [] for lists of elements, and "" for..strings def H _ case _ when Hash then '<'+(_[:_]||:div).to_s+(_.keys-[:_,:c]).map{|a| ' '+a.to_s+'='+"'"+ _[a].to_s.hsub({"'"=>'%27', '>'=>'%3E', '<'=>'%3C'})+"'"}.join+'>'+ (_[:c] ? (H _[:c]) : '')+ '' when Array then _.map{|n|H n}.join else _.to_s end end irb(main):010:0> H [{style: "display:block", c: {_: :h1, c: "TESTING"}},(0..3).map{|i|"#{i}.."}] => "

0..1..2..3.." From deveritt at innotts.co.uk Fri Dec 30 09:01:22 2011 From: deveritt at innotts.co.uk (Dave Everitt) Date: Fri, 30 Dec 2011 14:01:22 +0000 Subject: Markaby license issue In-Reply-To: References: <3CD7C575-DDD2-4DF1-A921-7E2E60AFF860@innotts.co.uk> <6AFAA499B6D4480EBEF7630F740B685B@creativepony.com> <3738446573510511849@unknownmsgid> Message-ID: <661A2333-76D6-4B1C-8E16-572D78ABC633@innotts.co.uk> I don't think there are any 'shoulds', but people writing code (including markup) which other people might one day need to understand would be wise to make it comprehensible, and probably therefore in a recognisable, readable syntax... which I think is the essence of Markaby and its legacy :-) DaveE > I think people who want to write HTML in HTML should write HTML in > HTML. > > I think people who don't want to write HTML in HTML should write it > in something they prefer. > > Just my humble opinion. > > --Isak Andersson > > Den 2011-12-29 02:14:18 skrev Anthony Durity > : > >> I think people should write HTML in HTML, CSS in CSS, Javascript in >> Javascript, and Ruby in Ruby. >> >> I don't get the fascination with DSLs for existing domains. DSLs >> for your >> own stuff is okay, where you need something that is more complex >> than a >> bunch of functions and less complex than a full blown language. But >> DSLs >> for existing domains. Just write it in the target language already. >> If you >> want to integrate with other stuff you can. If you want to switch >> platforms >> you can and you don't have to throw awaw or rewrite a ton of stuff. >> >> On Tue, Dec 20, 2011 at 6:56 AM, Jenna Fox >> wrote: >> >>> 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 >>> 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 >>> > >>> >

>>> > this is insane >>> > >>> > stuff! But still... >>> > >>> > I actually like XML. There are some of us in Ruby... From deveritt at innotts.co.uk Fri Dec 30 09:07:26 2011 From: deveritt at innotts.co.uk (Dave Everitt) Date: Fri, 30 Dec 2011 14:07:26 +0000 Subject: Markaby license issue In-Reply-To: <951BDB76264D4BA2A132BB64D7ADB364@creativepony.com> References: <3CD7C575-DDD2-4DF1-A921-7E2E60AFF860@innotts.co.uk> <951BDB76264D4BA2A132BB64D7ADB364@creativepony.com> Message-ID: <571421A3-97DC-47F4-B0AE-29CDF499CF62@innotts.co.uk> Thanks for the summary Jenna - I dropped back from XHTML to HTML4.01 strict some time ago, then to HTML5, so for me the XML-like syntax permitted in HTML5 seems out of place. But I'm not losing sleep over it... for the discussion about Markaby I just thought it might be good to strip out anything unnecessary to reduce complexity - DaveE > 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 at rubyforge.org >> http://rubyforge.org/mailman/listinfo/camping-list > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list -------------- next part -------------- An HTML attachment was scrubbed... URL: