*** tpb has joined #melange | 00:00 | |
*** lresende has joined #melange | 02:24 | |
*** mithro has joined #melange | 04:43 | |
*** ChanServ sets mode: +v mithro | 04:43 | |
*** sttwister has quit IRC | 05:44 | |
*** lresende has quit IRC | 05:46 | |
*** sttwister has joined #melange | 05:47 | |
*** sttwister has quit IRC | 05:52 | |
*** sttwister has joined #melange | 05:52 | |
*** dr__house has joined #melange | 06:11 | |
*** sttwister has quit IRC | 06:22 | |
*** sttwister has joined #melange | 06:23 | |
*** sttwister has quit IRC | 06:31 | |
*** sttwister has joined #melange | 06:31 | |
*** sttwister has quit IRC | 06:46 | |
*** sttwister has joined #melange | 06:47 | |
*** neo7 has joined #melange | 06:52 | |
*** sttwister has quit IRC | 06:53 | |
*** sttwister has joined #melange | 06:53 | |
*** sttwister has quit IRC | 07:15 | |
*** dr__house has quit IRC | 07:16 | |
*** sttwister has joined #melange | 07:18 | |
*** dr__house has joined #melange | 07:25 | |
*** sttwister has quit IRC | 07:35 | |
*** sttwister has joined #melange | 07:35 | |
*** dr__house` has joined #melange | 07:57 | |
*** dr__house has quit IRC | 07:57 | |
*** MatthewWilkes has joined #melange | 08:03 | |
*** sttwister has quit IRC | 08:21 | |
*** sttwister has joined #melange | 08:25 | |
*** dr__house` has quit IRC | 08:26 | |
*** sttwister has quit IRC | 08:34 | |
*** sttwister has joined #melange | 08:39 | |
*** Merio has joined #melange | 08:58 | |
*** ChanServ sets mode: +v Merio | 08:59 | |
Merio | sttwister: ping | 09:17 |
---|---|---|
sttwister | Merio: pong | 09:17 |
Merio | sttwister: so, I'm reading your latest changes to the wiki | 09:18 |
sttwister | ok cool | 09:19 |
Merio | about the web interface and the ajax api | 09:20 |
Merio | just to know, is there a technical reason to do this amount of roundtrips to the server? | 09:21 |
sttwister | well actually I was thinking about that and wanted to discuss it with you | 09:22 |
sttwister | all that data could be cached locally anyway as it won't change in a session | 09:23 |
sttwister | so I don't think that's a problem | 09:23 |
sttwister | what do you think ? | 09:23 |
Merio | Caching can be a PITA with browsers :) We can just make a single request at the beginning to gather all data needed by the interface | 09:24 |
sttwister | ok, I guess I could update that | 09:26 |
sttwister | I also would like to add a function to validate the parameters of a data provider, before sending the whole configuration to the server | 09:27 |
sttwister | it would be better for the user to report errors as soon as possible | 09:27 |
Merio | yes, it depends on your architecture whether to do this in Javascript or in Python | 09:27 |
Merio | I mean, you can send the whole configuration to the server, check for it and send an error message to the user | 09:28 |
Merio | This isn't too time consuming | 09:28 |
sttwister | well, I'll do that in Python | 09:28 |
Merio | You can also do that in Javascript, but then you're decoupling the architecture of the data providers... I guess the data provider itself knows what it wants | 09:28 |
sttwister | yes indeed that's my reasoning | 09:29 |
Merio | Furthermore if you do that in Javascript, just a guess, you would find issues with types | 09:29 |
sttwister | but I could also validate each data provider as it's configured (like a user registration from might instantly suggest that another email with that account is already registered) | 09:29 |
Merio | yes that's better | 09:30 |
Merio | It was actually what I was meaning, but I guess you need to send the whole configuration every time | 09:31 |
Merio | Since you're allowing loading of local jsons | 09:31 |
Merio | And then you need to check the whole configuration at once and raise the proper "red flags" :) | 09:32 |
sttwister | I guess it would be possible to send data only for a single data provider and save some traffic and complexity | 09:33 |
Merio | yes but then you need to do an exception on your interface if you're loading a whole json at once | 09:35 |
Merio | One thing is providing a "space" in the UI to display one error, another is saving another space for another method to display more than one error at once (possibly with links to the places to fix each error) | 09:35 |
sttwister | hmm | 09:36 |
sttwister | well, each error would be referenced by model and property name, right ? | 09:37 |
Merio | yes I guess so | 09:39 |
sttwister | arghh, I'm not sure of the exact details to implement this in JavaScript, but it seems more or less the same thing to me | 09:39 |
Merio | Maybe also by model only, but it's just a guessing, can't find a proper example in this very moment | 09:39 |
Merio | it's just a UI matte | 09:39 |
Merio | matter | 09:39 |
Merio | not really Javascript, you can do everything you want with the DOM | 09:39 |
Merio | Just you have to think about what to do in case of errors, what's the workflow you expect the user to do | 09:40 |
Merio | s/do/follow | 09:40 |
sttwister | well, I would expect the user to notice the big red text saying something is wrong right away :) | 09:41 |
sttwister | and fix it | 09:41 |
Merio | but what if there are errors in 30 properties of 10 models? | 09:42 |
sttwister | the user already knew about all errors when he wrote them | 09:43 |
Merio | You might want to have only a sort of red dot nearby each model to show there are errors inside, and then other red dots for each property with an error... and then when you click a suggestion on how to fix things | 09:43 |
sttwister | it's his fault if he didn't fix them on time on guess | 09:43 |
Merio | Maybe I'm just using a outdated json configuration in the repository, which has not been used in three months | 09:43 |
Merio | I would like some guidance on how to fix errors or to update the configuration | 09:44 |
Merio | It's not so complex to handle, it's just that it needs some thoughts before actually coding the UI | 09:44 |
sttwister | ok, well in that case, signaling each model, and then each property that are having errors sounds good enough to me | 09:45 |
Merio | yes, but for usability purposes you need to guide the user to fix things, because you know better what could go wrong and how to fix it. So you should either have a sort of shortcut to the model/property that needs fixing or the progressive red dots thingy I was telling you before | 09:47 |
Merio | Or something similar that you might want to do in place of those solutions | 09:47 |
Merio | But please keep in mind usability | 09:47 |
Merio | However you're now going to code the data providers so you might want to dig into the UI matter on some spare time | 09:48 |
sttwister | ok, will do | 09:48 |
Merio | I would suggest to draw some mockup just to have some ideas on it | 09:48 |
Merio | Even though you're going to do it in 14 days anyway | 09:49 |
sttwister | yep, I guess I'll do the mockups directly in HTML when the time comes | 09:49 |
sttwister | so, one thing I'm not sure about | 09:50 |
Merio | Yes but in that week we need to find time to sync more often or just post your progress somewhere during the week so I can check over it and give you some quick suggestions also by mail in the dev list if I can't find some time to do a proper meeting :) | 09:51 |
Merio | Yep tell me | 09:51 |
sttwister | you suggested making a single request at the beginning to gather data | 09:51 |
sttwister | would that really include all the information (i.e. all models with all properties AND all data providers) ? | 09:51 |
Merio | I think yes, I can't see any drawback. You can even avoid making any request at all, if you print the JSON with all these informations right into the django template that contains the data seeder UI | 09:53 |
sttwister | ok | 09:54 |
sttwister | and how would I go about the data providers? | 09:54 |
sttwister | 1. provide possible data providers for each property | 09:54 |
sttwister | for each model | 09:55 |
sttwister | 2. provide possible data providers for each property type, and then let JavaScript figure out what data providers are suitable for each property of each model | 09:55 |
Merio | It depends on what informations the Python end has and how you need your json configuration formatted to display UI properly | 09:56 |
Merio | I mean is there any loss of information on doing 2 over 1? | 09:57 |
Merio | Python knows better how to associate data providers with properties? | 09:57 |
sttwister | no, there isn't any loss of information, and would keep the json smaller | 09:58 |
sttwister | yes, that information is only known by Python and needs to be transmitted to the web UI somehow | 09:59 |
Merio | I mean | 10:00 |
Merio | Python knows that property "country" is a stringproperty | 10:01 |
Merio | so you can choose between 4 data providers: fixedstring, randomword, randomname, randomphrase | 10:01 |
Merio | for property "country" the correct data provider should be randomword from a list | 10:02 |
Merio | but this is not something that nor Python nor Javascript can guess | 10:03 |
Merio | both of them can only guess that if that property is a stringproperty than you have 4 data providers | 10:03 |
Merio | that means it's the same thing, so it's just a matter of the structure of the initial json to the WEB UI | 10:03 |
sttwister | hmm, I don't think there is such thing as a "correct" data provider | 10:03 |
sttwister | it really depends on the context and the purpose of seeding | 10:04 |
Merio | yes this is very truw | 10:04 |
Merio | true | 10:04 |
sttwister | maybe you want to generate test fixtures with faulty data | 10:04 |
Merio | for country it's just the most sensible, you may want to write some random string of characters to test something | 10:04 |
Merio | Yes perfectly | 10:04 |
Merio | But well it was just an example to say, it only affects the structure of the JSON | 10:05 |
sttwister | ok | 10:05 |
Merio | That means that you don't need to associate data providers for each property | 10:05 |
sttwister | so then I'll go with transmitting the data providers for each property type | 10:05 |
sttwister | and let the UI figure out the rest | 10:05 |
Merio | If you know that stringproperty has 4 data providers | 10:05 |
Merio | than you have a place in your json like "stringproperty": {"fixedstringprovider", etc} | 10:06 |
Merio | then it encounter a "stringproperty" and look for it in the "dataproviders" section of the json (for instance) | 10:06 |
Merio | and then you know the dataproviders, you avoid much duplication here | 10:06 |
sttwister | yep, that sounds good :) | 10:06 |
Merio | I think jlinq would help you a lot on this | 10:07 |
Merio | We already have it in our code base | 10:07 |
Merio | it helps querying over jsons | 10:07 |
Merio | http://www.hugoware.net/Projects/jLinq | 10:07 |
tpb | Title: jLinq - LINQ for JSON (at www.hugoware.net) | 10:07 |
Merio | you might find it useful to shrink some code while working on jsons | 10:08 |
sttwister | ok, I'll take a look at it | 10:08 |
sttwister | I have some catching up to do on the JavaScript part :P | 10:09 |
Merio | no problems about it :) | 10:09 |
sttwister | so, is there anything else we'd need to talk about ? | 10:13 |
Merio | I think not for the moment | 10:15 |
Merio | If you don't have anything else to ask/say | 10:15 |
Merio | It's fine with me, I'll take a look at your commits :) | 10:15 |
sttwister | nope, not really | 10:15 |
Merio | fine then, see you on gtalk and keep up the good work :) | 10:16 |
sttwister | see you :) | 10:20 |
sttwister | have fun at the conference ;) | 10:20 |
Merio | thank you very much ^__^ | 10:21 |
Merio | see you (don't forget meeting notes ;)) | 10:21 |
*** Merio has quit IRC | 10:24 | |
*** Leo___ has joined #melange | 11:21 | |
*** mithro has quit IRC | 12:00 | |
*** dr__house has joined #melange | 12:01 | |
*** Lennie has joined #melange | 12:31 | |
*** ChanServ sets mode: +o Lennie | 12:31 | |
*** sttwister has quit IRC | 13:08 | |
*** sttwister has joined #melange | 13:32 | |
*** Lennie has quit IRC | 13:35 | |
*** tansell-laptop has quit IRC | 14:34 | |
*** tansell-laptop has joined #melange | 14:35 | |
*** dreimark has quit IRC | 14:51 | |
*** dreimark has joined #melange | 14:51 | |
*** Leo___ has quit IRC | 15:05 | |
*** sttwister has quit IRC | 15:07 | |
*** MatthewWilkes has quit IRC | 16:39 | |
*** sttwister has joined #melange | 16:41 | |
*** SRabbelier has quit IRC | 17:18 | |
*** SRabbelier has joined #melange | 17:24 | |
*** ChanServ sets mode: +o SRabbelier | 17:24 | |
*** dhaun has joined #melange | 18:13 | |
*** sttwister has quit IRC | 18:40 | |
*** sttwister has joined #melange | 18:40 | |
*** thrain42 is now known as durin42 | 18:44 | |
*** dr__house has quit IRC | 19:08 | |
*** Merio has joined #melange | 20:29 | |
*** ChanServ sets mode: +v Merio | 20:29 | |
*** robbyoconnor has quit IRC | 20:52 | |
*** Merio has quit IRC | 20:55 | |
*** Merio has joined #melange | 20:57 | |
*** ChanServ sets mode: +v Merio | 20:57 | |
*** dhaun has quit IRC | 21:20 | |
*** EllenKo has joined #melange | 22:38 | |
*** EllenKo has quit IRC | 23:17 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!