On Sat, Dec 16, 2017 at 7:18 PM, Craig Russell <apache....@gmail.com> wrote:
> I'm starting to work on the project/discuss and project/vote stuff and have a
> few questions.
>
> I am having a hard time seeing the entire picture considering that some of
> the application runs on the server and some runs on the client. From the top,
> looking at the project/icla directory, config.ru is read by some component
> which tells it to run Sinatra::Application. Which then finds main.rb which
> somehow inherits the Sinatra code and routes the url to the proper code via
> the get function.
Apache runs Passenger which runs Rack, which runs config.ru. Main.rb
requires wunderbar/sinatra, which requires sinatra.
> The get function is invoked when an https get comes in. It declares some
> variables like @view, @pmcs, @ppmcs, user, committees, and ipmc. What is the
> naming convention for these? Which of them are sent to the client?
Variables which start with an @ sign will be passed to the view.
> In the get function the last line is _html :app. What is the :app?
That invokes views/app.html.rb. Simliarly, _json
:"actions/#{params[:file]}" will invoke a file from
views/actions/*.json.rb
> I envision using project/discuss and project/vote in addition to
> project/icla. To structure this as one application, would it be better to use
> project/icla as the root and use project/icla/discuss, project/icla/vote in
> addition to the existing project/icla/invite and project/icla/interview?
It is indeed probably best to make this one application.
project/icla/* would work. You could rename the whole directory if
you wanted something other that /icla/.
> The code in the existing main.rb in get '/invite' sets several variables that
> will be useful in discuss and vote. DRY says this code should only be in one
> place. How can variables be shared among multiple get and post paths?
Two basic approaches come to mind. In the roster tool, there is code
in the models directory that return hashes. Also in
www/roster/main.rb, you can find a helper that is called by multiple
views.
> I'd like to be able to test this code more easily by being able to mock
> users. That is, I'd like to be able to run the code as another user. So I
> would invoke the application via:
> https://whimsy.apache.org/project/icla/discuss?mock=rubys. Then, the code
> would set the user to rubys in order to test what happens with rubys. But I
> don't want just anyone to be able to pretend to be rubys. So I guess the code
> should only allow mock= to be used if the real user is a member of the whimsy
> developer team.
Would you want to mock users in production? If not, you could check
env['SERVER_NAME']. Compare the results of the following two URLs:
https://whimsy.apache.org/board/agenda/env
http://whimsy.local/board/agenda/env
> I would like to store the intermediate results in a file, as previously
> discussed. Using a unique file name (generated by a random string uuid
> generator) I can open the file with suffix .json or .yaml. Any idea which
> would be better for this application? The object stored would contain the
> status of the process for the user, so a sample file might be:
Either JSON or YAML would be fine. I have a mild preference for YAML.
> status: 'voting',
> proposedBy: 'clr',
> candidateName: 'Greg Rousseau',
> candidateEmail: 'greg.rouss...@gmail.com',
> votes: [
> {member: 'clr', vote: '+1', comment: 'seems like a good guy'},
> {member: 'rubys', vote: '+1', comment: 'seems like a better guy'},
> {member: 'max', vote: '+0', comment: 'don't no this guy'},
> {member: 'sebb', vote: '+1', comment: ''}
> ],
> discussion: [
> {member: 'clr', comment: 'seems like a good guy'},
> {member: 'rubys', comment: 'seems like a better guy'},
> {member: 'sebb', comment: 'seems like a best guy'},
> ]
>
> The above is json. Would it be trivial to make a ruby object out of this and
> transmit it to and from the client? Is a complex object like this suitable
> for sending to the client?
Yes to all of the above.
Examples of complex objects that are currently sent to the client:
https://whimsy.apache.org/board/agenda/2017-12-20.json
https://whimsy.apache.org/roster/committee/whimsy.json
Note: while either YAML or JSON are fine for server storage; JSON is
the way to communicate between client and server.
> Thanks,
>
> Craig "the noob"
>
> Craig L Russell
> Secretary, Apache Software Foundation
> c...@apache.org http://db.apache.org/jdo
- Sam Ruby
