| 2010-06-03 00:47:47 utc | jmettraux | lbt: many thanks for the wiki work, I will give it a second pass if you don't mind |
| 2010-06-03 06:40:16 utc | jmettraux | tosch_le: hello, I'm sorry, I can't release a 2.1.0 today |
| 2010-06-03 06:40:23 utc | jmettraux | ah wait |
| 2010-06-03 06:40:30 utc | jmettraux | friday is tomorrow |
| 2010-06-03 06:40:47 utc | tosch_le | just wanted to ask if you didn't say 'friday' |
| 2010-06-03 06:40:52 utc | jmettraux | :) |
| 2010-06-03 06:40:57 utc | tosch_le | coffee? ;) |
| 2010-06-03 06:41:08 utc | jmettraux | please ! |
| 2010-06-03 06:41:33 utc | tosch_le | ACTION emmits coffee |
| 2010-06-03 06:41:46 utc | jmettraux | ACTION receives coffee |
| 2010-06-03 06:41:50 utc | jmettraux | many thanks ! |
| 2010-06-03 06:42:06 utc | tosch_le | s/mm/m |
| 2010-06-03 06:42:18 utc | tosch_le | *blush* |
| 2010-06-03 06:45:51 utc | jmettraux | tosch_le: rspec question : is it possible to run a spec in isolation from others in ruote-kit ? |
| 2010-06-03 06:46:17 utc | tosch_le | one question regarding /participants: in Ruote::ParticipantList, there is only a public method (names) for getting a list of all participant names. information about the participants has to be fetched one by one for each participant. |
| 2010-06-03 06:46:56 utc | tosch_le | i assume that you can run one of the spec files in isolation from others. |
| 2010-06-03 06:47:05 utc | kennethkalmer | hi guys |
| 2010-06-03 06:47:18 utc | kennethkalmer | jmettraux: spec path/to/spec |
| 2010-06-03 06:47:37 utc | kennethkalmer | or: spec path/to/spec -e 'Full description of spec' |
| 2010-06-03 06:47:52 utc | jmettraux | kennethkalmer: I always forget "rspec".gsub(/^r/, '') |
| 2010-06-03 06:48:39 utc | tosch_le | 'rspec'[1..-1] |
| 2010-06-03 06:48:48 utc | tosch_le | ;-p |
| 2010-06-03 06:49:00 utc | kennethkalmer | :) |
| 2010-06-03 06:49:56 utc | jmettraux | tosch_le: as a temp workaround : info = engine.context.plist.send(:get_list)['list'] |
| 2010-06-03 06:50:16 utc | tosch_le | back to /participants: is it ok if GET /particpants just returns a list of participant names (information on each participant may be fetched by /participants/:name) or shall i query the storage directly? |
| 2010-06-03 06:50:22 utc | jmettraux | now if you have a nice name for the method that should wrap that ... |
| 2010-06-03 06:51:13 utc | tosch_le | i think it would be enough if get_list would be a public method instead a protected one. |
| 2010-06-03 06:51:24 utc | jmettraux | tosch_le: if it feels more in line with the other ruote-kit resources, I can add a method to engine directly |
| 2010-06-03 06:51:35 utc | jmettraux | get_list['list'] looks awkward though |
| 2010-06-03 06:52:00 utc | tosch_le | what about engine.context.plist.to_h? |
| 2010-06-03 06:52:09 utc | jmettraux | well |
| 2010-06-03 06:52:26 utc | jmettraux | it seems to imply that plist is a resource rather than a service |
| 2010-06-03 06:52:33 utc | jmettraux | IMHO |
| 2010-06-03 06:53:06 utc | tosch_le | even the name implies its a resource IMHO |
| 2010-06-03 06:53:27 utc | jmettraux | true |
| 2010-06-03 06:53:38 utc | jmettraux | I should change that name then |
| 2010-06-03 06:54:46 utc | jmettraux | is there an engine.to_h ? |
| 2010-06-03 06:55:11 utc | jmettraux | have to change fire position |
| 2010-06-03 07:02:12 utc | tosch_le | but it _is_ a list. |
| 2010-06-03 07:02:56 utc | jmettraux | the return value of plist.get_list['list'] is |
| 2010-06-03 07:03:12 utc | tosch_le | and there are just functions dealing with that list: adding and removing an item, retrieving information about one and getting a list of the members' names |
| 2010-06-03 07:03:56 utc | jmettraux | that's true |
| 2010-06-03 07:04:00 utc | tosch_le | an instance of ::Hash is a list, too, with similar methods |
| 2010-06-03 07:04:16 utc | jmettraux | service != entity |
| 2010-06-03 07:05:04 utc | jmettraux | that's why I'd love to change the name of ParticipantList to something else |
| 2010-06-03 07:05:22 utc | tosch_le | ParticipantListService ? ;-) |
| 2010-06-03 07:05:25 utc | jmettraux | in the light of your question about to_h, I think I made a bad naming decision |
| 2010-06-03 07:05:26 utc | jmettraux | :) |
| 2010-06-03 07:07:27 utc | tosch_le | engine.participants would be cute, i assume. but i suppose one would expect to get instances of participants and not just a configuration hash? |
| 2010-06-03 07:08:19 utc | jmettraux | returning classes and/or instance would be OK |
| 2010-06-03 07:08:27 utc | jmettraux | instances |
| 2010-06-03 07:09:25 utc | tosch_le | yeah, but that wouldn't help with /participants in rk |
| 2010-06-03 07:10:30 utc | jmettraux | the instance can be replaced with something like "**instance**" |
| 2010-06-03 07:13:08 utc | jmettraux | { '^user\_.*': [ "Ruote::StorageParticipant", {} ] } |
| 2010-06-03 07:13:12 utc | jmettraux | would be acceptable |
| 2010-06-03 07:13:30 utc | jmettraux | well |
| 2010-06-03 07:13:39 utc | jmettraux | wrong, order matters |
| 2010-06-03 07:14:37 utc | jmettraux | [ [ "toto", "MyParticipant", { 'customer': 2 } ], [ "^user\_.*", "Ruote::StorageParticipant", {} ] ] |
| 2010-06-03 07:16:07 utc | jmettraux | ACTION escapes to meeting |
| 2010-06-03 07:27:16 utc | lbt | jmettraux: yes, saved it as I went to bed last night |
| 2010-06-03 08:48:13 utc | jmettraux | back for five |
| 2010-06-03 08:52:30 utc | jmettraux | ACTION escapes to next meeting |
| 2010-06-03 10:33:23 utc | jmettraux | tosch_le: looking forward to suggestions about this participant list issue, ttyl ! |
| 2010-06-03 12:03:18 utc | tosch_le | jmettraux: what about { participant_name => options} with options = [ParticipantClass.to_s, options_hash] || 'inpa_participant_name' |
| 2010-06-03 12:03:36 utc | jmettraux | 'inpa_participant_name' ftw ! |
| 2010-06-03 12:03:46 utc | tosch_le | ;-p |
| 2010-06-03 12:04:05 utc | tosch_le | that's close to engine.context.plist.send(:get_list)['list'] |
| 2010-06-03 12:04:11 utc | jmettraux | but it has to be a list/array |
| 2010-06-03 12:04:19 utc | jmettraux | ah great |
| 2010-06-03 12:05:10 utc | tosch_le | it wraps the resources better than having the participant names within the same array as the participant class and options |
| 2010-06-03 12:05:15 utc | tosch_le | imho |
| 2010-06-03 12:07:28 utc | jmettraux | but order matters |
| 2010-06-03 12:07:39 utc | jmettraux | the catch all participant is last isn't it ? |
| 2010-06-03 12:09:05 utc | tosch_le | engine.context.plist.send(:get_list)['list'] returns an ordered array, doesn't it? |
| 2010-06-03 12:09:13 utc | jmettraux | yes |
| 2010-06-03 12:09:18 utc | jmettraux | IIRC |
| 2010-06-03 12:09:23 utc | tosch_le | the hash should be ordered in the same way, then |
| 2010-06-03 12:09:37 utc | jmettraux | there is no guarantee |
| 2010-06-03 12:09:50 utc | jmettraux | ruby 1.9 does it IIRC, but not ruby 1.8 |
| 2010-06-03 12:10:31 utc | tosch_le | just seen that: The order in which you traverse a hash by either key or value may seem arbitrary, and will generally not be in the insertion order. |
| 2010-06-03 12:10:53 utc | tosch_le | (from the ruby 1.8.4 docs) |
| 2010-06-03 12:10:57 utc | jmettraux | :) |
| 2010-06-03 12:11:11 utc | jmettraux | sorry, I thought you knew ;) |
| 2010-06-03 12:11:28 utc | tosch_le | never worried about that before |
| 2010-06-03 12:12:54 utc | tosch_le | ok, so having an array of arrays will be fine then, i suppose. |
| 2010-06-03 12:13:41 utc | tosch_le | i shall convert it into the hash form in rk trying hard to respect the order. |
| 2010-06-03 12:14:01 utc | tosch_le | does order matter in json? is suppose yes. |
| 2010-06-03 12:14:13 utc | jmettraux | yes |
| 2010-06-03 12:14:31 utc | jmettraux | but after deserialization, on 1.8, the order is lost |
| 2010-06-03 12:15:20 utc | jmettraux | { "links": ls, "list": [ ... ] } ? |
| 2010-06-03 12:16:13 utc | tosch_le | that would be inconsistent to the other resources in rk |
| 2010-06-03 12:17:12 utc | tosch_le | { "links": ls, "participants": { "alice": { "position": 0, "class": "StorageParticipant", "options": o1 } } } ? |
| 2010-06-03 12:17:24 utc | jmettraux | looks good |
| 2010-06-03 12:17:45 utc | tosch_le | just have to decide what to do with instanciated participants |
| 2010-06-03 12:17:49 utc | jmettraux | ACTION wishes he remembered better how the other resources get JSONified in ruote-kit |
| 2010-06-03 12:17:59 utc | jmettraux | 'inpa_...' is good |
| 2010-06-03 12:18:10 utc | jmettraux | there's isnt much more that can be done |
| 2010-06-03 12:19:39 utc | tosch_le | { "links": ls, "participants": { "alice": { "position": 0, "class": "StorageParticipant", "options": o1, "instanciated": false }, "bob": { "position": 1, "instanciated": true } } } |
| 2010-06-03 12:20:21 utc | tosch_le | since class and options aren't available then |
| 2010-06-03 12:20:42 utc | jmettraux | why the obssession with hashes ? JSON has arrays... Please explain me |
| 2010-06-03 12:21:40 utc | tosch_le | bad habit i suppose |
| 2010-06-03 12:22:03 utc | jmettraux | it's not an essential resource |
| 2010-06-03 12:23:18 utc | tosch_le | perhaps its that hashes are everywhere in rk's render_helpers.rb |
| 2010-06-03 12:23:31 utc | tosch_le | s/its/it's |
| 2010-06-03 12:23:42 utc | jmettraux | aaaaaaaaah |
| 2010-06-03 12:24:03 utc | tosch_le | every single resource gets a "links" section added |
| 2010-06-03 12:24:08 utc | jmettraux | [ regex, class, { opts } ] matches engine.register_participant 1 to 1 |
| 2010-06-03 12:24:21 utc | jmettraux | "links" is massively importantt |
| 2010-06-03 12:24:24 utc | jmettraux | important |
| 2010-06-03 12:24:32 utc | jmettraux | without it, no RESTfulness |
| 2010-06-03 12:25:22 utc | tosch_le | { "links": ls, "participants": { "alice": { "position": 0, "class": "StorageParticipant", "options": o1, "instanciated": false, "links": ls0 }, "bob": { "position": 1, "instanciated": true, "links": ls1 } } } would be the "natural" way in rk |
| 2010-06-03 12:26:11 utc | tosch_le | no, i'm wrong |
| 2010-06-03 12:27:33 utc | threetee | hi jmettraux |
| 2010-06-03 12:28:00 utc | jmettraux | threetee: hi, I'm about to reply to your email |
| 2010-06-03 12:28:01 utc | threetee | I knew you'd beat me to answering Asier's question on the google group :) |
| 2010-06-03 12:28:19 utc | threetee | cool, thanks! |
| 2010-06-03 12:28:51 utc | jmettraux | thanks for your answer, it's great |
| 2010-06-03 12:29:07 utc | tosch_le | it's more like { "links": ls, "participants": [ {"links": ls0, "regex": "^alice$", "class": "SP", "options": opts0, "instanciated": false }, {"links": ls1, "regex": "^bob$", "instanciated": true} ] } |
| 2010-06-03 12:29:38 utc | jmettraux | ok |
| 2010-06-03 12:32:13 utc | tosch_le | we could go for {"links":lss, "participants": [ {"links":ls, "participant":[regex, class, opts]} ]} which would be more in line with engine.register |
| 2010-06-03 12:32:52 utc | jmettraux | ok |
| 2010-06-03 12:32:57 utc | jmettraux | you're losing me |
| 2010-06-03 12:33:10 utc | jmettraux | I feel guilty, I should have looked at ruote-kit's work |
| 2010-06-03 12:33:35 utc | tosch_le | gna, it's ok. |
| 2010-06-03 12:34:31 utc | tosch_le | i'm just unsure how to design that as i have no emergent need for /participants |
| 2010-06-03 12:35:02 utc | jmettraux | me neither |
| 2010-06-03 12:35:24 utc | tosch_le | the first variant is more readable and therefore i have a slight preference for that |
| 2010-06-03 12:35:47 utc | tosch_le | it's more work to build the hash, though |
| 2010-06-03 12:35:55 utc | tosch_le | but i suppose that's ok. |
| 2010-06-03 12:54:56 utc | jmettraux | threetee: reply is out |
| 2010-06-03 12:59:41 utc | threetee | thanks |
| 2010-06-03 13:00:31 utc | threetee | I think that in my effort to simplify the code for posting to the group, I obscured some key details |
| 2010-06-03 13:00:32 utc | threetee | my fault |
| 2010-06-03 13:00:56 utc | jmettraux | does the answer help ? |
| 2010-06-03 13:01:14 utc | threetee | I think so |
| 2010-06-03 13:01:18 utc | threetee | need to fully digest it |
| 2010-06-03 13:01:26 utc | jmettraux | :) |
| 2010-06-03 13:01:51 utc | threetee | I moved my process definition from a constant in my model to a class method within my model |
| 2010-06-03 13:02:13 utc | jmettraux | Email.find(x) was executed as ruby was executing the code |
| 2010-06-03 13:02:19 utc | jmettraux | not when the process definition was running |
| 2010-06-03 13:02:40 utc | threetee | when it was a constant, yes, but if it's a method, shouldn't that be executed when I call it? |
| 2010-06-03 13:02:52 utc | threetee | so in the model I have: |
| 2010-06-03 13:02:56 utc | jmettraux | no |
| 2010-06-03 13:03:05 utc | threetee | def self.pdef_create_email |
| 2010-06-03 13:03:10 utc | threetee | then the pdef code |
| 2010-06-03 13:03:14 utc | jmettraux | x = Ruote.process_definition {} is calling process_definiton |
| 2010-06-03 13:03:47 utc | jmettraux | maybe it's better to ask your second "big question" via the mailing list ;) |
| 2010-06-03 13:03:57 utc | threetee | could be |
| 2010-06-03 13:04:38 utc | threetee | but you did answer my main question, which was how to access workitem fields |
| 2010-06-03 13:04:52 utc | threetee | I hadn't thought about creating a participant to do that |
| 2010-06-03 13:05:05 utc | jmettraux | process_definition is a method that when executed "generates" a ruote syntax tree |
| 2010-06-03 13:05:20 utc | jmettraux | so it's execute Email.find(x).begin_x at that point |
| 2010-06-03 13:06:10 utc | jmettraux | it's executed |
| 2010-06-03 13:06:27 utc | threetee | right, which is why I moved the process_definition call to a method, so I could call that method from my controllers at arbitrary times and have the code to generate the server list run each time I generate the process |
| 2010-06-03 13:06:49 utc | threetee | as a constant it will get cached with the model |
| 2010-06-03 13:07:12 utc | jmettraux | bound at execution time |
| 2010-06-03 13:07:24 utc | threetee | ah |
| 2010-06-03 13:07:39 utc | threetee | okay, I think I get it now |
| 2010-06-03 13:07:46 utc | jmettraux | :) |
| 2010-06-03 13:10:20 utc | threetee | time to work on updating some code, I'll post to the list once I get it worked out |
| 2010-06-03 13:10:26 utc | threetee | thanks for the quick response |
| 2010-06-03 13:10:30 utc | jmettraux | great |
| 2010-06-03 13:10:41 utc | jmettraux | thanks for helping out on the ml, much appreciated ! |
| 2010-06-03 13:11:43 utc | threetee | np |
| 2010-06-03 13:11:51 utc | threetee | I'm happy that I found a question I can answer :) |
| 2010-06-03 14:00:35 utc | jmettraux | tosch_le : let's discuss that further tomorrow |
| 2010-06-03 14:01:05 utc | jmettraux | I will have a look at /errors that could help me figure out this format issue |