| *** alga has quit IRC | 00:59 | |
| *** aks has joined #schooltool | 05:09 | |
| *** aks has joined #schooltool | 05:09 | |
| *** th1a has joined #schooltool | 06:13 | |
| *** th1a has quit IRC | 07:27 | |
| *** menesis has joined #schooltool | 08:55 | |
| *** alga has joined #schooltool | 09:30 | |
| *** yvl has quit IRC | 12:03 | |
| *** menesis has quit IRC | 12:12 | |
| *** yvl has joined #schooltool | 12:14 | |
| *** alga has quit IRC | 12:32 | |
| *** menesis has joined #schooltool | 13:08 | |
| *** alga has joined #schooltool | 14:05 | |
| *** aks has quit IRC | 14:21 | |
| *** replaceafill has joined #schooltool | 15:12 | |
| *** th1a has joined #schooltool | 15:28 | |
| yvl | good morning guys | 15:28 |
|---|---|---|
| yvl | I'm running a bit late today | 15:28 |
| yvl | if you could just give me 5 more minutes ;) | 15:28 |
| yvl | (to commit latest changes) | 15:28 |
| replaceafill | yvl the last change to the Makefile throws me an error on run | 15:29 |
| replaceafill | Traceback (most recent call last): | 15:29 |
| replaceafill | File "bin/start-schooltool-instance", line 154, in <module> | 15:29 |
| replaceafill | schooltool.paste.run.main() | 15:29 |
| replaceafill | File "/home/replaceafill/.sandboxes/flourish/src/schooltool/paste/run.py", line 100, in main | 15:29 |
| replaceafill | update_instance(instance_root) | 15:29 |
| replaceafill | File "/home/replaceafill/.sandboxes/flourish/src/schooltool/paste/run.py", line 60, in update_instance | 15:29 |
| yvl | yes | 15:29 |
| replaceafill | os.path.join(instance_root, 'paste.ini')) | 15:29 |
| replaceafill | OSError: [Errno 2] No such file or directory | 15:29 |
| replaceafill | ah ok :) | 15:29 |
| replaceafill | you're aware ;) | 15:29 |
| aelkner | replaceafill, i had that one before and fixed it by copying paste.ini from another sandbox | 15:31 |
| th1a | hi replaceafill, aelkner, yvl, menesis. | 15:31 |
| aelkner | morning | 15:31 |
| menesis | hu | 15:32 |
| menesis | hi | 15:32 |
| replaceafill | good morning/afternoon | 15:33 |
| th1a | OK, actually, I guess I can start while yvl is getting ready. | 15:34 |
| th1a | So the main agenda today is: | 15:34 |
| th1a | * yvl overview; | 15:34 |
| th1a | * replaceafill CSS discussion; | 15:34 |
| th1a | (that is, replaceafill doesn't have to lead it, but he's going to be the one doing it) | 15:35 |
| th1a | * initial strategies/tasks for everyone; | 15:35 |
| th1a | * (post-meeting) replaceafill and aelkner talking more jquery dialogs and accordions. | 15:36 |
| th1a | That should be more than enough. | 15:36 |
| th1a | Any initial questions or concerns? | 15:36 |
| aelkner | real quick | 15:37 |
| aelkner | you got my note about the hidden report sheets | 15:37 |
| th1a | Yes, let's talk about that later. I haven't really even looked at it closely tbh. | 15:38 |
| aelkner | can we get that merged and released in the short term to solve your friend's problem? | 15:38 |
| th1a | That's the idea. | 15:38 |
| th1a | So yes, later today we'll talk about it. | 15:38 |
| aelkner | ok | 15:38 |
| th1a | ... | 15:40 |
| th1a | replaceafill: So did you check out accordions last week? | 15:40 |
| replaceafill | yes | 15:40 |
| replaceafill | again, i don't like jquery ui accordions | 15:40 |
| th1a | Ah, why not? | 15:40 |
| replaceafill | because they only allow one open at the time | 15:40 |
| th1a | Oh... | 15:40 |
| replaceafill | but i found two ways of having multiple accordions open: a hack and a plugin | 15:41 |
| yvl | btw, meanwhile, please get the https://code.launchpad.net/~justas-pov/schooltool/flourish if you didn't already | 15:41 |
| replaceafill | yvl done | 15:41 |
| th1a | revision 2837? | 15:41 |
| th1a | replaceafill: tbh, we could even try the current implementation first. | 15:43 |
| replaceafill | th1a i think implementing accordions is really simple actually | 15:43 |
| replaceafill | i mean, our own accordions | 15:43 |
| replaceafill | you just toggle an element when you click another | 15:43 |
| th1a | I imagine. | 15:43 |
| replaceafill | http://jqueryui.com/demos/accordion/ even tells you that at the end | 15:44 |
| th1a | Why don't we just prototype with theirs first. | 15:44 |
| replaceafill | sure | 15:44 |
| th1a | OK. yvl ready? | 15:44 |
| yvl | coffee is almost done | 15:45 |
| th1a | replaceafill needs the coffee most. | 15:45 |
| replaceafill | i already had breakfast ;) | 15:45 |
| replaceafill | with coke, no coffee :P | 15:46 |
| th1a | At least it was good Coke made with sugar. | 15:46 |
| replaceafill | :)) | 15:46 |
| yvl | ready | 15:47 |
| yvl | so | 15:47 |
| yvl | there is a test layout in src/schooltool/skin/flourish/resources/test.html | 15:48 |
| yvl | it will be my visual aid today :) | 15:48 |
| yvl | well, where to begin... | 15:48 |
| th1a | How should I be viewing test.html? | 15:49 |
| th1a | Looking at the source? | 15:49 |
| yvl | open in browser | 15:49 |
| yvl | it should include necessary css | 15:49 |
| yvl | I think I sent you a screenshot of this recently | 15:49 |
| th1a | Got it. | 15:50 |
| yvl | there are several "sections" in this page | 15:50 |
| yvl | there's a top bar, basically a copy of our current top bar | 15:51 |
| th1a | But location aware. | 15:51 |
| th1a | Correct? | 15:51 |
| yvl | yes | 15:51 |
| yvl | the only real difference | 15:51 |
| yvl | thing is, that in many cases we'll need to specify this in zcml | 15:51 |
| yvl | for developers: | 15:51 |
| yvl | in the simplest case you can bind "active" location by context or layer | 15:52 |
| yvl | the adapters traverse context by "getParent" | 15:52 |
| yvl | so if you say, that looking at ISchoolToolApplication is "School" tabl | 15:53 |
| yvl | tab | 15:53 |
| yvl | all child objects are considered School | 15:53 |
| yvl | and if traversal gets into IGradebook, and you bind the active tab to IGradebook | 15:53 |
| yvl | all "childern" will show the Gradebook tab active | 15:54 |
| yvl | then there are breadcrumbs, obviously | 15:54 |
| yvl | going down... | 15:55 |
| th1a | Let's just move those into the red bar area now. | 15:55 |
| th1a | And perhaps change the color of the bar. | 15:55 |
| th1a | If necessary. | 15:55 |
| aelkner | yvl, is test.html intended to become a macro at some point? | 15:55 |
| yvl | not exactly | 15:55 |
| yvl | there are be page templates that are essentially contents of test.html | 15:56 |
| yvl | flourish/tempaltes/ : main.pt and page.pt | 15:56 |
| yvl | but I've opted to reduce amount of macros in SchoolTool | 15:56 |
| * replaceafill likes the idea of the content template :) | 15:57 | |
| yvl | in favor of content adapters | 15:57 |
| yvl | th1a, I'll do the breadcrumbs thing | 15:57 |
| th1a | kk | 15:58 |
| yvl | currently I didn't do the breadcrumbs themselves though :) | 15:58 |
| yvl | just the manager implementation with no breadcrumbs registered :) | 15:58 |
| th1a | Sure. | 15:58 |
| yvl | ok, so on to the page title | 15:58 |
| replaceafill | quick question: are the breadcrums also based on traversal | 15:58 |
| replaceafill | or containment | 15:58 |
| yvl | hmm | 15:59 |
| yvl | each breadcrumb knows it's parent | 15:59 |
| yvl | and is obtained by context, request, view | 15:59 |
| replaceafill | i mean, if you have schoolyear, term, section, will that show this hierarchy on the breadcrumb? | 16:00 |
| replaceafill | ah | 16:00 |
| yvl | by default - yes | 16:00 |
| replaceafill | ok, go on | 16:00 |
| yvl | but the implementation is a bit different than the rest of them in Zope | 16:00 |
| yvl | rationale - Vitor said the breadcrumbs should make sense for the user | 16:01 |
| yvl | and not by the actual hierarchy | 16:01 |
| replaceafill | right, that's why i'm asking :) | 16:01 |
| th1a | Yes. | 16:01 |
| yvl | resemble, yes, but not limited by it :) | 16:01 |
| th1a | That's partly why I got rid of them in the first place. | 16:01 |
| th1a | If it just tells you where you are in the database that might be more confusing than nothing. | 16:01 |
| yvl | true | 16:02 |
| th1a | Actually, I'd prefer not to get hung up on that implementation right now. | 16:02 |
| yvl | sure | 16:02 |
| th1a | Let's just agree that there will be breadcrumbs. | 16:02 |
| replaceafill | :) | 16:02 |
| th1a | That could even be implemented after the sprint if necessary. | 16:02 |
| yvl | all of the implementation is subject to change heavily at this point | 16:02 |
| th1a | So for now a placeholder is ok with me. | 16:02 |
| yvl | great :) | 16:02 |
| yvl | so, the title, subtitle and object navigation | 16:03 |
| yvl | basically, it works this way: | 16:03 |
| th1a | I'm anti-subtitle. | 16:03 |
| yvl | I imagine. | 16:03 |
| yvl | but let me advocate it a bit | 16:03 |
| th1a | OK. | 16:03 |
| yvl | so, the title is kind of obvious | 16:03 |
| yvl | objects have titles | 16:03 |
| * th1a is not convinced title is necessary here. | 16:04 | |
| yvl | apologies, I meant - "obvious what it does" | 16:04 |
| th1a | Let's assume it is there for now. | 16:04 |
| yvl | I just did it by guidelines | 16:04 |
| yvl | at the moment | 16:04 |
| th1a | We probably need it. | 16:04 |
| yvl | again - subject for discussion and change | 16:05 |
| yvl | the next thing is subtitle and navigation | 16:05 |
| yvl | these are mutually exclusive now | 16:05 |
| th1a | Ah, ok. | 16:05 |
| yvl | say, we are looking at a person | 16:05 |
| yvl | "tabbed" navigation over "contacts" "calendar" "overview" is kind of convenient there | 16:06 |
| yvl | but when we click action buttons, like.... | 16:06 |
| yvl | add person in person container | 16:06 |
| yvl | or edit person info in the person view | 16:06 |
| yvl | and we get to the actual forms | 16:06 |
| yvl | we have two options in my mind | 16:07 |
| yvl | 1) modal JS popup form | 16:07 |
| yvl | 2) non-modal page, without navigation, with subtitel | 16:07 |
| yvl | subtitle :) | 16:07 |
| yvl | John Smith | Edit personal information | 16:08 |
| th1a | It isn't clear to me what is going in Overview | Details | Stuff | Settings | 16:08 |
| aelkner | what is the subtitle? | 16:08 |
| yvl | aelkner: title is a title of the object; subtitle is a title of the page | 16:09 |
| yvl | th1a... | 16:09 |
| yvl | Overview | Details | Stuff works like tabs | 16:09 |
| yvl | when you press Overview, you get to the, well, person index.html | 16:10 |
| yvl | another button could be Contacts | 16:10 |
| yvl | of a person | 16:10 |
| yvl | Contacts are a "property" of a "person" object | 16:11 |
| aelkner | yvl, i branched and did a make on your flourish branch, should i be able to do make run? | 16:11 |
| yvl | in the eyes of the user | 16:11 |
| th1a | OK. Let's make those look like Ubuntu navigation bars. | 16:11 |
| yvl | aelkner, yes | 16:11 |
| aelkner | i get a not found page at app root | 16:11 |
| replaceafill | could they be like secondary navigation in the guidelines? | 16:11 |
| th1a | replaceafill: Yes. | 16:11 |
| yvl | hmm | 16:12 |
| yvl | gimme a moment to look at guidelines again :) | 16:12 |
| replaceafill | page 7 | 16:12 |
| th1a | p. 19 | 16:12 |
| th1a | ? | 16:12 |
| replaceafill | well, page 7 is the complete layout :) | 16:12 |
| * replaceafill goes to page 19 | 16:12 | |
| th1a | & 20. | 16:12 |
| replaceafill | ah yes, more detail there ;) | 16:12 |
| * yvl is trying to remember why it wasn't done by Ubuntu guidelines | 16:12 | |
| th1a | Takes up more vertical space. | 16:13 |
| replaceafill | maybe because of the login bar and breadcrumbs space? | 16:13 |
| yvl | ah, now I remember | 16:13 |
| th1a | Probably we'll compress all that vertically somewhat. | 16:13 |
| yvl | the reasons: | 16:13 |
| yvl | 1) vertical space | 16:13 |
| th1a | We may need a netbook layer ;-). | 16:14 |
| yvl | 2) top bar is taken by breadcrumbs | 16:14 |
| yvl | 3) there are action buttons on top of content | 16:14 |
| yvl | this was actually the result of merging Vitors work with Ubuntu guildelines | 16:14 |
| yvl | so this concept comes from Vitor's mockups | 16:15 |
| th1a | There shouldn't be any other buttons on top of content after this navigation. | 16:15 |
| th1a | And I think in most cases this bar won't be there at all. | 16:15 |
| th1a | e.g., for persons we'll use accordions instead. | 16:16 |
| yvl | ? | 16:16 |
| yvl | I mean - well, ok | 16:16 |
| th1a | And things like settings I'd prefer that to be in the side. | 16:16 |
| th1a | Basically instead of tabbing through views you'll switch content in the accordion. | 16:17 |
| yvl | interesting thought! | 16:17 |
| th1a | Of course, that may actually suck and we won't use it, but I'd like to try that first. | 16:17 |
| th1a | Partly it just breaks us out of the "piles of tabs" issue. | 16:18 |
| replaceafill | let's use the "contacts" example, you can have like "n" contacts in the accordion, but you need a button to go "manage" contacts for the person | 16:18 |
| yvl | personally, I don't see a piles of tabs issue ;) | 16:18 |
| yvl | just FYI | 16:18 |
| th1a | Two levels of tabby navigation is manageable. | 16:19 |
| aelkner | yvl, i was hoping to see test.html rendered in the browser since we are discussing it | 16:19 |
| th1a | replaceafill, Yes. | 16:19 |
| aelkner | how would i do that? | 16:19 |
| th1a | Mine is at file:///home/hoffman/Desktop/flourish/src/schooltool/skin/flourish/resources/test.html | 16:19 |
| replaceafill | aelkner just poing your browser to file:///home/replaceafill/.sandboxes/flourish/src/schooltool/skin/flourish/resources/test.html | 16:19 |
| yvl | mine is file:///home/justas/src/schooltool/schooltool_flourish/src/schooltool/skin/flourish/resources/test.html ;) | 16:20 |
| replaceafill | :)) | 16:20 |
| aelkner | oh, the file not a running server | 16:20 |
| yvl | yes :) | 16:20 |
| th1a | So in your example, those content sections would be in accordions. | 16:20 |
| yvl | I'm thinking... | 16:21 |
| yvl | it is very likely | 16:21 |
| yvl | can we take a 3 min break? | 16:21 |
| yvl | I'd like to think about this a little bit | 16:21 |
| th1a | lol... yes. | 16:21 |
| yvl | It is a very interesting idea | 16:21 |
| aelkner | 'thinking' one puff at a time :) | 16:21 |
| yvl | (especially for netbooks) | 16:21 |
| th1a | Note that we won't be slapping accordions everywhere. | 16:21 |
| yvl | yes :D | 16:21 |
| th1a | I'll talk to replaceafill. | 16:22 |
| th1a | I think I want you to just do buttons first. | 16:22 |
| th1a | Hm... the Ubuntu ones have gradient backgrounds. | 16:23 |
| replaceafill | it's an image i think | 16:23 |
| replaceafill | because of the "background-image: orange" rule | 16:23 |
| th1a | eh? | 16:23 |
| replaceafill | page 23 | 16:24 |
| replaceafill | last paragraph | 16:24 |
| replaceafill | i have a related question here: | 16:25 |
| replaceafill | i think css3 defines styles for gradients | 16:25 |
| th1a | sprites? | 16:25 |
| replaceafill | but not all browsers support it | 16:25 |
| replaceafill | http://webdesignerwall.com/tutorials/css3-gradient-buttons | 16:26 |
| th1a | One good thing about this is we can always look at ubuntu.com for clarification. | 16:26 |
| replaceafill | see the .button class defined there | 16:26 |
| replaceafill | true | 16:26 |
| * yvl back | 16:27 | |
| replaceafill | transparent url(images/topnav_divider.png) no-repeat scroll right top !important | 16:27 |
| aelkner | replaceafill, hugh? | 16:28 |
| yvl | it's a CSS rule | 16:28 |
| th1a | We may have to get used to replaceafill lapsing into talking CSS. | 16:28 |
| aelkner | :) | 16:28 |
| th1a | It is a side effect. | 16:28 |
| replaceafill | sorry :D | 16:28 |
| yvl | looks like one from top header | 16:28 |
| yvl | IIRC | 16:29 |
| yvl | the topmost tabbed one | 16:29 |
| replaceafill | i'll come back ot the css3 browser support question later | 16:29 |
| th1a | y | 16:29 |
| th1a | yvl? | 16:29 |
| yvl | th1a, I think the accordion thing is really worth trying out | 16:29 |
| yvl | at least in some places | 16:30 |
| yvl | like person :) | 16:30 |
| th1a | Yes. | 16:30 |
| yvl | ok, let's move on for now | 16:30 |
| yvl | so, the things we discussed so far are common for all pages | 16:31 |
| yvl | this is what every SchoolTool page will have | 16:31 |
| yvl | oh, and the footer of course | 16:31 |
| yvl | then comes the second part | 16:32 |
| yvl | in code it is put to another template | 16:32 |
| yvl | page.pt | 16:32 |
| yvl | (and page_extended.pt) | 16:32 |
| yvl | first, let's go over page.pt - it mimics the test.html | 16:32 |
| yvl | there are 3 vertical "columns", their widths taken from the guidelines | 16:33 |
| yvl | in the center you have the "content template" | 16:33 |
| yvl | that is the main content of your page | 16:33 |
| yvl | like - if you're looking at a gradebook it will take up the "Main Page Content Here" place | 16:34 |
| yvl | then, there's additional content | 16:34 |
| yvl | it will not apply to gradebook (likely) | 16:34 |
| yvl | but it is for pages like Person | 16:34 |
| yvl | you can add many "additional" blocks of content | 16:35 |
| yvl | say, in our person pages we have... | 16:35 |
| yvl | PersonInfo viewlet manager if memory serves me well | 16:35 |
| yvl | we add courses there | 16:35 |
| yvl | we add groups there | 16:35 |
| yvl | and so on | 16:35 |
| yvl | each of those, at the moment (!) | 16:36 |
| yvl | have their action buttons | 16:36 |
| yvl | umm, may have their action buttons | 16:36 |
| yvl | it looks quite nice in some places | 16:36 |
| yvl | like add event in calendar | 16:36 |
| th1a | We pretty much don't want to think "action buttons" at all anymore. | 16:37 |
| yvl | I'm not sure if we're going to end up with more than few of them | 16:37 |
| yvl | can you pick another name? | 16:37 |
| yvl | these (in my head) are for modifying contents of the block in some way | 16:37 |
| th1a | I think one key distinction is between "static" and "dynamic" actions. | 16:37 |
| * replaceafill wonders if those "action" buttons should be inserted into the rounded block of the content... | 16:38 | |
| th1a | replaceafill: yes. | 16:38 |
| yvl | replaceafill - I've no idea | 16:38 |
| yvl | maybe! | 16:38 |
| replaceafill | i mean to make clear to which block they apply | 16:38 |
| th1a | Static actions are integral to the body of the page. | 16:38 |
| th1a | They should *usually* just be integrated with the content. | 16:38 |
| th1a | In the main body. | 16:39 |
| yvl | hmm, I'm not sure I understand you | 16:39 |
| yvl | oh | 16:39 |
| yvl | hmm | 16:39 |
| th1a | They don't need to go at the top or side. | 16:40 |
| th1a | We can just design the page to be usable. | 16:40 |
| th1a | They might go at the side, or perhaps even as navigation. | 16:40 |
| yvl | right | 16:40 |
| th1a | Maybe *usually* is too strong. | 16:40 |
| th1a | We should always consider that they can go right in the body. | 16:40 |
| yvl | of course! | 16:41 |
| th1a | And go ahead and put them there as appropriate. | 16:41 |
| th1a | We've just chucked things into action buttons by default, which is bad. | 16:41 |
| * yvl agrees | 16:41 | |
| yvl | my guess is that there will be few buttons that could go at the top | 16:41 |
| yvl | I kind of like Launchpad's edit icon | 16:42 |
| th1a | Right. | 16:42 |
| aelkner | so when we talk about action buttons, we are thinking changing them to local context buttons, right? | 16:42 |
| aelkner | or buttons close to the thing being acted upon | 16:42 |
| th1a | Basically, hardcoded in the page. | 16:42 |
| th1a | There are essentially three places they can be put. | 16:42 |
| yvl | yes | 16:42 |
| th1a | They can be one of a small number of navigation style tabs at top. | 16:42 |
| th1a | 2) They can be embedded in the body of the page. | 16:43 |
| th1a | 3) They can go in the sidebar. | 16:43 |
| yvl | nice! | 16:43 |
| th1a | And then the "dynamic" buttons will be links in the sidebar. | 16:43 |
| th1a | The ones added programatically later. | 16:43 |
| yvl | just a minor note, if I may | 16:44 |
| th1a | Also the busy, cluttery parts. | 16:44 |
| yvl | I think it is acceptable for some modules to add buttons where they may | 16:44 |
| yvl | I am basically thinking CanDo, Cambodia and, well, gradebook | 16:44 |
| yvl | or calendars | 16:44 |
| th1a | Where they may? | 16:45 |
| yvl | "if it really makes sense" | 16:45 |
| yvl | "if it really really makes sense" | 16:45 |
| th1a | Where they may to their own views or others? | 16:45 |
| yvl | everywhere | 16:45 |
| yvl | in some cases you do need to remove stuff | 16:46 |
| yvl | or replace | 16:46 |
| yvl | but that should be a serious exception | 16:46 |
| yvl | the way I see it | 16:46 |
| yvl | if you need to add something, you can add as "additional content" for the page | 16:47 |
| th1a | I guess I'm saying that the main view should have the minimum of dependencies on other components, and if other components are adding actions, they'll fall in the side. | 16:47 |
| th1a | Well, perhaps we'll come up with a way to add an accordion section, too. | 16:47 |
| yvl | I think we are trying to say the same thing ;) | 16:47 |
| th1a | That's a good trick. | 16:47 |
| yvl | ok, so moving on to other 2 columns | 16:48 |
| yvl | the left on is called "refine" at the moment | 16:48 |
| yvl | though it's not as accurate as I'd like | 16:48 |
| yvl | same as the center column, plugins or modules can add content boxes there | 16:49 |
| yvl | the purpose is both navigation and filtering | 16:49 |
| th1a | So are those viewlets? | 16:49 |
| yvl | say, we're looking at a section | 16:49 |
| yvl | yes, th1a | 16:49 |
| yvl | almost everything is :D | 16:49 |
| replaceafill | content providers ;) | 16:50 |
| yvl | yes | 16:50 |
| aelkner | making it flexible | 16:50 |
| yvl | trying to :) | 16:50 |
| yvl | so, we're looking at a section | 16:50 |
| yvl | there could be a box "terms" | 16:50 |
| yvl | dealing with the thing that section can span multiple terms | 16:51 |
| yvl | umm, sorry | 16:51 |
| yvl | kind of lost my thought here | 16:51 |
| th1a | So on one hand, every page needs a bag o' links space at left. | 16:51 |
| yvl | yes | 16:52 |
| th1a | Where arbitrary future components can add links. | 16:52 |
| aelkner | except the gradebook, right? | 16:52 |
| yvl | why not the gradebook? | 16:52 |
| th1a | And then each object wants to be able to add additional viewlets | 16:52 |
| th1a | aelkner, To be decided. | 16:52 |
| aelkner | gradebook needs horizontal space | 16:52 |
| th1a | that are relevant to its particular navigational issues. | 16:52 |
| th1a | We'll see about the gradebook. | 16:53 |
| yvl | th1a, yes | 16:53 |
| th1a | aelkner: Probably. | 16:53 |
| yvl | another example: calendar | 16:53 |
| yvl | it can have, say, three boxes | 16:53 |
| yvl | 1) type of calendar: weekly/monthly/yearly | 16:53 |
| yvl | 2) overalyed calendars / visible calendars | 16:54 |
| yvl | 3) quick-nav, i.e. jump to year currently, could be replaced with jump to date (input box) | 16:54 |
| replaceafill | yvl, is it possible to insert "non-refine" content there? | 16:55 |
| yvl | yes | 16:55 |
| replaceafill | like a little calendar or something | 16:55 |
| replaceafill | ah ok | 16:55 |
| yvl | but! | 16:55 |
| th1a | Perhaps the first viewlet in that column should always be called "Links" to remind us that it is the dynamic navigation part. | 16:55 |
| yvl | a litle calendar should go on the right | 16:55 |
| aelkner | explain refine and non-refine please | 16:56 |
| replaceafill | yvl ah! | 16:56 |
| aelkner | i don't tink non-refine is a valid english concept | 16:56 |
| yvl | it is a name, aelkner | 16:56 |
| th1a | So that's how you get to Interventions or Grades for a individual student. | 16:56 |
| yvl | it should probably be change to navigation | 16:56 |
| yvl | just... better name than navigation | 16:56 |
| th1a | Links. | 16:57 |
| aelkner | related links? | 16:57 |
| yvl | well | 16:57 |
| yvl | say, we have resources | 16:57 |
| th1a | Actually, here's a key distinction. | 16:57 |
| yvl | that's another interesting case | 16:57 |
| yvl | yes, th1a ? | 16:57 |
| th1a | The difference between the way a person and their contacts are handled verses the way persons and their grades are. | 16:58 |
| th1a | Persons and contacts are tightly bound, you don't leave your context to view them. | 16:58 |
| th1a | But you follow a link to the gradebook view for the person. | 16:58 |
| th1a | We don't embed more than, at most, a summary. | 16:58 |
| yvl | a good example | 16:58 |
| th1a | But I don't want to be adding "Gradebook" to the second level navigation as a tab. | 16:59 |
| th1a | Gradebook shouldn't appear on both first and second level navigation! | 16:59 |
| yvl | th1a, thank you - you reminded of another example | 17:00 |
| yvl | say, we're looking at a person | 17:00 |
| yvl | one of the boxes at the right can be titled "Gradebook" | 17:00 |
| th1a | Actually, maybe the link bag's title should be the possessive form of the object's title. | 17:00 |
| th1a | Alan Elkner's... | 17:01 |
| yvl | with links to all his gradebooks - math, literature, etc. | 17:01 |
| th1a | - grades | 17:01 |
| th1a | etc... | 17:01 |
| yvl | +1 | 17:01 |
| yvl | no, +2 | 17:01 |
| th1a | tbh, let's start without a right sidebar and only add it if we really run out of space at left. | 17:01 |
| yvl | also, the boxes can be very dynamioc in some cases | 17:02 |
| yvl | say, we are looking at "Manage School" thing | 17:02 |
| yvl | on one hand, there are things global to the school | 17:02 |
| yvl | at the moment - all persons, all contacts, schoolyears | 17:02 |
| yvl | another box could be links for 2011 - the active year | 17:03 |
| yvl | courses, sections | 17:03 |
| yvl | and some hand-picked groups | 17:03 |
| yvl | teachers, students | 17:03 |
| th1a | Yes, the complex objects need more complex customized views. | 17:03 |
| th1a | Using multiple columns in the body, etc. | 17:03 |
| th1a | I'm considering that post-sprint work. | 17:03 |
| yvl | sure | 17:04 |
| yvl | but I was talking about the right column | 17:04 |
| yvl | it is not necessary only the links for the object | 17:04 |
| yvl | it may be reasonable links by context | 17:04 |
| yvl | like - active schoolyear | 17:04 |
| th1a | Let's just table the right sidebar for now. | 17:04 |
| yvl | ok | 17:04 |
| yvl | finally, there's the right column, I called it "detail" in the code | 17:05 |
| yvl | it has some useful cases | 17:05 |
| yvl | for one - two small calendars look really in place for the calendar view | 17:05 |
| yvl | if you recall, currently they are on the left in ST | 17:05 |
| yvl | if they go on the right, the view becomes way cleanre to look at | 17:05 |
| yvl | another useful scenario | 17:06 |
| yvl | if you add a term, and put a box with school year 2011 start/end dates | 17:06 |
| yvl | it draws attention to the eye | 17:06 |
| yvl | it's not necessary, but it just looked more... | 17:06 |
| yvl | obvious when I expermiented | 17:06 |
| aelkner | help the user learn? | 17:06 |
| yvl | (than putting the same line in the page) | 17:06 |
| yvl | oh, sorry, I remember | 17:07 |
| yvl | it's called "related" in the code | 17:07 |
| yvl | yes, help the user learn :) | 17:07 |
| yvl | it's basically a place for non-vital related information | 17:07 |
| yvl | summary of stuff | 17:07 |
| th1a | I'm anti-box in these sidebars, by the way. I'd go for a look like the Ubuntu footer. | 17:07 |
| yvl | hmm | 17:08 |
| yvl | interesting | 17:08 |
| yvl | frankly, I've never considered putting such information at the bottom | 17:09 |
| yvl | I'm just not used to seeing anything there | 17:09 |
| th1a | No... I just mean style wise. | 17:09 |
| yvl | as in | 17:09 |
| yvl | I'm used to facebook's style | 17:09 |
| aelkner | problem with footers is user doesn't see it if main content is long | 17:10 |
| th1a | I just mean lines. | 17:10 |
| th1a | Design. | 17:10 |
| yvl | oh! | 17:10 |
| yvl | right :) | 17:10 |
| aelkner | it's one thing to put copywrite | 17:10 |
| yvl | then - yes, please! | 17:10 |
| aelkner | or register bugs links | 17:10 |
| th1a | I'm just talking style, aelkner. | 17:10 |
| aelkner | oh sorry, ust css | 17:11 |
| yvl | boxes were... the first obvious choice to keep myself reminded that these are separate viewlets | 17:11 |
| yvl | it's a developer thing ;) | 17:11 |
| th1a | Sure. | 17:11 |
| yvl | this is the type of thing the design company will probably adress | 17:12 |
| yvl | address | 17:12 |
| th1a | Incidentally, I was just thinking about making the footer a one line static footer locked to the bottom of the window. | 17:12 |
| aelkner | ooh | 17:12 |
| th1a | Well... to a degree, but we should start with the Ubuntu consistent way. | 17:12 |
| aelkner | an acordian? | 17:12 |
| yvl | hmm, if I understood you correctly, then -1 | 17:13 |
| th1a | No... | 17:13 |
| yvl | you meant always visible, right? | 17:13 |
| th1a | This is just a brainstorm. | 17:13 |
| th1a | Yes. | 17:13 |
| replaceafill | if we think netbookwise, -1 | 17:13 |
| aelkner | yes, th1a meant that, but i thought it could open up with more info | 17:13 |
| th1a | You could hide it. | 17:13 |
| aelkner | if the user clicked it | 17:14 |
| yvl | +1 for such thing in devmode, -1 for user mode | 17:14 |
| aelkner | or hide it, too | 17:14 |
| th1a | I'm just thinking that sometimes it is way too prominent because we have very short forms. | 17:14 |
| yvl | oh! | 17:14 |
| aelkner | yes, good point | 17:14 |
| yvl | I am sorry about that | 17:14 |
| yvl | I don't know a way to get around this | 17:15 |
| yvl | a clean way, that is | 17:15 |
| th1a | Anyhow, that's just a brainstorm. | 17:15 |
| th1a | Let's move on for now. | 17:15 |
| yvl | but it was a good point, th1a | 17:15 |
| aelkner | doesn't css allow locking divs relative to browser position? | 17:15 |
| yvl | with the short forms | 17:15 |
| yvl | as far as I'm aware - 90% of the worlds web developers are annoyed at this :) | 17:16 |
| yvl | "if the content is too short vertically, just fill the page!" | 17:16 |
| yvl | right | 17:16 |
| yvl | maybe in CSS4 ;) | 17:16 |
| th1a | OK, moving on. | 17:17 |
| yvl | yes | 17:17 |
| yvl | well, so that's that with the layout | 17:17 |
| th1a | yvl: What do you think you should do next? | 17:17 |
| yvl | take a small break :D | 17:17 |
| yvl | more seriously though | 17:17 |
| yvl | one of the things is to chat about the code changes | 17:18 |
| yvl | then | 17:18 |
| th1a | Oh, right. | 17:18 |
| yvl | hmm | 17:18 |
| yvl | you know, let's take a break | 17:18 |
| yvl | some code speak will be probably next | 17:18 |
| th1a | OK. | 17:18 |
| th1a | 10 minute break. | 17:19 |
| yvl | ok | 17:19 |
| replaceafill | th1a this is what i meant before about gradients in ubuntu.com, for example: http://www.ubuntu.com/download/ubuntu/download uses: | 17:24 |
| replaceafill | http://www.ubuntu.com/sites/default/themes/ubuntu10/images/btn-download-bg.png | 17:24 |
| replaceafill | http://www.ubuntu.com/sites/default/themes/ubuntu10/images/btn-download-hover-bg.png | 17:24 |
| replaceafill | http://www.ubuntu.com/sites/default/themes/ubuntu10/images/btn-download-active-bg.png | 17:24 |
| replaceafill | for the Download button | 17:25 |
| replaceafill | sorry, "Start download" button | 17:25 |
| th1a | Are those gradients? | 17:25 |
| replaceafill | just background images | 17:26 |
| replaceafill | with gradient effect | 17:26 |
| th1a | OK. Good. | 17:26 |
| th1a | OK, that's ten minutes. | 17:28 |
| th1a | Breaks are stricter when they're timestamped. | 17:28 |
| replaceafill | :D | 17:28 |
| yvl | :) | 17:30 |
| yvl | true | 17:30 |
| yvl | ok | 17:30 |
| yvl | so, some codespeek | 17:30 |
| th1a | Yes. | 17:30 |
| yvl | there are few concepts that will be "heavily" used from now on | 17:30 |
| yvl | content providers, viewlets/managers and zc.resourcelibrary :) | 17:30 |
| yvl | first, the easiest part, the resources | 17:31 |
| yvl | if you looked at skin/flourish/configure.zcml , | 17:31 |
| yvl | there is a resourceLibrary directive for static resources | 17:31 |
| yvl | all libraries have their unique names | 17:32 |
| yvl | dependencies | 17:32 |
| yvl | and files they include | 17:32 |
| yvl | one module can have multiple libraries | 17:32 |
| yvl | now, the good part | 17:32 |
| yvl | <tal:block replace="resource_library:schooltool.skin.flourish" /> | 17:33 |
| yvl | and the library is | 17:33 |
| yvl | <zope:resourceLibrary | 17:34 |
| yvl | name="schooltool.skin.flourish" | 17:34 |
| yvl | require="" > | 17:34 |
| yvl | <directory | 17:34 |
| yvl | source="resources" | 17:34 |
| yvl | include="flourish.css | 17:34 |
| yvl | </zope:resourceLibrary> | 17:34 |
| yvl | this way you should write css and javascript your pages need | 17:34 |
| yvl | say, calendar needs it's own grid and event css | 17:34 |
| yvl | also, some js | 17:35 |
| yvl | there should be a respective library for that | 17:35 |
| yvl | and all views should have the resource_library: directives | 17:35 |
| yvl | it tells the internal machinery that template is dependent on the library, and library includes are render *after* the page is rendered | 17:36 |
| yvl | so if you want to add some box with a little calendar to a person view | 17:36 |
| yvl | you can do it by rendering the viewlet | 17:36 |
| yvl | and since it's template knows the css library it needs | 17:36 |
| yvl | the library will be added | 17:37 |
| replaceafill | question here: | 17:37 |
| yvl | the require pare of the zcml directive describes libraries that *must* be rendered before | 17:37 |
| replaceafill | ah! | 17:37 |
| replaceafill | that was my question :D | 17:37 |
| yvl | so that solves the ordering | 17:38 |
| replaceafill | ok, new question | 17:38 |
| replaceafill | in cases where the .js file depends on information of the view class, | 17:38 |
| replaceafill | should we still use "html_head" to insert those | 17:38 |
| replaceafill | or does this "require" functionality could handle that?/ | 17:39 |
| yvl | I would prefer not to use html_head | 17:39 |
| yvl | there are few ways to do this | 17:39 |
| * replaceafill is ashame of his english... "does... could" | 17:39 | |
| yvl | :D | 17:39 |
| replaceafill | i mean, the gradebook's js depends a lot on the view class | 17:39 |
| yvl | first, it is ok to render some script in the view itself | 17:40 |
| yvl | second, the tal directive is derived from tal's string: directive | 17:40 |
| yvl | so you can <tal:block replace="resource_library:${view/stuff}" /> | 17:40 |
| yvl | and you can pick respective library | 17:41 |
| yvl | those two should cover most of the cases | 17:41 |
| yvl | as for the language-dependent JS... | 17:41 |
| yvl | frankly, I haven't decided on that one | 17:41 |
| th1a | Are you following this, aelkner? | 17:42 |
| aelkner | i'm struggling to catch up | 17:42 |
| aelkner | but i get the idea of js and css being linked to the view | 17:42 |
| aelkner | this last part about the tal:block? | 17:43 |
| yvl | ok | 17:43 |
| yvl | let me grep for an example | 17:44 |
| aelkner | i was going to say that examples are the way for me to grok it | 17:44 |
| aelkner | for instance, above flourish.css sonds like a global thing, so i'm confused by that | 17:44 |
| yvl | ah, ok | 17:45 |
| aelkner | two examples starts a trend :) | 17:45 |
| yvl | say, you defined a library in ZCML | 17:46 |
| yvl | and named it "schooltool.skin.flourish" | 17:46 |
| yvl | it becomes a global thing | 17:46 |
| yvl | now in any template you can say that you need these resources so that it would be displayed correctly in the browser | 17:46 |
| yvl | the last part is for very rare cases | 17:47 |
| yvl | say, you do not know the name of the library in advance | 17:47 |
| yvl | and want to calculate it | 17:47 |
| yvl | schooltool.calendar-weekly, schooltool.calendar-daily | 17:47 |
| yvl | this is a very rare case! | 17:48 |
| yvl | if you looked at table/templates/batch.pt | 17:48 |
| yvl | and searched for string: | 17:48 |
| yvl | you can find: | 17:48 |
| yvl | <a tal:attributes="href string:${view/base_url}?batch_size${view/name}=10" | 17:48 |
| yvl | here, | 17:49 |
| yvl | href is calculated as a string | 17:49 |
| yvl | ${} parts are inserted into the whole string | 17:49 |
| yvl | you can do the same with library names | 17:49 |
| yvl | <tal:block replace="resource_library:datewidget_${view/language}" /> | 17:50 |
| yvl | but the usual scenario is simpler | 17:50 |
| yvl | not all of the gradebook views need the "grid" css | 17:50 |
| yvl | hence that css should be included in some of the views | 17:51 |
| yvl | you need to define "schooltool.gradebook-tabbed-grid" library in zcml | 17:51 |
| yvl | and include only necessary CSS files | 17:51 |
| aelkner | i follow that | 17:51 |
| yvl | and then, in the views, you add the resource_library: thing | 17:51 |
| yvl | cool | 17:51 |
| yvl | so that is it actually | 17:52 |
| yvl | oh | 17:52 |
| aelkner | so you covered the 'first, the easiest part' from above | 17:52 |
| yvl | you can also specify the needed library in python | 17:52 |
| yvl | zc.resourcelibrary.need('schooltool.gradebook-tabbed-grid') | 17:52 |
| yvl | say, in update or render method | 17:52 |
| aelkner | how about at lcass level? | 17:53 |
| aelkner | class | 17:53 |
| aelkner | like fields or something | 17:53 |
| yvl | no, it needs to be in a method | 17:53 |
| * replaceafill haven't really understood the "need()" call | 17:53 | |
| replaceafill | what does it do? | 17:53 |
| aelkner | i mean, we say template= or fields= at class level as it is | 17:53 |
| yvl | it's a same as resource_library: directive | 17:53 |
| yvl | good point, aelkner | 17:54 |
| replaceafill | yvl get's you the appropriate "url" for it? | 17:54 |
| yvl | yes I do? ;) | 17:54 |
| yvl | I mean yes, it does | 17:54 |
| yvl | zcml registers the resources | 17:54 |
| yvl | the name of the library is just a shorthand | 17:55 |
| yvl | but it is unique to your application | 17:55 |
| yvl | hence it's good to use long names, like "schooltool.gradebook-gradebook-tabs" | 17:55 |
| yvl | currently I'd prefer all dependencies to be declared in .pt files | 17:56 |
| yvl | they themselves need the CSS after all | 17:56 |
| *** alga has quit IRC | 17:56 | |
| aelkner | yeah, good point | 17:56 |
| yvl | ok, so let's move on? | 17:57 |
| aelkner | the less needless switching back and forth from pt to py the better | 17:57 |
| yvl | +1 ;) | 17:57 |
| yvl | so, next are the content providers | 17:57 |
| yvl | you may have seen some of the code already | 17:58 |
| yvl | basically, it is a named adapter on context, request and view | 17:58 |
| replaceafill | i have a Lazy question :) | 17:58 |
| yvl | go ahead | 17:59 |
| replaceafill | once you told me we shouldn't use Lazy because it behaves strange in the debugger | 17:59 |
| replaceafill | remember? | 17:59 |
| yvl | yes | 17:59 |
| replaceafill | can you describe what it does? | 17:59 |
| aelkner | why do you ask? | 17:59 |
| aelkner | what code are you looking at? | 17:59 |
| yvl | because I had a change of heart and started using it again | 18:00 |
| yvl | flourish/page.py | 18:00 |
| replaceafill | yvl :D | 18:00 |
| menesis | :) | 18:00 |
| yvl | well it is somewhat annoying when debugging | 18:00 |
| replaceafill | so, it's like a property that's calculated only once? | 18:00 |
| yvl | yes | 18:01 |
| replaceafill | ah | 18:01 |
| yvl | also it is annoying for tests, because I always forget that once it's calculated it's calculated | 18:01 |
| yvl | and if you change some view attributes in test, it does not re-calculate by magic | 18:01 |
| yvl | easy to forget and make mistakes | 18:02 |
| yvl | I used it to reduce adapter lookups | 18:02 |
| replaceafill | right, and we usally don't register stuff on runtime, right? | 18:02 |
| yvl | I reckon we don't define new adapters that often | 18:02 |
| yvl | even in tests | 18:02 |
| aelkner | could one say that it's appropriate when used sparingly and with high payoff? | 18:03 |
| yvl | one surely could | 18:03 |
| replaceafill | yvl another thing i didnt get right: | 18:03 |
| replaceafill | # Arbitrary keys and values are allowed to be passed to the manager. | 18:03 |
| replaceafill | IManagerDirective.setTaggedValue('keyword_arguments', True) | 18:03 |
| yvl | ah, magic :D | 18:03 |
| replaceafill | what does that setTaggedValue do? | 18:03 |
| replaceafill | :) | 18:03 |
| yvl | this is a neat trick | 18:03 |
| yvl | this means that the directive now accepts any random values | 18:04 |
| yvl | <flourish:viewlet | 18:04 |
| yvl | .... | 18:04 |
| yvl | foobar="Hello!" | 18:04 |
| replaceafill | ah! | 18:04 |
| yvl | /> | 18:04 |
| yvl | and current implementation sets foobar = u"Hello!" to your class | 18:04 |
| yvl | very usefull for viewlets | 18:05 |
| yvl | again - a good payoff | 18:05 |
| replaceafill | definitely | 18:05 |
| yvl | so, content providers | 18:05 |
| yvl | current implementation is a bit messy | 18:05 |
| yvl | but in its essence it allows things like: | 18:05 |
| yvl | <content | 18:06 |
| yvl | class=".app.ContentTitle" | 18:06 |
| yvl | permission="schooltool.view" | 18:06 |
| yvl | (as seen in schooltool/app/browser/app.py) | 18:06 |
| yvl | and then in page templates: | 18:06 |
| yvl | <h1 tal:content="structure context/schooltool:content/title"> </h1> | 18:07 |
| yvl | schooltool:content looks up the content provider named title | 18:07 |
| yvl | since the content provider is registered for context, request, view | 18:08 |
| aelkner | may i ask something real quick? | 18:08 |
| yvl | sure! | 18:08 |
| aelkner | the branch we're looking at is trunk plus skin/flourish? | 18:09 |
| aelkner | and nothing else, right? | 18:09 |
| yvl | + some views in schooltool/app/browser/app.py | 18:09 |
| yvl | and some new templates named f_*.pt | 18:09 |
| aelkner | ok | 18:09 |
| yvl | hmm | 18:09 |
| yvl | maybe there's something else | 18:10 |
| yvl | I don't remember what was merged to trunk, sorry | 18:10 |
| aelkner | i'm lloking at app.py, but i don't see what you're referring to | 18:10 |
| yvl | in trunk? | 18:11 |
| replaceafill | aelkner schooltool.app.browser.app.ContentTitle | 18:11 |
| aelkner | oops | 18:11 |
| aelkner | i was looking at app/app.py not ht ebrowser file :) | 18:12 |
| yvl | :) | 18:12 |
| yvl | so, content providers give us some fine-tuning points | 18:12 |
| yvl | say, we want to change a title of person container in some views | 18:13 |
| yvl | <content | 18:13 |
| yvl | class="schooltool.app.browser.app.ContentTitle" | 18:13 |
| yvl | permission="schooltool.view" | 18:13 |
| yvl | I could have changed the title for a view, if view="..." was set | 18:13 |
| yvl | here it was changed for a container in all views | 18:14 |
| yvl | so if you wrote something like this in tal: | 18:14 |
| yvl | <h1 tal:content="view/schooltool_app/persons/schooltool:content/title"></h1> | 18:14 |
| yvl | you would get "Persons" | 18:14 |
| yvl | replaceafill - note the "title" attribute - it's not a part of directive, it's done via tagged keywords and replaces a *property* in base class | 18:15 |
| yvl | hacky! | 18:15 |
| replaceafill | :) | 18:15 |
| yvl | the directive in this example is cumbersome, but I plan to write ZCML shorthands as we have more similar directives | 18:16 |
| yvl | it's a bit difficult to plan ahead | 18:16 |
| yvl | ok, so that's it on content providers, unless you have questions | 18:17 |
| yvl | (other than "why the hell you would need them?") | 18:18 |
| aelkner | this last part is magic | 18:18 |
| yvl | yes | 18:18 |
| aelkner | i'd say ok to magic if demystified by examples/docs | 18:18 |
| yvl | apologies, I did intend to write those! | 18:18 |
| yvl | well, I still do :) | 18:19 |
| aelkner | see, when everything is just concepts, i get lost easily | 18:19 |
| yvl | I don't blame you! | 18:19 |
| aelkner | i'm a pattern recognizer if there is a label to be put on me | 18:19 |
| replaceafill | the answer is in the code :) | 18:19 |
| replaceafill | but also, i dont blame you | 18:20 |
| th1a | Well, aelkner won't need to do this stuff immediately anyhow. | 18:20 |
| th1a | I don't think... | 18:20 |
| yvl | true | 18:20 |
| th1a | Let's talk about the rest of the day and tomorrow. | 18:20 |
| yvl | ok | 18:20 |
| yvl | just one thing | 18:21 |
| yvl | I'd like to briefly go over some places page.pt | 18:21 |
| replaceafill | the only concept i dont have clear right now is the "active viewlet" | 18:21 |
| yvl | when you display a list of tabs, you need to highlight one of them | 18:21 |
| aelkner | did we discuss that yet? | 18:21 |
| yvl | no | 18:21 |
| yvl | name sucks, but it is again a simple adapter | 18:22 |
| yvl | viewlet managers have a list of viewlets | 18:23 |
| aelkner | replaceafill, where are you getting this from? | 18:23 |
| yvl | all viewlets have names | 18:23 |
| replaceafill | aelkner skin/flourish/instance/app.zcml | 18:23 |
| yvl | IActiveViewletName returns the name of the viewlet that is "selected" | 18:23 |
| yvl | also, there is a trick replaceafill :) | 18:24 |
| yvl | if you define a viewlet manager | 18:25 |
| yvl | and define an identical one on one of the views, with a slight difference | 18:25 |
| yvl | active_viewlet="manage" | 18:25 |
| yvl | it will override the machinery and set the active viewlet | 18:25 |
| yvl | as a class attribute | 18:25 |
| yvl | not saying you should use this, but just FYI | 18:25 |
| replaceafill | :) | 18:26 |
| yvl | oh, and active_viewlet is used in ListNavigationBase | 18:26 |
| yvl | allright then, I think th1a intends to round this up | 18:27 |
| yvl | so we can postpone the viewlet manager talk for later | 18:27 |
| yvl | and go over immediat plans | 18:27 |
| yvl | immediate :) | 18:27 |
| yvl | ("right after these commercials!") | 18:27 |
| * yvl runs off for 3 minutes | 18:28 | |
| * th1a wakes up. | 18:28 | |
| th1a | Three minutes... | 18:31 |
| * th1a is glad real meetings don't have timestamped breaks. | 18:32 | |
| yvl | :) | 18:33 |
| th1a | OK. | 18:33 |
| th1a | So, perhaps yvl would like to iterate on test.html tomorrow? | 18:33 |
| yvl | hmm | 18:34 |
| th1a | Or... | 18:34 |
| th1a | I can come back to you. | 18:34 |
| yvl | menesis raised a good point | 18:34 |
| yvl | I got to the part on "how the page is assembled" | 18:34 |
| yvl | i.e.: how to write a view | 18:34 |
| yvl | so I'll need to talk about this | 18:35 |
| yvl | or... write an email | 18:35 |
| replaceafill | explain <flourish:page ...> too | 18:35 |
| yvl | that's the part :) | 18:35 |
| replaceafill | content_template=... | 18:35 |
| replaceafill | :) | 18:35 |
| replaceafill | and dont forget i18n:domain in content templates :P | 18:35 |
| yvl | I explicitly ignored them | 18:36 |
| replaceafill | i noticed :P | 18:36 |
| yvl | thank you! :) | 18:36 |
| yvl | ok | 18:36 |
| replaceafill | and then you made me think "maybe ther'es a magic way for the extractor to pick them up".... | 18:36 |
| yvl | no there's not | 18:36 |
| yvl | so let me sum that up in email tomorrow | 18:36 |
| aelkner | btw, is this term, 'flourish' going to end up in the permanent namespace? | 18:37 |
| * yvl shrugs | 18:37 | |
| yvl | this seemed like a better name than "newskin" | 18:37 |
| th1a | I like it. | 18:37 |
| th1a | Yes! | 18:37 |
| yvl | and I kind of liked the full definition of the word | 18:37 |
| th1a | Actually, if we ever somehow lose our trademark cold war, I think "flourish" would be a good name for the application. | 18:38 |
| yvl | :D | 18:38 |
| yvl | thanks, th1a :) | 18:38 |
| replaceafill | cold war :)) | 18:38 |
| th1a | So... let's talk about aelkner and replaceafill. | 18:39 |
| yvl | so, is anyone up for another meeting tomorrow? | 18:39 |
| th1a | We'll need one. | 18:39 |
| th1a | Regular time. | 18:39 |
| th1a | 1 hour. | 18:39 |
| yvl | agreed | 18:39 |
| aelkner | i thought we were meeting all week | 18:39 |
| th1a | Pretty much. | 18:39 |
| aelkner | it's a sprint, isn't it? | 18:39 |
| th1a | Yes. | 18:40 |
| th1a | I've been running in place the whole time. | 18:40 |
| * yvl is also ok with regular time - 1h, duration 1h :) | 18:40 | |
| th1a | Yes, keep it to an hour. | 18:40 |
| yvl | ok, so replaceafill | 18:40 |
| yvl | there is an important thing that needs to be done | 18:41 |
| yvl | form css :) | 18:41 |
| yvl | are you up for it? | 18:41 |
| th1a | Well, perhaps not immediately. | 18:41 |
| yvl | ok | 18:41 |
| th1a | I think I need replaceafill and aelkner to get aelkner up to speed on making jquery dialogs. | 18:42 |
| th1a | So I can keep aelkner grinding away. | 18:42 |
| yvl | there is one thing that would be a big help for me | 18:42 |
| yvl | since you guys are in the same timezone | 18:42 |
| aelkner | also, we need to discuss branch coordination | 18:43 |
| yvl | right! | 18:43 |
| aelkner | is yvl's flourish branch the sprint trunk? | 18:43 |
| yvl | no, I will make one | 18:43 |
| yvl | and send and email ;) | 18:43 |
| aelkner | user schooltool-developers, right? | 18:43 |
| aelkner | then we can bzr pull before bzr push, etc. | 18:44 |
| yvl | yes | 18:44 |
| yvl | then again | 18:44 |
| aelkner | that's what filip and i did at our sprint | 18:44 |
| yvl | we could have one central branch | 18:44 |
| aelkner | that's what i meant | 18:44 |
| yvl | you and replaceafill could have your own branches | 18:44 |
| yvl | every morning I would merg your branches (and mine) to the central | 18:45 |
| aelkner | sorry, go on | 18:45 |
| yvl | every morning you would merge the central to yours | 18:45 |
| aelkner | and we would merge back from central? | 18:45 |
| aelkner | oops, hit enter before reading | 18:45 |
| yvl | and every morning th1a would pull from the central | 18:45 |
| th1a | Yes, that's what I want. | 18:45 |
| aelkner | sounds like a good plan | 18:46 |
| aelkner | clean | 18:46 |
| yvl | menesis, do you think that bzr is up for the task? | 18:46 |
| yvl | :) | 18:46 |
| aelkner | replaceafill and i could even merge from one-another's branches | 18:46 |
| aelkner | on occasion, when we want to share something new | 18:46 |
| menesis | yvl: that's what bzr was made for! | 18:46 |
| yvl | that settles it then :))) | 18:47 |
| yvl | and aelkner - yes, please do | 18:47 |
| replaceafill | yvl is the branches talk the thing that would be a big help for you? | 18:47 |
| aelkner | anyway, we don't have the central branch ntil tomorrow | 18:47 |
| yvl | well, yes, but I had something else in mind | 18:47 |
| aelkner | what tasks can we have until then? | 18:48 |
| aelkner | i can read your code and grok it | 18:48 |
| th1a | making some modals. | 18:48 |
| aelkner | the part about the content providers and directives is all magic to me | 18:48 |
| yvl | replaceafill, can you help aelkner "real time" with undocumented zcml/zope hackery? | 18:48 |
| aelkner | ah yes, replaceafill can clue me in on dialogs as th1a suggested | 18:48 |
| replaceafill | i can try ;) | 18:48 |
| * yvl would be very grateful :) | 18:49 | |
| replaceafill | of course | 18:49 |
| yvl | allright then | 18:50 |
| yvl | modal dialogs... | 18:50 |
| yvl | few things of interest | 18:50 |
| th1a | The one problem with this plan is that the links that trigger the modal dialogs will be changing. | 18:50 |
| th1a | I assume that's a minor issue. | 18:50 |
| yvl | hopefully | 18:50 |
| yvl | replaceafill, see flourish/templates/z3c_form.pt | 18:51 |
| replaceafill | yes | 18:51 |
| yvl | this is the content template for a person add | 18:51 |
| replaceafill | i was going to bring that up on the <page> directive cnoversation :) | 18:51 |
| yvl | I'm thinking about making Page's traversable | 18:51 |
| replaceafill | yvl should something like that be the template for all forms? | 18:51 |
| replaceafill | shouldn't... | 18:51 |
| yvl | well it currently uses a macro | 18:52 |
| yvl | I intend to put the content of the macro there | 18:52 |
| yvl | so, if all pages have their /modal | 18:52 |
| yvl | and, say, render content_template instead of template... :) | 18:53 |
| yvl | could you put that into modal dialog? ;) | 18:53 |
| yvl | and make some links do url to the page + "/modal" | 18:53 |
| yvl | and such links could have onclick | 18:53 |
| yvl | and instead of flourish.page.LinkViewlet there could be JSModalLinkViewlet.... | 18:54 |
| replaceafill | yvl you mean the traversal view idea you mentioned before? | 18:54 |
| yvl | yes | 18:54 |
| replaceafill | :| | 18:54 |
| replaceafill | so we would have "persons/add.html/modal | 18:55 |
| yvl | yes | 18:55 |
| replaceafill | courses/addSchoolToolCourse.html/modal | 18:55 |
| replaceafill | and so on | 18:55 |
| yvl | automation :D | 18:55 |
| yvl | then again, I've not settled on the issue yet | 18:55 |
| yvl | maybe simply registering page that instead of template renders content_template may be better | 18:56 |
| yvl | you could start with that | 18:56 |
| th1a | A page might have multiple modals. | 18:56 |
| yvl | th1a, it should be fine | 18:57 |
| yvl | persons/index.html will have multiple modals | 18:57 |
| yvl | persons/addTeacher.html will be add teacher *page* | 18:57 |
| yvl | persons/addTeacher.html/modal will be the modal version of the form | 18:57 |
| th1a | OK. | 18:58 |
| yvl | again - haven't finally decided | 18:58 |
| th1a | So... what do you think replaceafill? | 18:58 |
| th1a | I don't want to hold up on this process. | 18:58 |
| replaceafill | yvl so, for registering those i should use: <page content_template="TEMPLATE WITH ONLY REQUIRED Z3C FORM MACROS"> | 18:59 |
| yvl | for starters, you could do this: | 18:59 |
| yvl | instead of specifying content_template | 18:59 |
| yvl | specify template directly | 18:59 |
| yvl | that's it | 18:59 |
| replaceafill | ah, ok | 18:59 |
| yvl | <flourish:page | 19:00 |
| yvl | for="schooltool.app.interfaces.ISchoolToolApplication" | 19:00 |
| yvl | name="login.html" | 19:00 |
| yvl | /> | 19:00 |
| yvl | <flourish:page | 19:00 |
| yvl | for="schooltool.app.interfaces.ISchoolToolApplication" | 19:00 |
| yvl | name="login-modal.html" | 19:00 |
| yvl | title="Log in" | 19:00 |
| yvl | template="templates/f_login.pt" | 19:00 |
| yvl | class="schooltool.app.browser.app.LoginView" | 19:00 |
| yvl | permission="zope.Public" | 19:00 |
| yvl | /> | 19:00 |
| yvl | insta-win! ;) | 19:00 |
| replaceafill | :D | 19:00 |
| yvl | so... are we there yet? ;) | 19:01 |
| aelkner | perhaps a silly question | 19:01 |
| aelkner | the whole flourish sub-package of skin is intended as an addition | 19:01 |
| aelkner | that works wide-by-side with the main skin | 19:01 |
| aelkner | and is registered as a separate skin? | 19:02 |
| yvl | yes | 19:02 |
| aelkner | and the flourish namespace is for this skin only | 19:02 |
| yvl | yes | 19:02 |
| replaceafill | yvl it's basically what i did here, correct? http://bazaar.launchpad.net/~replaceafill/schooltool/schooltool_jquery-ui/revision/2800 | 19:02 |
| replaceafill | name="addSchoolToolCourseInline.html" | 19:02 |
| replaceafill | well, not exactly the same... | 19:03 |
| replaceafill | but same idea | 19:03 |
| yvl | same idea | 19:03 |
| replaceafill | got it | 19:03 |
| yvl | a small note - I'll move some of the zcml from flrourish subpackage to respective folders | 19:03 |
| aelkner | like what? | 19:04 |
| yvl | app.zcml to schooltool/browser/app/flourish.zcml | 19:04 |
| aelkner | ah | 19:04 |
| yvl | from schooltool/skin/frlourish/instance | 19:04 |
| yvl | but the idea stays the same | 19:04 |
| yvl | flourish is a separate skin | 19:04 |
| yvl | also - a separate instance - at the moment | 19:05 |
| yvl | will be default instance this autumn | 19:05 |
| aelkner | that's the switch-over | 19:05 |
| aelkner | seems like a clean plan | 19:06 |
| yvl | let's do this ;) | 19:06 |
| replaceafill | question: | 19:06 |
| replaceafill | for this modal task | 19:06 |
| replaceafill | i think we should move old <addform> <editform> directives to z3c.forms | 19:06 |
| yvl | +7 | 19:07 |
| replaceafill | or are we going to post pone this | 19:07 |
| replaceafill | :) | 19:07 |
| th1a | I think now is the time. | 19:07 |
| aelkner | +1 | 19:07 |
| yvl | some formlib views can stay though | 19:07 |
| yvl | but if you can move them - move them | 19:08 |
| replaceafill | does formlib provide macros? | 19:08 |
| replaceafill | like z3c.form dos | 19:08 |
| replaceafill | does | 19:08 |
| yvl | we have macros for both formlib and z3c.form | 19:08 |
| replaceafill | ah ok | 19:08 |
| yvl | see schooltool/skin/configure.zcml | 19:09 |
| yvl | z3cform include | 19:09 |
| yvl | and, well, "formlib_macros" :D | 19:09 |
| yvl | and the rest of the mess | 19:09 |
| yvl | so | 19:10 |
| yvl | where's that bag of gravel? ;) | 19:10 |
| aelkner | not ready yet | 19:10 |
| yvl | aww | 19:11 |
| aelkner | i was promised a branch discussion | 19:11 |
| aelkner | i have two branches, one for the menu (not as important) and one for iding report sheets | 19:11 |
| aelkner | hiding | 19:11 |
| th1a | The day is not over aelkner. | 19:11 |
| aelkner | that one is needed by a customer | 19:11 |
| th1a | Here's what I keep trying to get to. | 19:11 |
| th1a | aelkner: Chill. | 19:12 |
| th1a | So I have some places to put modal dialogs in related to persons in the spreadsheet. | 19:12 |
| th1a | Can we have aelkner and replaceafill try to tackle one or more of those today. | 19:12 |
| th1a | ? | 19:12 |
| *** menesis has quit IRC | 19:12 | |
| th1a | Say, password_edit.html? | 19:13 |
| yvl | person_add? | 19:13 |
| th1a | @@groups.html if you're ambitious. | 19:13 |
| yvl | well, here's the status of the views | 19:13 |
| th1a | yvl: Actually, I don't think we gain anything with such a complex form. | 19:13 |
| yvl | true | 19:13 |
| yvl | true | 19:14 |
| yvl | hmm | 19:14 |
| yvl | it would be best to have a person view | 19:14 |
| yvl | that we could look at | 19:14 |
| yvl | before toying with edit view | 19:14 |
| th1a | There is plenty of work to do around the edges. | 19:15 |
| yvl | replaceafill, if you're up for it, you can port the index.html of basic person | 19:15 |
| yvl | well, here's the thing - | 19:15 |
| th1a | In fact, the edges are the site of some of the biggest atrocities. | 19:15 |
| yvl | hmm | 19:15 |
| th1a | I need to get aelkner working on these or he'll be twiddling his thumbs. | 19:15 |
| yvl | you know, I think guys can try out the change password view | 19:16 |
| yvl | or any other edit view | 19:16 |
| yvl | but branched from trunk | 19:16 |
| th1a | That's what I was thinking. | 19:16 |
| yvl | then quickly re-do it on sprint branch | 19:16 |
| replaceafill | i also think aelkner and i can use trunk for now | 19:16 |
| th1a | y | 19:16 |
| yvl | go ahead then | 19:16 |
| th1a | Do you guys need anything else from yvl that you can think of before he goes and has a beer? | 19:17 |
| * replaceafill looks his email | 19:17 | |
| replaceafill | "Though I'm a bit concerned with the amount of customization done in the "inline" course view class." | 19:17 |
| replaceafill | yvl just that comment | 19:17 |
| replaceafill | the way i implemented inline views required lots of jquery | 19:18 |
| replaceafill | to submit the form and insert validation results | 19:18 |
| replaceafill | but i couldnt figure a better way | 19:18 |
| replaceafill | btw, https://lists.launchpad.net/schooltool-developers/msg00402.html | 19:19 |
| replaceafill | that's one of yvl's comment to my jquery ui branch | 19:19 |
| th1a | Is this a case of premature optimization? | 19:20 |
| replaceafill | i'd like to think it is | 19:20 |
| replaceafill | so i should let yvl go | 19:20 |
| replaceafill | and we can discuss it during the week | 19:20 |
| * th1a drops the bag of gravel. | 19:20 | |
| yvl | I think that's the case, replaceafill | 19:20 |
| th1a | See everyone tomorrow, regular time. | 19:20 |
| yvl | we can make the "shared" case after 2-3 views are customized | 19:21 |
| replaceafill | great, thanks | 19:21 |
| yvl | well, good luck guys! | 19:21 |
| yvl | (almost 4 hour meeting.. wow ;) ) | 19:21 |
| th1a | I'll let replaceafill and aelkner decide if they want a break. | 19:22 |
| yvl | see you all tomorrow | 19:22 |
| replaceafill | thanks yvl | 19:22 |
| replaceafill | aelkner when it's a good time for us to start? | 19:22 |
| aelkner | cya yvl | 19:22 |
| th1a | thanks yvl. | 19:22 |
| replaceafill | i'd like th1a to be around if possible | 19:22 |
| aelkner | then i'll leave it up to him | 19:23 |
| replaceafill | to keep us focused :P | 19:23 |
| replaceafill | and by us i mean me :) | 19:23 |
| replaceafill | ok, let's only decide what view do we make modal | 19:23 |
| aelkner | well, you and i need to discuss what we are doing off of trunk | 19:24 |
| replaceafill | aelkner ? | 19:24 |
| aelkner | we will have nothing from the flourish namspace | 19:24 |
| replaceafill | aelkner i think flourish is not necessary yet | 19:24 |
| aelkner | well, for starters, what are we trying to do first? | 19:24 |
| aelkner | i mean, by making modal, what changes are needed in trunk? | 19:25 |
| aelkner | for picking the niew, i think edit_password is best | 19:25 |
| th1a | The whole point is that it is something aelkner can do while flourish is being fleshed out. | 19:25 |
| * replaceafill goes see edit password | 19:26 | |
| aelkner | replaceafill, if we are to make a modal dialog version of an existing view | 19:26 |
| aelkner | are we not in need of the /modal traversal concept? | 19:27 |
| aelkner | or are we talking about changing edit_password to be modal in place? | 19:27 |
| replaceafill | what i dont like about edit password is that is not z3c.form | 19:27 |
| replaceafill | it's zope.formlib | 19:27 |
| aelkner | oh, forget that then | 19:27 |
| aelkner | person add? | 19:27 |
| replaceafill | no, too complex and i think th1a just said unnecessary | 19:28 |
| aelkner | is group add z3c? | 19:28 |
| replaceafill | something on person | 19:28 |
| aelkner | contact add | 19:28 |
| replaceafill | aelkner edit password doesnt seem too difficult to port | 19:29 |
| replaceafill | i'd almost say we only need to change the base class :D | 19:29 |
| th1a | Look at the spreadsheet. | 19:30 |
| aelkner | true, if ever there was an easy port, that would be it | 19:30 |
| th1a | You could probably just re-implement it as a pure jquery dialog. | 19:30 |
| th1a | Also /preferences | 19:31 |
| replaceafill | aelkner let's start with edit password | 19:31 |
| replaceafill | or password_edit.html | 19:31 |
| aelkner | i was just going to say | 19:32 |
| replaceafill | i hope that widget works quickly in z3c.form | 19:32 |
| aelkner | so i'm going to make a sandbox and branch trunk | 19:32 |
| replaceafill | go ahead | 19:32 |
| replaceafill | can we call them "flourish_sprint" or something? | 19:33 |
| replaceafill | i'll do the same | 19:33 |
| aelkner | depends | 19:33 |
| aelkner | what is the time frame for how long we will not be working on branches of yvl's flourish branch | 19:34 |
| aelkner | i was thinking 'modal_test' | 19:34 |
| aelkner | because this is just a test until the real thing, isn't that right? | 19:34 |
| replaceafill | ok | 19:35 |
| replaceafill | i was just thinking we could use the same branch and merge flourish when it's done | 19:35 |
| replaceafill | we can do whatever we want with our branches ;) | 19:36 |
| aelkner | i prefer to keep the names clear enough for what i did and when | 19:36 |
| replaceafill | ... | 19:36 |
| replaceafill | ok... | 19:36 |
| aelkner | i get confused easily renaming branches for different purposes | 19:36 |
| replaceafill | ok | 19:37 |
| replaceafill | so, i'm going to port that view to z3c.form right now | 19:37 |
| replaceafill | if i can :) | 19:38 |
| replaceafill | and we start from there, ok? | 19:38 |
| aelkner | well, what would i do in the meantime? | 19:38 |
| replaceafill | read jquery ui docs | 19:38 |
| replaceafill | http://jqueryui.com/demos/dialog/ | 19:39 |
| aelkner | ok, will do | 19:39 |
| replaceafill | mostly, the option of the dialog | 19:39 |
| replaceafill | http://jqueryui.com/demos/dialog/#options | 19:39 |
| replaceafill | aelkner you could also check out my jquery ui branch, it has an example for adding courses using modal dialogs | 19:41 |
| replaceafill | https://code.launchpad.net/~replaceafill/schooltool/schooltool_jquery-ui | 19:41 |
| replaceafill | specifically see revision 2800 | 19:41 |
| aelkner | ok | 19:43 |
| replaceafill | th1a shouldn't we ask for current password on password edit? | 19:56 |
| replaceafill | in case i leave my session open and unattended ;) | 19:56 |
| th1a | Actually, yes. | 19:56 |
| replaceafill | good time to do that? | 19:56 |
| replaceafill | dont think it's too difficult | 19:56 |
| th1a | Well... hopefully there's no hidden trap that explains why it wasn't done the first time. | 19:58 |
| replaceafill | another thing related to edit password, if you change your own password, you'll be automatically logged out | 20:02 |
| replaceafill | i change my password, hit Apply, get success message, but next time i click something i get the "not allowed message" | 20:02 |
| replaceafill | i guess we need to change the success message to say that | 20:03 |
| th1a | Oh... does that make it a bad candidate for modalness? | 20:03 |
| replaceafill | "you need to provide your new credentials" | 20:03 |
| replaceafill | th1a probably :( | 20:03 |
| th1a | You're not going back to where you came from. | 20:03 |
| th1a | preferences then? | 20:04 |
| aelkner | yes, app preferences | 20:04 |
| replaceafill | well, at least porting was easy :) | 20:04 |
| th1a | There are person preferences too, right? | 20:05 |
| aelkner | nope, thought there are gradebook preferences, but that's not core | 20:06 |
| replaceafill | th1a yes, there are person preferences for setting "show periods" and "make calendar public" | 20:07 |
| replaceafill | regular BrowserView + template | 20:07 |
| th1a | Yeah, they're really more like calendar settings. | 20:08 |
| th1a | We'll probably move the link there, and then someday do a grand reorganization of personal settings. | 20:08 |
| th1a | But anyhow, you could do that one as modal. | 20:08 |
| replaceafill | all right, starting to port... | 20:08 |
| th1a | I think one of the more complex forms that would benefit is the ones in the style of @@groups.html. | 20:09 |
| replaceafill | ok, done porting preferences form to z3c.form | 20:32 |
| replaceafill | let's see how many tests were broken | 20:33 |
| replaceafill | th1a zyt? | 20:41 |
| replaceafill | i'm not sure about a behaviour | 20:41 |
| replaceafill | can you visit: http://69.164.203.135:7081/persons/camila | 20:41 |
| replaceafill | log in as manager | 20:42 |
| aelkner | i'm going to take a break for about an hour | 20:42 |
| aelkner | afk | 20:43 |
| th1a | I'm here. | 20:49 |
| replaceafill | ah, it's just that the edit form for preferences doesnt give you confirmation message on apply | 20:50 |
| replaceafill | so, if you go to that form and hit apply, things are saved, but nothing is shown to the user | 20:50 |
| th1a | See... the kind of gaffe we just avoid with modal dialogs! | 20:50 |
| replaceafill | :D | 20:50 |
| replaceafill | anyway, it's just that my z3c.form implementation break tests because of this | 20:50 |
| replaceafill | but i think we can continue anyway | 20:51 |
| replaceafill | for aelkner to start on jquery | 20:51 |
| th1a | We'll be spending more time on tests that anything else. | 20:51 |
| th1a | Well, in an hour. | 20:51 |
| th1a | If you want take a look at @@groups.html | 20:51 |
| replaceafill | ah ok, i'll will | 20:52 |
| replaceafill | th1a just a comment | 20:52 |
| replaceafill | aelkner i pushed my changes | 20:55 |
| replaceafill | aelkner https://code.launchpad.net/~replaceafill/schooltool/modal_test | 20:55 |
| replaceafill | aelkner we'll start from there | 20:56 |
| replaceafill | aelkner see you in an hour | 20:56 |
| *** replaceafill has quit IRC | 20:56 | |
| *** alga has joined #schooltool | 20:58 | |
| *** menesis has joined #schooltool | 21:57 | |
| *** replaceafill has joined #schooltool | 22:41 | |
| th1a | aelkner: ayt? | 22:45 |
| * th1a was waiting for aelkner to rejoin the channel. | 22:45 | |
| aelkner | i'm here | 22:49 |
| aelkner | replaceafill, so i groked your jquery-ui branch and your z3c person views | 22:50 |
| aelkner | what shall we do next | 22:50 |
| aelkner | oh, i do have a question about jquery-ui | 22:51 |
| replaceafill | aelkner yes? | 22:51 |
| aelkner | the $ operator in jquery is for the standard jquery object | 22:51 |
| aelkner | so how does .dialog() get into it | 22:51 |
| replaceafill | aelkner though a plug in | 22:51 |
| aelkner | is that what jquery-ui does in some startup code? | 22:51 |
| replaceafill | that's what jquery *UI* does | 22:52 |
| replaceafill | yes | 22:52 |
| aelkner | you could have coded the ready function without class attributes in theory | 22:53 |
| aelkner | using the @absolute_url adapter and string: | 22:53 |
| aelkner | but that's not important | 22:53 |
| aelkner | anyway, what next? | 22:54 |
| replaceafill | aelkner what do you mean without class attributes? | 22:55 |
| replaceafill | aelkner btw, i'm on a really slow network :( | 22:55 |
| aelkner | <metal:block tal:replace="view/addform_id" /> | 22:56 |
| aelkner | sorry, i meant | 22:56 |
| aelkner | <metal:block tal:replace="view/addform_inline_url" /> | 22:56 |
| aelkner | that could be done without adding to the view class | 22:56 |
| replaceafill | you need it in the class so the form has it | 22:57 |
| replaceafill | sorry, not the form, the placeholder for the dialog | 22:58 |
| replaceafill | in the .pt file: | 22:58 |
| aelkner | <metal:block tal:replace="string:${context/@@absolute_url}/addSchoolToolCourseInline.html" /> | 22:58 |
| aelkner | wouldn't that work as well and not necessitate the class attribute? | 22:59 |
| replaceafill | ok, check course/templates/course_container.pt | 23:00 |
| replaceafill | at the bottom: | 23:00 |
| aelkner | that's where i got that from | 23:00 |
| aelkner | the load call | 23:01 |
| replaceafill | <div id="addform" tal:condition="view/canModify"> | 23:01 |
| replaceafill | </div> | 23:01 |
| replaceafill | no, the bottom of the template | 23:01 |
| aelkner | the addform div | 23:01 |
| replaceafill | not the javascript code | 23:01 |
| replaceafill | yes | 23:01 |
| *** hoffman has joined #schooltool | 23:01 | |
| replaceafill | do you have firebug installed? | 23:01 |
| aelkner | yes | 23:01 |
| replaceafill | look at the html output in firebug | 23:02 |
| replaceafill | there's an block below the footer | 23:02 |
| replaceafill | do you see it? | 23:02 |
| replaceafill | it has "display: none;" | 23:02 |
| replaceafill | so it's not visible | 23:02 |
| replaceafill | but you can see it in firebug | 23:03 |
| aelkner | yeah, i see it | 23:03 |
| replaceafill | ok, in the template you need a "placeholder" for the dialog | 23:04 |
| aelkner | right | 23:04 |
| replaceafill | the class attribute and the id attribute in the template should match | 23:04 |
| replaceafill | they don't | 23:04 |
| replaceafill | the attribute in the template is hardcoded | 23:04 |
| replaceafill | anyway, the point of doing all that was to get as dynamic as possible :/ | 23:05 |
| aelkner | you're thinking of this as a general solution, so you want the attributes to be resolved in the view class | 23:05 |
| replaceafill | but again, to the basics | 23:05 |
| replaceafill | correct | 23:05 |
| replaceafill | same goes with course.CourseInlineAddView | 23:06 |
| replaceafill | it has an id | 23:06 |
| replaceafill | id = 'course-add-form' | 23:06 |
| replaceafill | that can be used in jquery | 23:07 |
| replaceafill | because the form renders with | 23:07 |
| replaceafill | <form id="course-add-form" ...> | 23:07 |
| replaceafill | as i told you in my email about the popup, if you only have one element in the tree, you can assign an id to refer to it from jquery | 23:08 |
| replaceafill | if you will have several elements, then you append "class=" attribute to them | 23:08 |
| aelkner | yeah, we never discussed that change you made to my js | 23:09 |
| replaceafill | we can if you want | 23:09 |
| aelkner | since only one menu at a time was going to be active | 23:09 |
| aelkner | why is it different giving it a class from giving it an id | 23:09 |
| replaceafill | think of it like this: | 23:10 |
| replaceafill | after the template has been rendered, you should have unique ids | 23:10 |
| replaceafill | and the id should stay the same for elements | 23:10 |
| replaceafill | classes can be dynamic | 23:10 |
| replaceafill | i mean, you can do whatever you want with attributes, but that's what you usually do | 23:11 |
| replaceafill | you don't move the id from one element to another | 23:11 |
| aelkner | is that something you read in a standards doc or something? | 23:11 |
| replaceafill | if you want to refer to a specific element you use its id | 23:11 |
| replaceafill | the html spec :) | 23:11 |
| aelkner | well, i was referring to a specific element, but which element that was is dynamic | 23:12 |
| replaceafill | http://www.w3.org/TR/html40/struct/global.html#h-7.5.2 | 23:12 |
| aelkner | that link supports what i did, not the opposite | 23:13 |
| aelkner | there is onl one menu that is active at a time | 23:13 |
| aelkner | so the words 'specific element' applies to that | 23:13 |
| replaceafill | :/ | 23:13 |
| aelkner | classes are assigned to types of elements that could be more than one in instance | 23:13 |
| aelkner | which is also exactly not the case | 23:14 |
| replaceafill | correct, or removed | 23:14 |
| aelkner | there is only one active menu | 23:14 |
| replaceafill | correct, and then you REMOVE it | 23:14 |
| aelkner | 'Any number of elements may be assigned the same class name' | 23:14 |
| aelkner | but we are talking about only one element | 23:14 |
| replaceafill | yes, but focus on the remove part... | 23:15 |
| aelkner | what about it | 23:15 |
| aelkner | are you saying that because there is removeClass | 23:16 |
| replaceafill | when you display the menu, you mark it one way (either id or class), when you hide it, you need to mark it a different way | 23:16 |
| aelkner | and there is no removeId | 23:16 |
| replaceafill | correct | 23:17 |
| replaceafill | jquery provides methods for managing classes | 23:17 |
| aelkner | ok, so it's a matter of language convenience | 23:17 |
| replaceafill | addClass(), removeClass() | 23:18 |
| aelkner | that works for me | 23:18 |
| replaceafill | unfortunately you will have to trust me on this one :/ | 23:18 |
| replaceafill | anyway | 23:18 |
| replaceafill | continuing the popup change | 23:18 |
| replaceafill | also, jquery allows you to traverse stuff | 23:18 |
| replaceafill | so you can avoid plain javascript logic | 23:18 |
| aelkner | hasClass? | 23:19 |
| replaceafill | you had: | 23:19 |
| replaceafill | current_menu = $('#my_menu') | 23:19 |
| replaceafill | (with no semicolon...) | 23:20 |
| replaceafill | if (current_menu.length > 0){ | 23:20 |
| replaceafill | $(current_menu).css('visibility', 'hidden'); | 23:20 |
| replaceafill | $(current_menu).attr('id', ''); | 23:20 |
| replaceafill | } | 23:20 |
| replaceafill | let's only focus on the if | 23:20 |
| aelkner | i know what i had | 23:20 |
| replaceafill | i know you know :) | 23:20 |
| replaceafill | i'm only making my point | 23:20 |
| aelkner | sure, go ahead | 23:20 |
| replaceafill | there, you're checking if there are elements with #my_menu ids, correct? | 23:21 |
| aelkner | right | 23:21 |
| replaceafill | that's what the > 0 is doing | 23:21 |
| replaceafill | but you can go ahead and do: $('#my_menu').css('something', 'value'); | 23:21 |
| replaceafill | if there's not element with #my_menu identifier, nothing happens | 23:21 |
| replaceafill | you dont get an error | 23:22 |
| replaceafill | you this type of checking is unnecessary | 23:22 |
| aelkner | if ($(e.target).hasClass('activity_heading') == false) { | 23:23 |
| replaceafill | hold on, one more thing | 23:23 |
| aelkner | if the place they click is not an activity link | 23:23 |
| replaceafill | before i get there | 23:23 |
| replaceafill | you had: menu = e.target.parentNode.parentNode.firstElementChild | 23:24 |
| replaceafill | that's traversing the DOM | 23:24 |
| replaceafill | again, jquery provides methods for traversing using ids and classes | 23:24 |
| replaceafill | like parentsUntil(selector) | 23:24 |
| aelkner | what does that do? | 23:24 |
| replaceafill | it gets you all the parent elements that match the selector | 23:25 |
| replaceafill | $(this).parent().prev('ul.popup_menu').addClass('activity_menu'); | 23:25 |
| aelkner | yeah, i don't get that one | 23:26 |
| replaceafill | there ^ im refering to the link (the title of the activity) | 23:26 |
| replaceafill | the one the user does click on | 23:26 |
| replaceafill | does click on -> clicks on :) | 23:26 |
| replaceafill | so, this is the <a ...> element in the dom | 23:26 |
| replaceafill | $(this) makes it a jquery object | 23:27 |
| replaceafill | with jquery methods | 23:27 |
| replaceafill | this is very important | 23:27 |
| aelkner | that part i got | 23:27 |
| replaceafill | ok | 23:27 |
| replaceafill | then jquery objects have a parent() method | 23:27 |
| replaceafill | (i suppose you know what it does) | 23:27 |
| aelkner | the same as parentNone? | 23:27 |
| replaceafill | and jquery objects have a .prev(selector) | 23:27 |
| replaceafill | method | 23:27 |
| aelkner | parentNode | 23:27 |
| replaceafill | but your traversing depends on the node | 23:28 |
| replaceafill | jquerys depend on selectors | 23:28 |
| aelkner | so parent() applies to all elements selected | 23:28 |
| aelkner | no sorry, that's not what i meant | 23:28 |
| replaceafill | no, to the element you clicked on | 23:28 |
| aelkner | $(this) is a specific node | 23:28 |
| aelkner | and .parent() is its parent ode | 23:29 |
| replaceafill | it's a jquery object for its parent node :) | 23:29 |
| aelkner | right, everything stays wrappend in jquery | 23:29 |
| replaceafill | remember, jquery != node | 23:29 |
| replaceafill | correct | 23:29 |
| replaceafill | so, you get the parent as a jquery object | 23:29 |
| replaceafill | and then | 23:29 |
| replaceafill | the html produced is: | 23:30 |
| replaceafill | <div class="idontremember"> | 23:30 |
| replaceafill | <ul class="popup"> | 23:30 |
| replaceafill | <li>s | 23:30 |
| replaceafill | </ul> | 23:30 |
| replaceafill | <div> | 23:30 |
| replaceafill | <a> | 23:30 |
| replaceafill | hold on | 23:30 |
| replaceafill | let me start the instance better... :) | 23:30 |
| replaceafill | <div class="padded"> | 23:31 |
| replaceafill | <ul class="popup_menu"> | 23:31 |
| replaceafill | <li> | 23:31 |
| replaceafill | <span>A1</span> | 23:31 |
| replaceafill | </li> | 23:31 |
| replaceafill | </ul> | 23:32 |
| replaceafill | <div> | 23:32 |
| replaceafill | <a class="activity_heading" | 23:32 |
| replaceafill | href="gradeActivity.html?activity=Activity" | 23:32 |
| replaceafill | title="A1">A1</a> | 23:32 |
| replaceafill | </div> | 23:32 |
| replaceafill | the user clicks on a.activity_heading | 23:32 |
| replaceafill | that's "this" in that method | 23:32 |
| replaceafill | parent gets you to the plain <div> | 23:32 |
| replaceafill | then you have .prev('ul.popup_menu') | 23:32 |
| replaceafill | prev and next are for finding siblings | 23:32 |
| * hoffman goes to make dinner. | 23:32 | |
| replaceafill | children of the same parent | 23:33 |
| hoffman | I can talk to aelkner later about the hiding implementation. | 23:33 |
| replaceafill | aelkner so, prev(...) gives us the list | 23:34 |
| replaceafill | and we finally add a class to it | 23:34 |
| replaceafill | i called it "activity_menu" | 23:34 |
| aelkner | so prev() and next() are again more powerful than regular js because they support selectors | 23:34 |
| replaceafill | correct :) | 23:34 |
| replaceafill | i mean, you can do all of this in plain javascript, but it's really painful :( | 23:35 |
| aelkner | well, i did it, and it didn't kill me, but i see that jquery is nicer | 23:35 |
| aelkner | and using selectors is very convenient | 23:35 |
| replaceafill | it's because you're too good | 23:35 |
| replaceafill | :P | 23:35 |
| aelkner | gee thanks, i just used firebug and found the methods there :) | 23:36 |
| replaceafill | :D | 23:36 |
| replaceafill | ok | 23:36 |
| replaceafill | finally, the comparison | 23:36 |
| replaceafill | if ($(e.target).hasClass('activity_heading') == false) { | 23:36 |
| replaceafill | e.target is again a dom element | 23:36 |
| replaceafill | where the element was carried | 23:36 |
| replaceafill | sorry | 23:36 |
| replaceafill | where the event was carried | 23:37 |
| replaceafill | this is a click event, so it means the dom element you clicked on | 23:37 |
| aelkner | which element they clicked basically | 23:37 |
| replaceafill | correct :) | 23:37 |
| replaceafill | see that this is bind to the document | 23:37 |
| replaceafill | $(document).click(function(e) { | 23:37 |
| replaceafill | that's why you need e.target instead of this | 23:38 |
| aelkner | yep | 23:38 |
| replaceafill | so, you check that the <a ...> element has an activity | 23:38 |
| replaceafill | sorry, that doesnt have the class activity | 23:38 |
| replaceafill | damn! | 23:39 |
| replaceafill | that the element doesnt have the 'activity_heading' class | 23:39 |
| replaceafill | :) | 23:39 |
| replaceafill | which only activity titles have | 23:39 |
| replaceafill | meaning: they clicked anywhere but an activity title | 23:39 |
| aelkner | i see that you hide the current menu if they click anywhere but an activity title | 23:40 |
| aelkner | but what if they click on the activity menu itself | 23:40 |
| aelkner | not a link, but on one of the <li> elements | 23:40 |
| aelkner | ah, wait | 23:41 |
| replaceafill | the menu is hiddent | 23:41 |
| replaceafill | and they're taken to the link | 23:41 |
| replaceafill | see that there's no "return false;" | 23:41 |
| replaceafill | preventing clicks | 23:41 |
| aelkner | the <li> element contains the <a> | 23:41 |
| replaceafill | and this check is for <a> | 23:42 |
| replaceafill | the a.activity_heading to be specifi | 23:42 |
| replaceafill | c | 23:42 |
| replaceafill | links in the popup menu dont have this class | 23:42 |
| replaceafill | only activity titles | 23:42 |
| aelkner | the logic reads: | 23:42 |
| aelkner | if they clicked on anything other than an element with class activity | 23:43 |
| aelkner | activity_heading | 23:43 |
| aelkner | then make the menu disappear | 23:43 |
| aelkner | so if they click inside the <li> but not inside the <a> contained in the <li>, what then? | 23:44 |
| aelkner | i would think, in that case, the current menu should stay active | 23:44 |
| replaceafill | a.activity_heading are not in the li aelkner | 23:44 |
| aelkner | so the test passes and te men u is hidden | 23:45 |
| aelkner | == false | 23:45 |
| replaceafill | again, note the e.target | 23:45 |
| aelkner | strange that you don't see my point here, e.target would be the <li> | 23:46 |
| aelkner | the test for == flase would pass | 23:46 |
| replaceafill | no!!!!!!!!!! | 23:46 |
| replaceafill | see the html!! | 23:46 |
| replaceafill | ^^^ | 23:46 |
| aelkner | see what html? | 23:47 |
| aelkner | the page template has it, what are you referring to? | 23:48 |
| aelkner | the <li> in the page template? | 23:48 |
| replaceafill | http://pastebin.com/4Bn4rUGM | 23:48 |
| replaceafill | the output html | 23:48 |
| aelkner | so the <li> elements there have no class="activity_heading" | 23:49 |
| replaceafill | :/ | 23:49 |
| aelkner | so if one clicks on one, the test will pass | 23:49 |
| replaceafill | yep | 23:49 |
| aelkner | and the menu will be hidden | 23:49 |
| replaceafill | and you get to the link page | 23:49 |
| replaceafill | you dont stay on that page | 23:49 |
| aelkner | why would clicking on a <li> cause a link to be visited? | 23:50 |
| aelkner | only clicking on <a> does that | 23:50 |
| aelkner | do you see now what i mean? | 23:50 |
| aelkner | the <li> contains the <a>, but there is space in the <li> that is not inside the <a> | 23:51 |
| replaceafill | no | 23:51 |
| replaceafill | ok, let's slow down | 23:51 |
| replaceafill | that test is only for titles of activities, correct? | 23:52 |
| replaceafill | like "Quiz", "Exam1" etc | 23:52 |
| aelkner | what test? | 23:52 |
| replaceafill | $(e.target).hasClass('activity_heading') == false | 23:52 |
| aelkner | that test says, if the clicked element is not the activity link | 23:53 |
| aelkner | that's obvious | 23:53 |
| replaceafill | yes | 23:53 |
| aelkner | so you hide the active menu if anything other than the activity link is clicked | 23:53 |
| replaceafill | correct | 23:53 |
| aelkner | so if the user clicks an <li>, but not the <a> contained therin | 23:54 |
| replaceafill | because you could have clicked on another activity title | 23:54 |
| aelkner | the menu disappears | 23:54 |
| replaceafill | aelkner!!! | 23:54 |
| replaceafill | the <a> you're referring to are not activity titles | 23:54 |
| replaceafill | they are menu options | 23:54 |
| aelkner | i know that | 23:54 |
| aelkner | so? | 23:54 |
| replaceafill | so if you click on one of those, the menu is hidden | 23:54 |
| replaceafill | correct? | 23:55 |
| aelkner | if you click on one of the <a> elements inside the menu? | 23:55 |
| replaceafill | yes | 23:55 |
| aelkner | then the link is visited and the whole page is reloaded | 23:55 |
| replaceafill | yes... | 23:56 |
| aelkner | i'm not referring to that | 23:56 |
| aelkner | i'm talking about the <li> | 23:56 |
| aelkner | clicking on the <li> i sot the same as clicking on the <a> it contains | 23:57 |
| replaceafill | sot? | 23:57 |
| aelkner | tell me understand that point, please | 23:57 |
| aelkner | i've been saying it a million times, i don't know how to say it differently | 23:58 |
| replaceafill | :D | 23:58 |
| aelkner | sot -> not | 23:58 |
| aelkner | sorry | 23:58 |
| aelkner | didn't see the typo | 23:58 |
| replaceafill | :) | 23:58 |
| replaceafill | ok, you start over this time... | 23:58 |
| aelkner | ok, i'm referring to the logic for handling the user clicks on the <li> of an active menu | 23:59 |
| aelkner | but not on the <a> therein | 23:59 |
| aelkner | the test == false will pass | 23:59 |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!
