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
I don''t have time to look thru now, but it doesn''t seem to support boolean attributes (e.g. `input checked:true` should render <input checked="checked" />)? I was very much missing this feature in old Markaby, and finally even wrote a patch, as you might remember[1]. 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
2011/12/18 Bartosz Dziewo?ski <matma.rex at gmail.com>:> I don''t have time to look thru now, but it doesn''t seem to support > boolean attributes (e.g. `input checked:true` should render <input > checked="checked" />)? I was very much missing this feature in old > Markaby, and finally even wrote a patch, as you might remember[1].That''s actually supported. If an attribute is `true` it will use the attribute name as the value. (so checked: true is the same as checked: "checked"). Also, false and nil attributes won''t be included.> > It''d probably be quite easy to add, and after all it was included in > the latest 0.7.2 version. > > > [1] https://github.com/markaby/markaby/commit/999c418e3c096d2007d18c0a118390bd07d40eb0 > > -- Matma Rex > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list
2011/12/19 Magnus Holm <judofyr at gmail.com>:> 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
2011/12/19 Bartosz Dziewo?ski <matma.rex at gmail.com>:> 2011/12/19 Magnus Holm <judofyr at gmail.com>: >> 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.
> 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 startedI 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.
2011/12/19 Magnus Holm <judofyr at gmail.com>:> 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
> 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/
On Mon, Dec 19, 2011 at 21:34, Isak Andersson <IcePapih at lavabit.com> wrote:>> My suggestion would be to make it Markaby 2.0 (of course, once it''s >> running and mostly backwards-compatible), keeping the old gem name, >> and to develop on a branch in markaby repo. > > > Yeah, we should more or less do a rewrite and make it properly open source. > You are allowed to make something with the same name aren''t you? I mean > there > is songs with the same names after all. > > So what we would have wouldn''t exactly be Markaby but it would be used > exactly > like Markaby. We could make it smaller/faster and more up to date :)Just so everyone knows: Camping doesn''t depend on Markaby today. It''s only loaded when you actually try to use it. Would you suggest that we switch to a hard dependency on Markaby, or should we continue what we''re doing today?
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 <judofyr at gmail.com> wrote:> On Mon, Dec 19, 2011 at 21:34, Isak Andersson <IcePapih at lavabit.com> wrote: >>> My suggestion would be to make it Markaby 2.0 (of course, once it''s >>> running and mostly backwards-compatible), keeping the old gem name, >>> and to develop on a branch in markaby repo. >> >> >> Yeah, we should more or less do a rewrite and make it properly open source. >> You are allowed to make something with the same name aren''t you? I mean >> there >> is songs with the same names after all. >> >> So what we would have wouldn''t exactly be Markaby but it would be used >> exactly >> like Markaby. We could make it smaller/faster and more up to date :) > > Just so everyone knows: Camping doesn''t depend on Markaby today. It''s > only loaded when you actually try to use it. Would you suggest that we > switch to a hard dependency on Markaby, or should we continue what > we''re doing today? > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list-- Dave
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 <IcePapih at lavabit.com (mailto:IcePapih at lavabit.com)> wrote: > > > My suggestion would be to make it Markaby 2.0 (of course, once it''s > > > running and mostly backwards-compatible), keeping the old gem name, > > > and to develop on a branch in markaby repo. > > > > > > > > > > > Yeah, we should more or less do a rewrite and make it properly open source. > > You are allowed to make something with the same name aren''t you? I mean > > there > > is songs with the same names after all. > > > > So what we would have wouldn''t exactly be Markaby but it would be used > > exactly > > like Markaby. We could make it smaller/faster and more up to date :) > > > > > Just so everyone knows: Camping doesn''t depend on Markaby today. It''s > only loaded when you actually try to use it. Would you suggest that we > switch to a hard dependency on Markaby, or should we continue what > we''re doing today? > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org (mailto:Camping-list at rubyforge.org) > http://rubyforge.org/mailman/listinfo/camping-list > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/camping-list/attachments/20111220/0c36c7a5/attachment.html>
> switch to a hard dependency on Markaby, or should we continue what > we''re doing today?no hard dependency, continue as today - DaveE
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: <http://rubyforge.org/pipermail/camping-list/attachments/20111220/8e3997a3/attachment.html>
So then I''d have to remember it''s the opposite of the way it''s been? :P Dave On Mon, Dec 19, 2011 at 5:53 PM, Jenna Fox <a at creativepony.com> wrote:> If no hard dependancies, can we switch it around so core camping is in a > camping-seedling gem, and the regular camping gem is actually the one with > all the omnibus? I always forget when setting up a new system and end up > confused why camping isn''t working > > > ? > Jenna Fox > > On Tuesday, 20 December 2011 at 9:52 AM, Dave Everitt wrote: > > switch to a hard dependency on Markaby, or should we continue what > we''re doing today? > > > no hard dependency, continue as today - DaveE > _______________________________________________ > Camping-list mailing list > Camping-list 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
Nah I''d still just think "I want camping! I''ll install camping!" but then it''d just work :P ? Jenna Fox On Tuesday, 20 December 2011 at 1:15 PM, David Susco wrote:> So then I''d have to remember it''s the opposite of the way it''s been? :P > > Dave > > On Mon, Dec 19, 2011 at 5:53 PM, Jenna Fox <a at creativepony.com (mailto:a at creativepony.com)> wrote: > > If no hard dependancies, can we switch it around so core camping is in a > > camping-seedling gem, and the regular camping gem is actually the one with > > all the omnibus? I always forget when setting up a new system and end up > > confused why camping isn''t working > > > > > > ? > > Jenna Fox > > > > On Tuesday, 20 December 2011 at 9:52 AM, Dave Everitt wrote: > > > > switch to a hard dependency on Markaby, or should we continue what > > we''re doing today? > > > > > > no hard dependency, continue as today - DaveE > > _______________________________________________ > > Camping-list mailing list > > Camping-list 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: <http://rubyforge.org/pipermail/camping-list/attachments/20111220/4fccf242/attachment.html>
2011/12/19 Bartosz Dziewo?ski <matma.rex at gmail.com>:> 2011/12/19 Magnus Holm <judofyr at gmail.com>: >> 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.
On Mon, Dec 19, 2011 at 23:24, Jenna Fox <a at creativepony.com> 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.
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 <matma.rex at gmail.com (mailto:matma.rex at gmail.com)>: > > 2011/12/19 Magnus Holm <judofyr at gmail.com (mailto:judofyr at gmail.com)>: > > > 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: <http://rubyforge.org/pipermail/camping-list/attachments/20111220/94ce4aff/attachment.html>
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 <a at creativepony.com (mailto:a at creativepony.com)> 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: <http://rubyforge.org/pipermail/camping-list/attachments/20111220/c1b86d93/attachment.html>
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" <judofyr at gmail.com> wrote:> On Mon, Dec 19, 2011 at 23:24, Jenna Fox <a at creativepony.com> 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: <http://rubyforge.org/pipermail/camping-list/attachments/20111220/adbf9195/attachment.html>
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" <judofyr at gmail.com (mailto:judofyr at gmail.com)> wrote: > > On Mon, Dec 19, 2011 at 23:24, Jenna Fox <a at creativepony.com (mailto:a at creativepony.com)> 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: <http://rubyforge.org/pipermail/camping-list/attachments/20111220/1ec76a51/attachment-0001.html>