Demo Site and Template Code

[jeremyevans]

Google Group Post: https://groups.google.com/g/ruby-forme/c/_wVmkTTxhVc
Google Group Date: Tue, 6 May 2014 14:52:13 -0700
Google Group Sender: [email protected]

This is a good start. I've got the "Default" and "Explicit" pages open in
front of me.

I thought to myself "Why does 'debut album' get a checkbox but "out of
print" get a drop down? Surely they're both boolean?"

But now I can just flip back to the schema, and go "aahhhh, but 'out of
print' could also be null." And then I click the box, and sure enough,
there's a blank option. So, that was much easier to 'get' than before.

I would like to suggest, though, that " " isn't the best way to show a
null? It's too easy for a user to fail to see a blank line as an option. It
just looks like whitespace, some margin room in the form. Ideally, there's
a parameter for setting how to present nulls, but I'd suggest the default
be "(null)" or something else that is visible.

I'm still not sure what to do about

<% form(Album.first, form_attr, form_opts) do |f| %>

What are "form_attr" and "form_opts" set to? If they're nil, then why are
they there? They don't seem to be nil, but then I wonder what
"form_opts[:one]" evaluates to. I think I finally started to suspect what
was going on when I got to the "Association" demo, but that's well past
when I would normally have given up. Because the demo pages are in a clear
sequential order at the top, I think it's reasonable to expect people to
read them that way, and that means there shouldn't be anything on the
"Default" page that can only be understood by looking at the "Associations"
page.

We talked in email about sample data and what happens if you don't know it.
So, I think at the moment that the demo database's first album name is
"Elvis Presley?" Err?

I tried changing it to see what happened, but the "Update Album" button is
dead.

So what is the "Explicit" demo trying to show me? it's not clear how much
of the difference between that and "Default" is due to the CSS vs. due to
":labeler=>:explicit" as a form option.

I see that I can set "copies sold" to -1. I'm assuming I'd have to have
some sort of JavaScript going on to be able to limit the selectable range?

On the "Association" page, "Artist" "Tracks" and "Tags" are white type on a
gray background. It appears that that's because before labels were demarked
with a "" tag, but now the associations are getting a "" tag. It's not at all clear what caused that difference.

On all the non-nested forms, I was really puzzled by how "Tracks" was
appearing. I think it's because tracks.album_id is nullable. So, when the
"Default" form says "f.input(:tracks)", is Forme really loading the
entire tracks table and populating the selector with every track in the
database? If I check off the box for an unselected track, does that 'steal'
it from whatever other album it might be assigned to?

[jeremyevans]

Google Group Date: Tue, 6 May 2014 15:43:21 -0700
Google Group Sender: [email protected]

On Tuesday, May 6, 2014 2:52:13 PM UTC-7, [email protected] wrote:

This is a good start. I've got the "Default" and "Explicit" pages open in
front of me.

I thought to myself "Why does 'debut album' get a checkbox but "out of
print" get a drop down? Surely they're both boolean?"

But now I can just flip back to the schema, and go "aahhhh, but 'out of
print' could also be null." And then I click the box, and sure enough,
there's a blank option. So, that was much easier to 'get' than before.

I would like to suggest, though, that " " isn't the best way to show a
null? It's too easy for a user to fail to see a blank line as an option. It
just looks like whitespace, some margin room in the form. Ideally, there's
a parameter for setting how to present nulls, but I'd suggest the default
be "(null)" or something else that is visible.

The problem with (null) instead of the empty is that most people using the
forms aren't coming from a database background and aren't going to know
what (null) means. Using an empty option for no choice is far more common
than using (null) in my experience.

Note that you can use :add_blank=>'(null)' to use a specific label for the
null value, so you can override this on a per call basis. I could also
make the default a global setting, so if you want all of your blank options
to default to '(null)', you can do that. But I think the default value
should remain blank.

I'm still not sure what to do about

<% form(Album.first, form_attr, form_opts) do |f| %>

What are "form_attr" and "form_opts" set to? If they're nil, then why are
they there? They don't seem to be nil, but then I wonder what
"form_opts[:one]" evaluates to. I think I finally started to suspect what
was going on when I got to the "Association" demo, but that's well past
when I would normally have given up. Because the demo pages are in a clear
sequential order at the top, I think it's reasonable to expect people to
read them that way, and that means there shouldn't be anything on the
"Default" page that can only be understood by looking at the "Associations"
page.

form_attr and form_opts are there because all of the basic views share the
same template. I suppose I could change the layout so that it shows the
contents of form_attr and form_opts.

We talked in email about sample data and what happens if you don't know
it. So, I think at the moment that the demo database's first album name is
"Elvis Presley?" Err?

Elvis's first album was titled Elvis Presley. :) Maybe I should default to
the last album instead of the first?

I tried changing it to see what happened, but the "Update Album" button
is dead.

Unlike the AutoForme demo, the Forme demo is not modifably by the user. It
serves only to show the forms created. Forme doesn't handle processing of
the forms, so I don't think that should be part of the demo. I probably
should put a notice on the front page that the forms are not functional.
This will also be more obvious if I show the form_attr on the example
pages, since it is set to {:onsubmit=>'return false'}.

So what is the "Explicit" demo trying to show me? it's not clear how much
of the difference between that and "Default" is due to the CSS vs. due to
":labeler=>:explicit" as a form option.

It's sort of expected that users of a form library are interested in the
HTML it uses, so I would expect them to view source to see the differences.
The difference between :labeler=>:explicit and the default is that instead
of including the input tags inside the label tag, it uses the for attribute
of the label tag to reference the id of the form input. The explicit
labeler requires that all inputs being referenced have the id attribute
set, and since Forme cannot enforce that, the default is the implicit
labeler.

I see that I can set "copies sold" to -1. I'm assuming I'd have to have
some sort of JavaScript going on to be able to limit the selectable range?

Probably. Forme doesn't use any javascript, and there aren't plans to add
javascript features in the future. Forme does have the ability to use the
reflections added by the validation_class_methods plugin to automatically
set up some HTML5 input attributes such as pattern, though the demo doesn't
do that.

On the "Association" page, "Artist" "Tracks" and "Tags" are white type on
a gray background. It appears that that's because before labels were
demarked with a "" tag, but now the associations are getting a
"" tag. It's not at all clear what caused that
difference.

When using a set of radio buttons or a set of checkbox buttons instead of a
single or multiple select box, you can't use a label tag as label tags are
supposed to reference a single input. When using a set of buttons, each
button has their own label tag. So as a work around, the label for the set
of buttons is changed to a span tag, which is displayed differently by
Bootstrap.

On all the non-nested forms, I was really puzzled by how "Tracks" was
appearing. I think it's because tracks.album_id is nullable. So, when the
"Default" form says "f.input(:tracks)", is Forme really loading the
entire tracks table and populating the selector with every track in the
database? If I check off the box for an unselected track, does that 'steal'
it from whatever other album it might be assigned to?

Forme really is loading the entire tracks table to display the associated
track. It's also loading the entire artists table to show the available
artists that the album can be associated with. Obviously you shouldn't use
this feature in a large database. In AutoForme, you'd generally use
autocompletion for large tables.

Yes, if you unselect a box for a track and submitted it, assuming the form
input was actually processed, it would remove that track from the album.
And if you selected an unselected track and submitted it, it would set the
foreign key of that track to the current album. Few people are going to
want to associate/disassociate objects for a one_to_many association. It's
much more common in a many_to_many situation, as shown with the tags below
it.

Thanks,
Jeremy

[jeremyevans]

Google Group Date: Tue, 6 May 2014 21:16:01 -0700
Google Group Sender: [email protected]

On May 6, 2014, at 15:43 , Jeremy Evans [email protected] wrote:

The problem with (null) instead of the empty is that most people using the forms aren't coming from a database background and aren't going to know what (null) means. Using an empty option for no choice is far more common than using (null) in my experience.

I’m sure it is. I would, however, argue that it’s still just about the worst possible thing to actually use. It’s only going to appear by itself when Forme is populated from a database, and if somebody’s doing that and doesn’t know what “null” means . . . c’mon. Whether it’s “(null)”, “”, “N/A”, or “???”, having actual visible text is, I think, going to be far more comprehensible to the user (not the programmer). In most cases, it ought to be context-specific, but defaulting to white space means there will be plenty of end users who, if the column contains ‘true’ or ‘false,’ won’t understand that the blank area at the top of the drop-down is, in fact, one of their choices.

Note that you can use :add_blank=>'(null)' to use a specific label for the null value, so you can override this on a per call basis. I could also make the default a global setting, so if you want all of your blank options to default to '(null)', you can do that. But I think the default value should remain blank.

Being able to set a global default for that seems like the sort of configurable option you tend to offer anyway, no?

form_attr and form_opts are there because all of the basic views share the same template. I suppose I could change the layout so that it shows the contents of form_attr and form_opts.

I think having
form_attr={}
form_opts={}
on the default page (and likewise on the others, as appropriate) would be very helpful. At some point, I’m going to try to write up a paragraph for each of those that would go at the top to provide a sort of guided tour of what it’s all doing.

We talked in email about sample data and what happens if you don't know it. So, I think at the moment that the demo database's first album name is "Elvis Presley?" Err?

Elvis's first album was titled Elvis Presley. :)

That’s what I was afraid of.

Maybe I should default to the last album instead of the first?

How about to the most famous one? :) But yea, something that has an album-y sounding name would be clearer.

Unlike the AutoForme demo, the Forme demo is not modifably by the user. I

Ah. I just got confused. Okay, that’s fine.

It's sort of expected that users of a form library are interested in the HTML it uses, so I would expect them to view source to see the differences. The difference between :labeler=>:explicit and the default is that instead of including the input tags inside the label tag, it uses the for attribute of the label tag to reference the id of the form input.

Ah. That’s exactly the sort of info I want to put into explanatory text.

Probably. Forme doesn't use any javascript, and there aren't plans to add javascript features in the future.

That’s fine. Client-side validation can be added by the programmer without making Forme do the heavy lifting.

Few people are going to want to associate/disassociate objects for a one_to_many association.

That’s what I was thinking. It seemed like something so rarely useful that I assumed at first I was merely failing to understand what was actually going on. With my library, if I included “:track” in the form, it took for granted what I think you use subform for: the link between the parent object and the associated is taken as inviolate; what you get is the ability to change fields of the associated object. To actually change the link was done by referencing the column, not the association. Mapping my library’s behavior onto Forme syntax, editing an album’s track would be f.input(:track); associating/dessociating a track would be done with f.input(:track_id).

When using a set of radio buttons or a set of checkbox buttons instead of a single or multiple select box, you can't use a label tag as label tags are supposed to reference a single input. When using a set of buttons, each button has their own label tag. So as a work around, the label for the set of buttons is changed to a span tag, which is displayed differently by Bootstrap.

Ah, I see. I went and read up on what a “label” is. Hmm.

[jeremyevans]

Google Group Date: Wed, 7 May 2014 10:40:32 -0700
Google Group Sender: [email protected]

On Tuesday, May 6, 2014 9:16:01 PM UTC-7, Dave Howell wrote:

On May 6, 2014, at 15:43 , Jeremy Evans wrote:

The problem with (null) instead of the empty is that most people using
the forms aren't coming from a database background and aren't going to know
what (null) means. Using an empty option for no choice is far more common
than using (null) in my experience.

I’m sure it is. I would, however, argue that it’s still just about the
worst possible thing to actually use. It’s only going to appear by itself
when Forme is populated from a database, and if somebody’s doing that and
doesn’t know what “null” means . . . c’mon. Whether it’s “(null)”, “”,
“N/A”, or “???”, having actual visible text is, I think, going to be far
more comprehensible to the user (not the programmer). In most cases, it
ought to be context-specific, but defaulting to white space means there
will be plenty of end users who, if the column contains ‘true’ or ‘false,’
won’t understand that the blank area at the top of the drop-down is, in
fact, one of their choices.

Well, I do deal with many non-technical users that appear to understand it
intuitively. That's obviously anecdotal, but at least for me it hasn't
been a problem.

One issue with any non-blank text is it can potentially overlap with
existing valid options, while an empty string will generally not be valid
(assuming you have a presence validation or something similar on the
column).

Note that you can use :add_blank=>'(null)' to use a specific label for
the null value, so you can override this on a per call basis. I could also
make the default a global setting, so if you want all of your blank options
to default to '(null)', you can do that. But I think the default value
should remain blank.

Being able to set a global default for that seems like the sort of
configurable option you tend to offer anyway, no?

Correct. I've added this to my todo list.

form_attr and form_opts are there because all of the basic views share
the same template. I suppose I could change the layout so that it shows
the contents of form_attr and form_opts.

I think having
form_attr={}
form_opts={}
on the default page (and likewise on the others, as appropriate) would be
very helpful. At some point, I’m going to try to write up a paragraph for
each of those that would go at the top to provide a sort of guided tour of
what it’s all doing.

I've made these changes in my local branch, I should hopefully have time to
push it with some other changes later today.

We talked in email about sample data and what happens if you don't know
it. So, I think at the moment that the demo database's first album name is
"Elvis Presley?" Err?

Elvis's first album was titled Elvis Presley. :)

That’s what I was afraid of.

Maybe I should default to the last album instead of the first?

How about to the most famous one? :) But yea, something that has an
album-y sounding name would be clearer.

I think just using the last album ought to fix this. At least that album
isn't self titled.

It's sort of expected that users of a form library are interested in the
HTML it uses, so I would expect them to view source to see the differences.
The difference between :labeler=>:explicit and the default is that instead
of including the input tags inside the label tag, it uses the for attribute
of the label tag to reference the id of the form input.

Ah. That’s exactly the sort of info I want to put into explanatory text.

That makes sense to me too. I've also made that change in my local branch.

Few people are going to want to associate/disassociate objects for a
one_to_many association.

That’s what I was thinking. It seemed like something so rarely useful that
I assumed at first I was merely failing to understand what was actually
going on. With my library, if I included “:track” in the form, it took for
granted what I think you use subform for: the link between the parent
object and the associated is taken as inviolate; what you get is the
ability to change fields of the associated object. To actually change the
link was done by referencing the column, not the association. Mapping my
library’s behavior onto Forme syntax, editing an album’s track would be
f.input(:track); associating/dessociating a track would be done with
f.input(:track_id).

One alternative is that for the basic forms (not the nested ones), just
don't show the tracks association. The tags association has all of the
same options as the tracks association, so I don't think it misses showing
any of the features.

Thanks for reviewing these changes, it's very helpful to be able to get
feedback.

Jeremy

[jeremyevans]

Google Group Date: Wed, 7 May 2014 11:15:30 -0700
Google Group Sender: [email protected]

Using an empty option for no choice is far more common than using (null) in my experience.

I’m sure it is. I would, however, argue that it’s still just about the worst possible thing to actually use.

Well, I do deal with many non-technical users that appear to understand it intuitively. That's obviously anecdotal, but at least for me it hasn't been a problem.

I retire the point. The most important aspect to me is that you have thought about it and have reasoning to back up the decision, and you’ve definitely got that. Once the global default option is in place, it will be entirely satisfactory for my purposes.

It's sort of expected that users of a form library are interested in the HTML it uses, so I would expect them to view source to see the differences.

Reasonable. At the moment, I’m focused more on being able to get data in and out of the database, because that’s harder than reshaping the HTML that Forme spits out, so I’d put looking at the output as a lower priority.

One alternative is that for the basic forms (not the nested ones), just don't show the tracks association. The tags association has all of the same options as the tracks association, so I don't think it misses showing any of the features.

You mean for the demo site? I think that sounds good. Esp. for people who aren’t as hard-core database-driven, the association cleverness might not be their primary concern. Leaving it out for the first part and adding it in after the core functions have been demonstrated might reduce the cognitive load.

Thanks for reviewing these changes, it's very helpful to be able to get feedback.

Oh, good. I wasn’t sure if I’d crossed over from “helpful comments” to “annoying whining” yet. :)

Probably my next set of comments are going to be around the wrappers. I have to dig into that a bit.

[jeremyevans]

Google Group Date: Wed, 7 May 2014 12:12:18 -0700
Google Group Sender: [email protected]

I've updated the demo-site to reflect the discussed changes. I still need
to add the ability to set the default for the :add_blank default prompt.
Hopefully I'll have time for that later today or later this week.

Thanks,
Jeremy

[jeremyevans]

Google Group Date: Wed, 7 May 2014 14:31:35 -0700
Google Group Sender: [email protected]

On May 7, 2014, at 12:12 , Jeremy Evans [email protected] wrote:

I've updated the demo-site to reflect the discussed changes. I still need to add the ability to set the default for the :add_blank default prompt. Hopefully I'll have time for that later today or later this week.

Groovy.

I took a closer look at it.

“Okay, so he’s got the ‘form,’ and then he nested a bunch of ‘f.input’ commands inside an ‘f.inputs’ command. I wonder why?”

{looks at source}

“Apparently that makes the

happen, and there’s the command. I wonder what the heck those are for?”

{googles for ‘html form legend’}

“‘Legend’ is a caption for a fieldset, and a fieldset draws a box around a set of fields. A box? What box?”

So then I saved the page source to my desktop, and reopened it, thus breaking the style sheet links. I have to say that the relationship between the template and the HTML is quite a bit clearer .

Are the following two code fragments synonymous?

f.inputs([:legend=>’Album’, :name, :copies_sold)

f.inputs(:legend=>’Album’) do
f.input(:name)
f.input(:copies_sold)
end

[jeremyevans]

Google Group Date: Wed, 7 May 2014 14:36:12 -0700
Google Group Sender: [email protected]

On Wednesday, May 7, 2014 2:31:35 PM UTC-7, Dave Howell wrote:

Are the following two code fragments synonymous?

f.inputs([:legend=>’Album’, :name, :copies_sold)

f.inputs(:legend=>’Album’) do
f.input(:name)
f.input(:copies_sold)
end

Pretty much. The options hash needs to come as the second argument, though:

f.inputs([:name, :copies_sold], :legend=>’Album’)

Jeremy

[jeremyevans]

Google Group Date: Wed, 7 May 2014 14:46:01 -0700
Google Group Sender: [email protected]

On Wednesday, May 7, 2014 12:12:18 PM UTC-7, Jeremy Evans wrote:

I've updated the demo-site to reflect the discussed changes. I still need
to add the ability to set the default for the :add_blank default prompt.
Hopefully I'll have time for that later today or later this week.

I've pushed up a few more commits to GitHub, one of which supports setting
the :add_blank default prompt.

Thanks,
Jeremy

[jeremyevans]

Google Group Date: Wed, 7 May 2014 15:07:14 -0700
Google Group Sender: [email protected]

On May 7, 2014, at 14:36 , Jeremy Evans [email protected] wrote:

Pretty much. The options hash needs to come as the second argument, though:

f.inputs([:name, :copies_sold], :legend=>’Album’)

From the documentation:

“[inputs(*a, &block)]...calls input on each element of inputs,”

Should that be

“[inputs(*a, &block)]...calls input on each element of inputs,”
?

The given opts are passed to the inputs_wrapper, and the default inputs_wrapper supports a :legend option that is used to set the legend for the fieldset.

I’m not sure how I can tell that “:legend=>’Album’” goes outside the array, and after it, from that.

[jeremyevans]

Google Group Date: Wed, 7 May 2014 15:14:55 -0700
Google Group Sender: [email protected]

On Wednesday, May 7, 2014 3:07:14 PM UTC-7, Dave Howell wrote:

On May 7, 2014, at 14:36 , Jeremy Evans wrote:

Pretty much. The options hash needs to come as the second argument,
though:

f.inputs([:name, :copies_sold], :legend=>’Album’)

From the documentation:

“[inputs(*a, &block)]...calls input on each element of inputs,”

Should that be

“[inputs(*a, &block)]...calls input on each element of inputs,”

?

The documentation is wrong because the method signature uses a splat and
passes the arguments to _inputs. I've just pushed a change so that inputs
has the same signature as _inputs, which should fix this.

Note that this wouldn't be reflected on the RDoc site, since that always
reflects the latest release (0.9.2 in this case).

Thanks,
Jeremy

[jeremyevans]

Google Group Date: Wed, 7 May 2014 15:27:14 -0700
Google Group Sender: [email protected]

On May 7, 2014, at 15:14 , Jeremy Evans [email protected] wrote:

The documentation is wrong because the method signature uses a splat and passes the arguments to _inputs. I've just pushed a change so that inputs has the same signature as _inputs, which should fix this.

Er, come again? “Splat” = asterisk? So you’re saying that what it should have said is

inputs(inputs=[], opts={}) { || … }

which is what _inputs says, because inputs is defined as “inputs (*a, &block)”, and it just turns right around and hands “a” off to _inputs?

If that’s so, then how does it work to do

f.inputs(:legend=>’Album’) do

? Because doesn’t that put the options hash in the first parameter?

Note that this wouldn't be reflected on the RDoc site, since that always reflects the latest release (0.9.2 in this case).

Yea, I was cut-n-paste-ing from my local docs. What do I need to do to be able to see the mostest up-to-date set?

[jeremyevans]

Google Group Date: Wed, 7 May 2014 15:36:08 -0700
Google Group Sender: [email protected]

On Wednesday, May 7, 2014 3:27:14 PM UTC-7, Dave Howell wrote:

On May 7, 2014, at 15:14 , Jeremy Evans wrote:

The documentation is wrong because the method signature uses a splat and
passes the arguments to _inputs. I've just pushed a change so that inputs
has the same signature as _inputs, which should fix this.

Er, come again? “Splat” = asterisk? So you’re saying that what it should
have said is

Yes, splat means * in this context. This is a pretty common term in the
ruby community.

If that’s so, then how does it work to do

f.inputs(:legend=>’Album’) do

? Because doesn’t that put the options hash in the first parameter?

If the first argument is a hash and not an array, it merges it with the
second argument and the output is treated as the options hash. This makes
it easier to use when you aren't providing inputs. I'm guessing I should
document that? :) I'll do that.

Yea, I was cut-n-paste-ing from my local docs. What do I need to do to be

able to see the mostest up-to-date set?

Clone the repository and run rake rdoc. The output might look different
than the website, though.

Thanks,
Jeremy

[jeremyevans]

Google Group Date: Wed, 7 May 2014 15:49:19 -0700
Google Group Sender: [email protected]

On May 7, 2014, at 15:36 , Jeremy Evans [email protected] wrote:

Yes, splat means * in this context. This is a pretty common term in the ruby community.

Oh, it’s a pretty common term in general. However, many Macintosh users use “splat” to identify ⌘, the Command meta key. Since it’s ambiguous, I thought I’d confirm.

I have an editorial background, and still work part of the year as a textbook typesetter. I know that “#” has been called “the number sign,” “the pound sign,” and “hash”, but that its true name is “an octothorpe,” and that ~ is NOT a tilde. It’s a swung dash. It becomes a tilde only when it sits atop a letter. I do my best to keep my typographic pedantry to a minimum. :)

If the first argument is a hash and not an array, it merges it with the second argument and the output is treated as the options hash. This makes it easier to use when you aren't providing inputs. I'm guessing I should document that? :) I'll do that.

Indeed. :)

Clone the repository and run rake rdoc. The output might look different than the website, though.

I’ll see if I can puzzle this out. Looking different is fine, though, I really really dislike the ‘new’ default format somebody concocted. It’s dramatically less functional than the old.

[jeremyevans]

Google Group Date: Wed, 7 May 2014 15:56:16 -0700
Google Group Sender: [email protected]

On Wednesday, May 7, 2014 3:49:19 PM UTC-7, Dave Howell wrote:

If the first argument is a hash and not an array, it merges it with the
second argument and the output is treated as the options hash. This makes
it easier to use when you aren't providing inputs. I'm guessing I should
document that? :) I'll do that.

Indeed. :)

I've pushed another commit for that.

Clone the repository and run rake rdoc. The output might look different
than the website, though.

I’ll see if I can puzzle this out. Looking different is fine, though, I
really really dislike the ‘new’ default format somebody concocted. It’s
dramatically less functional than the old.

If you want it looking like the website:

gem install rdoc --version ' = 3.12.2' # last version before 4
gem install hanna-nouveau

The issue is that since rdoc 3, the default template is darkfish, a
frameless template. Hanna was an older alternative rdoc template for rdoc
2. When rdoc 3 came out, hanna-nouveau ported the hanna code over to rdoc
3's new API (I helped a little with that). Unfortunately, rdoc 4 changed
the API again, so you can't run hanna-nouvueau with rdoc 4. The Rakefile
will use rdoc 3.12.2 and hanna-nouveau if both are found on the system. If
I end up with a lot of spare time, I may try porting hanna-nouveau to the
rdoc 4 API.

Thanks,
Jeremy

[jeremyevans]

Google Group Date: Wed, 7 May 2014 17:02:27 -0700
Google Group Sender: [email protected]

On May 7, 2014, at 15:56 , Jeremy Evans [email protected] wrote:

If you want it looking like the website:

Like the website . . . I’m not sure I’ve seen the online docs . . .

Holy retrochronotron! Yea, that! The format that actually lets you find stuff, and doesn’t suck! Yea!

The template that came with 1.8.7 had the frames across the top, and I moved them to the side on my own personal install because, well, they’re better there. I’m still using my 1.8.7 RDoc tree with 2.0 because the 2.0 install’s docs are so dysfunctional.

{happy dance}

[jeremyevans]

Google Group Date: Wed, 7 May 2014 19:18:21 -0700
Google Group Sender: [email protected]

On May 7, 2014, at 15:56 , Jeremy Evans [email protected] wrote:

If you want it looking like the website:

gem install rdoc --version ' = 3.12.2' # last version before 4
gem install hanna-nouveau

That, was bloody awful. Neither one of those gems can be installed as is.

rdoc insisted on installing json. json has invalid command line parameters. Previously, XCode apparently overlooked garbage on the command line. Now, it calls that an error. It proved impossible to force the stupid gem to not either overwrite the fixed makefile, or blow up in a temper tantrum when I told it to leave the frickin’ file alone. Eventually I just copied json 1.5.5 from my ruby 1.8 install.

hanna-nouveau did get itself installed, but the docs failed:

Installing darkfish documentation for haml-3.0.25
ERROR: While executing gem ... (RDoc::Error)
error generating /Library/Ruby/Gems/2.0.0/doc/haml-3.0.25/rdoc/Rakefile.html: Error while evaluating /Library/Ruby/Gems/2.0.0/gems/rdoc-3.12.2/lib/rdoc/generator/template/darkfish/page.rhtml: undefined method `chomp' for nil:NilClass (RDoc::Error)

Cripes.

I finally have my docs, though. {pant pant pant}

[jeremyevans]

Google Group Date: Wed, 7 May 2014 20:09:29 -0700
Google Group Sender: [email protected]

On Wednesday, May 7, 2014 7:18:21 PM UTC-7, Dave Howell wrote:

On May 7, 2014, at 15:56 , Jeremy Evans wrote:

If you want it looking like the website:

gem install rdoc --version ' = 3.12.2' # last version before 4
gem install hanna-nouveau

That, was bloody awful. Neither one of those gems can be installed as is.

rdoc insisted on installing json. json has invalid command line
parameters. Previously, XCode apparently overlooked garbage on the command
line. Now, it calls that an error. It proved impossible to force the stupid
gem to not either overwrite the fixed makefile, or blow up in a temper
tantrum when I told it to leave the frickin’ file alone. Eventually I just
copied json 1.5.5 from my ruby 1.8 install.

hanna-nouveau did get itself installed, but the docs failed:

Installing darkfish documentation for haml-3.0.25
ERROR: While executing gem ... (RDoc::Error)
error generating
/Library/Ruby/Gems/2.0.0/doc/haml-3.0.25/rdoc/Rakefile.html: Error while
evaluating
/Library/Ruby/Gems/2.0.0/gems/rdoc-3.12.2/lib/rdoc/generator/template/darkfish/page.rhtml:
undefined method `chomp' for nil:NilClass (RDoc::Error)

Cripes.

I finally have my docs, though. {pant pant pant}

That sucks. I didn't realize how broken the install is, since I haven't
done it in a while. The json gem ships with ruby 2.0, so rdoc should
theoretically use the already installed gem instead of trying to install a
new one. The error while installing docs looks to be internal to rdoc, I'm
not sure what is up with that.

At least it's working now.

Thanks,
Jeremy

[jeremyevans]

Google Group Date: Thu, 8 May 2014 15:02:19 -0700
Google Group Sender: [email protected]

On May 7, 2014, at 20:09 , Jeremy Evans [email protected] wrote:

The error while installing docs looks to be internal to rdoc, I'm not sure what is up with that.

It’s HAML’s docs, so I was wondering if it had been upgraded to the RDoc 4.0 standard, which was then failing because I’d pushed RDoc back down to the 3.x version. {shrug}

Although what I went through to get gems to compile both as i386 and x86_64 was ten times worse than this. Since the OS scripting interface is still 32-bit, some of my existing code has to be run as i386, but getting the gems to compile as post-PowerPC universal was stupidly hard.

They call it “universal” now, but I don’t unless it looks like this:
file “/Library/PostgreSQL/psqlODBC/lib/psqlodbcw.so"
/Library/PostgreSQL/psqlODBC/lib/psqlodbcw.so: Mach-O universal binary with 3 architectures
/Library/PostgreSQL/psqlODBC/lib/psqlodbcw.so (for architecture i386): Mach-O bundle i386
/Library/PostgreSQL/psqlODBC/lib/psqlodbcw.so (for architecture ppc7400): Mach-O bundle ppc
/Library/PostgreSQL/psqlODBC/lib/psqlodbcw.so (for architecture x86_64): Mach-O 64-bit bundle x86_64

I have some shipping software with (in theory) an ODBC interface. It doesn’t work. I complained. They told me “You probably don’t have the right architecture in your driver.” I told them “try again.” They eventually admitted that it just doesn’t work right in the Mac version.