* th1a and aelkner just finished talking on the phone. | 00:11 | |
aelkner | replaceafill, we need to talk about two things that i can hopefully take over by the end of the week | 00:12 |
---|---|---|
replaceafill | aelkner yes? | 00:12 |
th1a | the end of tomorrow ;-) | 00:12 |
aelkner | 1) making edit views modal (the ajaz for errors issue) | 00:12 |
aelkner | 2) making relationship views modal | 00:13 |
aelkner | ok, the end of tomorrow | 00:13 |
aelkner | wiat, tomorrow is thursday | 00:13 |
aelkner | sorry, losing track of the week a second there | 00:13 |
th1a | The week ends on Friday. | 00:13 |
th1a | ;-) | 00:14 |
replaceafill | aelkner i'm making calendar_selection.html modal | 00:14 |
replaceafill | and i hope that's a good example for you to follow | 00:14 |
th1a | So that's a relationship one. | 00:14 |
aelkner | so can i help? | 00:14 |
replaceafill | aelkner you should take a look at the inline view for courses in my jquery-ui branch | 00:14 |
replaceafill | i'm doing the same with calendar_selection | 00:14 |
aelkner | will there be something for me to merge later tonight? | 00:16 |
aelkner | i'd like to look at it and grok it together with the courses one | 00:16 |
Lumiere | hi guys | 00:17 |
replaceafill | aelkner i think so | 00:17 |
replaceafill | aelkner no, you will have something | 00:17 |
replaceafill | :) | 00:17 |
* Lumiere just realized his account on opn/fn turns 10 this week! | 00:17 | |
aelkner | Lumiere, the guy who's always there, but hardly ever speaks | 00:17 |
aelkner | who's it going? | 00:17 |
* Lumiere is now in San Antonio, TX | 00:18 | |
Lumiere | Working for RAX | 00:18 |
aelkner | ah, that's right, jelkner told me | 00:18 |
Lumiere | so I am only 2 hours into my shift | 00:18 |
aelkner | sounds like a good place | 00:18 |
Lumiere | hotter than **** here | 00:20 |
aelkner | that's what AC is for :) | 00:21 |
aelkner | you texans know how to contribute to global worming! | 00:22 |
aelkner | replaceafill, can we talk about CourseInlineAddView? | 00:24 |
aelkner | you could save me time by explaining the reason for the various methids | 00:25 |
replaceafill | aelkner hold on | 00:25 |
replaceafill | i'm on something | 00:25 |
replaceafill | give me 10 mins | 00:25 |
aelkner | ok | 00:26 |
replaceafill | th1a you there? | 00:34 |
replaceafill | aelkner ok, ready | 00:36 |
replaceafill | ... | 00:41 |
replaceafill | ... | 00:46 |
replaceafill | :) | 00:46 |
* replaceafill goes get some coffee | 00:46 | |
aelkner | replaceafill, ready | 00:53 |
replaceafill | k | 00:54 |
replaceafill | i just pushed a change to my modal_test branch in case you want to see it | 00:54 |
replaceafill | to make calendar_selection modal | 00:54 |
aelkner | ok, looking... | 00:54 |
replaceafill | both examples still suck, but they're providing the pattern we're looking for | 00:55 |
replaceafill | the thing with calendar_selection is the same as with preferences, they don't do validation | 00:55 |
replaceafill | so, no ajaxy stuff happens | 00:56 |
aelkner | launchpad is going down in 5 minutes, so i merged | 00:56 |
replaceafill | :| | 00:56 |
replaceafill | cool | 00:56 |
replaceafill | aelkner you could see that change in: http://69.164.203.135:54222/ | 00:57 |
replaceafill | log in as teacher001/teacher001 | 00:57 |
replaceafill | go to Calendar | 00:57 |
replaceafill | hit Manage | 00:57 |
replaceafill | and you will see the dialog | 00:57 |
aelkner | nice | 00:59 |
replaceafill | it's the same thing we did with preferences | 00:59 |
aelkner | yeah, no erros possible | 01:00 |
replaceafill | we can talk inline course if you want | 01:00 |
replaceafill | you do need ajax there | 01:00 |
aelkner | finally :) | 01:00 |
replaceafill | ¬¬ | 01:00 |
replaceafill | ok, you wanted me to explain the methods, right_ | 01:00 |
aelkner | look at all those methods that deliver html | 01:00 |
aelkner | or i should say, js | 01:01 |
replaceafill | yes, js | 01:01 |
replaceafill | the thing is | 01:01 |
replaceafill | inside the dialog, you need js | 01:01 |
replaceafill | or at much submit buttons | 01:01 |
replaceafill | because the dialog cannot submit to itself | 01:02 |
replaceafill | there's no way to refresh dialogs | 01:02 |
replaceafill | (at least i havent found any) | 01:02 |
replaceafill | so the buttons in the dialog have to be very smart | 01:02 |
aelkner | wait | 01:03 |
aelkner | if that's the task you need done, how about a bit of out of the box thinking | 01:03 |
* replaceafill listens | 01:03 | |
aelkner | could we have a way to let the dialog disappear, but with a redirect back to it with the errors in the request | 01:04 |
aelkner | you know what, forget it | 01:04 |
aelkner | it would be better if we used ajax | 01:04 |
replaceafill | :) | 01:04 |
replaceafill | so... | 01:05 |
replaceafill | course inline view has two buttons | 01:05 |
replaceafill | and all those methods just do that, create two smart js buttons | 01:05 |
replaceafill | cancel is not that smart | 01:05 |
replaceafill | it just looks for the dialog and closes it | 01:05 |
replaceafill | look at the cancel button i just did for modal_test | 01:05 |
replaceafill | i used the id directly | 01:06 |
replaceafill | course inline view looks for the right dialog | 01:06 |
replaceafill | one is more "dynamic" than the other | 01:06 |
replaceafill | wanna talk about the Add button? | 01:07 |
replaceafill | the one doing ajaxy stuff | 01:07 |
replaceafill | it uses jquery.post | 01:07 |
replaceafill | http://api.jquery.com/jQuery.post/ | 01:07 |
replaceafill | passing the url to handle the request | 01:08 |
replaceafill | the form data | 01:08 |
replaceafill | and a js function to handle the response | 01:08 |
replaceafill | so, when you click 'Add' only jquery.post is called | 01:08 |
replaceafill | and it's the js callback the one that checks you got no errors | 01:09 |
replaceafill | that js callback is rendered by "def handlerScript" | 01:09 |
replaceafill | all clear aelkner? | 01:11 |
aelkner | jQuery.post() takes scripts as parms | 01:12 |
replaceafill | js functions | 01:12 |
replaceafill | (url, data, function) | 01:13 |
replaceafill | you call url using post request passing data | 01:13 |
replaceafill | then you get the response back as html | 01:13 |
replaceafill | and you do whatever you want with it in "function" | 01:13 |
aelkner | when are wanting to do something? | 01:14 |
replaceafill | ? | 01:15 |
aelkner | in order to post? | 01:15 |
aelkner | during the post? | 01:15 |
replaceafill | after the post | 01:15 |
replaceafill | you send "data" to "url" using a html post, right? | 01:15 |
aelkner | what to do with the resonse | 01:15 |
replaceafill | then you get a "result" back (the response) | 01:15 |
replaceafill | html | 01:16 |
aelkner | i got it | 01:16 |
aelkner | you often will put the result into the DOM | 01:16 |
replaceafill | in this case (course inline view) | 01:16 |
aelkner | in our case errors into the errors div | 01:16 |
replaceafill | i check for errors in the form (response) | 01:16 |
replaceafill | if there are errrors, i insert them back into the form | 01:17 |
replaceafill | if there are no errors, i redirect using window.location | 01:17 |
aelkner | does that close the dialog? | 01:17 |
replaceafill | the "insert errors back in the form" part is important | 01:17 |
replaceafill | redirecting? | 01:17 |
replaceafill | yes | 01:17 |
replaceafill | you just go to a new schooltool view | 01:18 |
aelkner | and by doing so, the dialog disappears | 01:19 |
replaceafill | yep | 01:19 |
aelkner | you know, that's really convenient, i mean that the modal dialog is not | 01:19 |
replaceafill | a more cleaner scenario would involve centralizing all these "onclicks" | 01:19 |
aelkner | really anywhere different than the page it's on top of | 01:19 |
aelkner | so moving from it is the same as moving from the page that's below | 01:20 |
aelkner | and then the redirect takes you back to whereyou want to go | 01:20 |
replaceafill | correct | 01:20 |
replaceafill | a true ajaxy aproach would popup the dialog | 01:21 |
replaceafill | accept input, proccess | 01:21 |
replaceafill | and refresh the page where the dialog was popped up | 01:21 |
replaceafill | without full reload | 01:21 |
aelkner | yes, we can do that, too eventually | 01:21 |
replaceafill | suppose you're in the course container with only two existing Courses | 01:21 |
replaceafill | Chemistry and Physics | 01:21 |
replaceafill | you get the dialog, fill with Math, hit Add | 01:22 |
replaceafill | the new course is inserted in the courses view using ajax | 01:22 |
replaceafill | no full reload | 01:22 |
replaceafill | but yes | 01:22 |
replaceafill | let's first do this ;) | 01:22 |
replaceafill | can i do a last comment on this? | 01:23 |
replaceafill | make! | 01:23 |
replaceafill | i always get confused by do vs make ;) | 01:23 |
replaceafill | as i was saying, having functions with meaningful names would be better | 01:23 |
replaceafill | like processNewCourse | 01:24 |
replaceafill | or something | 01:24 |
aelkner | instead of handlerScript? | 01:24 |
replaceafill | with handlerScript logic | 01:24 |
aelkner | yeah, but the clearer name | 01:24 |
replaceafill | sure, but a function | 01:24 |
aelkner | it would be nice, if a method is to return js (esentually an ajax method) | 01:25 |
aelkner | that it would have a prefix | 01:25 |
replaceafill | that function would only need the handler url for post | 01:25 |
replaceafill | right | 01:25 |
aelkner | like ajaxProcessNewCours | 01:25 |
replaceafill | whatever, but outside of z3c.form | 01:25 |
*** alga has quit IRC | 01:25 | |
replaceafill | just putting it back in js files | 01:26 |
aelkner | ? | 01:26 |
replaceafill | all this js logic is in a z3c.form | 01:26 |
aelkner | the library, you mean | 01:26 |
aelkner | there is a call that you can pass the url and form to? | 01:27 |
replaceafill | what do you mean? | 01:32 |
aelkner | all this logic, what logic | 01:32 |
replaceafill | the string returned by handlerScript | 01:33 |
aelkner | go on | 01:34 |
replaceafill | look for references to self.context or self.request in all those methods | 01:34 |
replaceafill | you need four of them | 01:34 |
replaceafill | the id of the form | 01:35 |
replaceafill | the id of the 'Add' button | 01:35 |
replaceafill | and self.context and self.request to calculate the url to send the data | 01:35 |
replaceafill | we could get rid of the first two with conventions | 01:35 |
replaceafill | naming all the buttons with this behaviour (add things through javascript) the same | 01:36 |
replaceafill | and naming all forms with this behaviour the same | 01:36 |
replaceafill | then you could move most of this code to a static js | 01:36 |
replaceafill | it's the same solution i did with the gradebook | 01:36 |
replaceafill | moving static things out of the view | 01:36 |
replaceafill | by things i mean code :) | 01:37 |
replaceafill | js code | 01:37 |
replaceafill | anyhow... | 01:37 |
replaceafill | you'll get all these answers after you've coded like 10 cases ;) | 01:37 |
replaceafill | any other question/comment aelkner? | 01:38 |
aelkner | so the course inline that we've been discussing works | 01:38 |
aelkner | so it's model for creating dialogs that retain active status when errors come back | 01:39 |
replaceafill | correct | 01:39 |
aelkner | yes, i can figure out how to do another one now | 01:40 |
replaceafill | my advice, do: Add Groups | 01:40 |
aelkner | we don't need to worry about whether there is something in z3c.form that we could use | 01:40 |
aelkner | we can just generate the js ourselves for now | 01:40 |
replaceafill | sure, it's not pretty but i works | 01:40 |
aelkner | and we can put stuff in the pt file | 01:40 |
aelkner | linstead of the view class some times | 01:41 |
replaceafill | right | 01:41 |
aelkner | also, i definitely agree to the convention for ids for add forms | 01:41 |
aelkner | although, could we also use classes | 01:41 |
aelkner | well, id has the advantage of being unique | 01:42 |
aelkner | tat's your call, of course | 01:42 |
replaceafill | a class would be right when we have several dialogs in the same page | 01:44 |
aelkner | exactly | 01:44 |
aelkner | and we will | 01:44 |
replaceafill | again, i suggest you to port "Add Group" | 01:44 |
replaceafill | group need titles | 01:44 |
replaceafill | so you need a little validation | 01:45 |
aelkner | ah, add group, the simple one | 01:46 |
replaceafill | yes | 01:46 |
aelkner | i was thinking a relationship | 01:46 |
aelkner | like adding a group to a person | 01:46 |
aelkner | add group is perfect | 01:46 |
replaceafill | give it a shot :) | 01:46 |
replaceafill | Add Group is the same as Add Course | 01:46 |
replaceafill | but will help you do the whole process | 01:46 |
aelkner | i agree | 01:47 |
aelkner | sounds like a plan | 01:47 |
replaceafill | cool | 01:47 |
replaceafill | let me know if i can help | 01:47 |
aelkner | thanks for the walk-though | 01:48 |
replaceafill | i'll go out for a while but i plan to work tonigh | 01:48 |
replaceafill | so i'll be around | 01:48 |
replaceafill | np | 01:48 |
aelkner | i learned a lot | 01:48 |
replaceafill | :) | 01:48 |
* replaceafill goes out | 01:51 | |
aelkner | cool, catch you later | 01:51 |
*** replaceafill has quit IRC | 01:51 | |
*** ignas has quit IRC | 01:52 | |
*** menesis has quit IRC | 02:04 | |
*** replaceafill has joined #schooltool | 02:42 | |
*** th1a_ has joined #schooltool | 04:24 | |
*** aks has joined #schooltool | 06:08 | |
*** aks has joined #schooltool | 06:08 | |
*** replaceafill has quit IRC | 06:28 | |
*** replaceafill has joined #schooltool | 06:37 | |
*** th1a has quit IRC | 06:45 | |
*** replaceafill has quit IRC | 08:45 | |
*** yvl has joined #schooltool | 09:06 | |
*** dadeng has joined #schooltool | 09:30 | |
*** th1a_ has quit IRC | 10:02 | |
*** menesis has joined #schooltool | 10:17 | |
*** alga has joined #schooltool | 10:40 | |
*** menesis has quit IRC | 13:01 | |
*** dadeng has quit IRC | 13:55 | |
*** aks has quit IRC | 14:21 | |
*** menesis has joined #schooltool | 14:22 | |
*** dadeng has joined #schooltool | 14:44 | |
*** replaceafill has joined #schooltool | 15:26 | |
*** dadeng has quit IRC | 15:49 | |
*** dadeng has joined #schooltool | 15:56 | |
yvl | OMG, it's meeting time! | 16:30 |
aelkner | hey yvl | 16:30 |
* yvl runs of to quickly make coffee | 16:30 | |
yvl | hi aelkner :) | 16:30 |
yvl | meanwhile: https://code.launchpad.net/~schooltool-owners/schooltool/flourish | 16:34 |
yvl | our new sprint branch ;) | 16:35 |
aelkner | yay | 16:35 |
*** th1a has joined #schooltool | 16:35 | |
th1a | Hey guys. | 16:35 |
yvl | check it out, and, well check it out :) | 16:35 |
yvl | hi th1a | 16:35 |
yvl | hey replaceafill ;) | 16:35 |
replaceafill | hey everybody :) | 16:36 |
th1a | We had a violent thunderstorm last night. | 16:36 |
th1a | Lots of trees down. | 16:36 |
th1a | Took me a while to get back from dropping Vivian off. | 16:36 |
th1a | Ah, ok, I didn't miss much. | 16:37 |
th1a | So... today... yvl update on flourish. | 16:37 |
th1a | Talking CSS with replaceafill. | 16:38 |
aelkner | between trees and the potholes, it's a wonder you can get anywhere :) | 16:38 |
th1a | Update on jus. | 16:38 |
th1a | js | 16:38 |
aelkner | au jus | 16:38 |
*** dadeng has quit IRC | 16:39 | |
th1a | The meeting with schwa design went well yesterday. | 16:39 |
yvl | cool | 16:39 |
* yvl is eager to hear more | 16:39 | |
th1a | Nothing in particular to report... the tech guy on the team actually works with several local schools. | 16:39 |
th1a | And they did some design work last year for the local charter school, which I'd noticed was pretty good. | 16:40 |
th1a | So we should have an estimate next week. | 16:40 |
yvl | great! | 16:40 |
yvl | if you mange to remember the url to that charter school, it would be nice | 16:40 |
th1a | http://highlandercharter.org/index.php | 16:41 |
th1a | They're interested in an ongoing relationship, which I would want as well. | 16:41 |
th1a | OK... | 16:41 |
th1a | yvl: Where are we? | 16:42 |
yvl | ok... | 16:42 |
yvl | to reiterate - https://code.launchpad.net/~schooltool-owners/schooltool/flourish | 16:42 |
yvl | our new sprint branch | 16:42 |
yvl | I finally moved content providers to flourish namespace | 16:42 |
yvl | and re-arranged some of the other stuff | 16:43 |
yvl | ran into few fun potholes in Zope, worked around them | 16:43 |
aelkner | like what? | 16:43 |
yvl | like trusted locating adapter factories wrapping None into security proxies | 16:43 |
yvl | then into location proxies | 16:44 |
yvl | that resuling into bogus getAdapter results | 16:44 |
aelkner | :) | 16:44 |
yvl | also, there I didn't do something right with certain permission declarations for viewlets | 16:44 |
yvl | I think zope.viewlet may also have the same drawbacks | 16:45 |
yvl | will need to fix it... later | 16:45 |
yvl | also, ported person index.html and edit.html | 16:45 |
th1a | What are the implications of this problem? | 16:45 |
yvl | at some rare points security mechanism will fail | 16:46 |
th1a | Fail and expose sensitive data? | 16:46 |
yvl | other way around | 16:46 |
th1a | That's better. | 16:47 |
yvl | but that will always be obvious | 16:47 |
yvl | it's just that we have "some" limitations on writing viewlets | 16:47 |
yvl | and breadcrumbs | 16:47 |
th1a | OK. | 16:47 |
yvl | I don't know what exactly those are | 16:47 |
yvl | just stumbled into one scenario | 16:47 |
yvl | we'll fix it - later | 16:48 |
yvl | so, currently flourish is actually somewhat operational | 16:48 |
yvl | you can even add person | 16:48 |
yvl | (you'll get a traceback or not found after that, but the person is there) | 16:48 |
yvl | and you can consider person add and edit views as simple examples of porting | 16:49 |
yvl | persons also have an "Edit" action button | 16:49 |
yvl | which is an example of adding action buttons to content | 16:49 |
yvl | also | 16:49 |
th1a | Is that the same branch location I already have? | 16:49 |
yvl | no, I think you have my personal branch | 16:50 |
yvl | please run bzr info and check if its justas-pov or schooltool-owners | 16:50 |
yvl | if replaceafill writes his own LinkViewlet | 16:50 |
th1a | Right. | 16:50 |
yvl | he can add JS and link IDs he needs | 16:50 |
yvl | for modal forms | 16:50 |
replaceafill | great! | 16:50 |
aelkner | LinkViewlet? | 16:51 |
yvl | hopefully it is self-explanatory | 16:51 |
th1a | OK, so we can all pile in then? | 16:51 |
yvl | aelkner, in schooltool.skin.flourish.page | 16:51 |
yvl | it's a class I currently use for links | 16:52 |
yvl | <flourish:viewlet | 16:52 |
yvl | name="site-preferences.html" | 16:52 |
yvl | title="Site Preferences" | 16:52 |
yvl | class="schooltool.skin.flourish.page.LinkViewlet" | 16:52 |
yvl | manager="schooltool.app.browser.app.ManageSiteLinks" | 16:52 |
yvl | permission="schooltool.edit" | 16:52 |
yvl | /> | 16:52 |
yvl | <flourish:viewlet | 16:53 |
yvl | name="edit_person" | 16:53 |
yvl | link="edit.html" | 16:53 |
yvl | title="Edit" | 16:53 |
yvl | for="schooltool.basicperson.interfaces.IBasicPerson" | 16:53 |
yvl | view="schooltool.basicperson.browser.person.FlourishPersonView" | 16:53 |
yvl | manager="schooltool.skin.flourish.page.IContentActionsManager" | 16:53 |
yvl | class="schooltool.skin.flourish.page.LinkViewlet" | 16:53 |
yvl | permission="schooltool.edit" | 16:53 |
yvl | html_class="modify" | 16:53 |
yvl | /> | 16:53 |
*** dadeng has joined #schooltool | 16:53 | |
yvl | first one adds link to a Manage Site box on the left of a certain page | 16:53 |
yvl | latter one adds action button to main content of person index.html | 16:53 |
yvl | declarations are overkill at the moment, but they *will* be minimised | 16:54 |
yvl | with helpers like flourish:action_button, once I write them | 16:54 |
th1a | OK, what's an action button? | 16:54 |
yvl | if you remember test.html ... | 16:55 |
th1a | Yeah... I don't think I want those. | 16:55 |
yvl | I'm not saying they should be there | 16:55 |
yvl | but we do need them | 16:55 |
th1a | OK. | 16:55 |
yvl | the concept | 16:55 |
th1a | What, why? | 16:55 |
yvl | say, we're looking at... a course | 16:56 |
yvl | we want to change the title | 16:56 |
yvl | we need to clikc something | 16:56 |
yvl | or, say, we're looking at the user | 16:56 |
yvl | we need to click something to change his password | 16:57 |
th1a | OK, let's not call anything an action button in flourish. | 16:57 |
yvl | :D | 16:57 |
th1a | We have secondary navigation. | 16:57 |
yvl | can I call them actions? | 16:57 |
th1a | Which is tabbish. | 16:57 |
yvl | hmm | 16:57 |
th1a | Correct? | 16:57 |
yvl | and what about "change password" pop-ups? | 16:57 |
yvl | they're not navigation | 16:57 |
th1a | We have several things... | 16:58 |
th1a | We have links in the sidebar. | 16:58 |
yvl | frankly, I don't care that much where and how the concept ends up | 16:58 |
th1a | Well, I do, so I'm trying to make it clear. | 16:58 |
yvl | but navigation needs to be separate from actions | 16:58 |
th1a | I'm saying: | 16:58 |
th1a | - secondary navigation (tabbish) | 16:58 |
th1a | - sidebar ("actions," more or less, including ones added externally) | 16:59 |
th1a | - plain old links coded into the content of the page. | 16:59 |
th1a | Those are the bags. | 16:59 |
th1a | And the third isn't really a bag. | 17:00 |
th1a | And the second is a bag of bags. | 17:00 |
th1a | Are we on the same page here? | 17:00 |
yvl | I see your point | 17:00 |
yvl | more Launchpad style | 17:01 |
yvl | a good point, actually | 17:01 |
th1a | I've learned my job is to be design enforcer. | 17:02 |
yvl | :) | 17:02 |
yvl | well | 17:02 |
yvl | I have a "by authority" counter-argument | 17:02 |
yvl | but I won't push my point | 17:03 |
yvl | I mean - the action buttons on top of content aren't bad | 17:03 |
yvl | really | 17:03 |
yvl | they are good | 17:03 |
yvl | just one style of doing this | 17:03 |
yvl | we can put them hard-wired inside content | 17:04 |
yvl | that's also good | 17:04 |
th1a | It gives us control of the presentation. | 17:04 |
th1a | And links in the sidebar is more fault-tolerant. | 17:05 |
yvl | um? | 17:05 |
yvl | oh, yes | 17:05 |
yvl | basically I'm adovcating action buttons | 17:05 |
yvl | because they work pretty well like pop-ups | 17:05 |
yvl | say | 17:05 |
yvl | all links in side-bar are not modal | 17:05 |
yvl | links as action buttons can be modal or in-place | 17:06 |
yvl | you suggest to hard-wire the (previously action button) links to a page | 17:06 |
yvl | like this: | 17:06 |
yvl | John Peterson | 17:06 |
yvl | something something | 17:06 |
yvl | (change password) | 17:07 |
yvl | which is also nice | 17:07 |
yvl | there is no plugabillity in this case | 17:07 |
yvl | but it is probably fine | 17:07 |
th1a | The plugability mostly goes in the sidebar. | 17:07 |
yvl | yes | 17:07 |
th1a | We may make persons a special pluggable accordion eventually. | 17:08 |
yvl | ? | 17:08 |
yvl | well ok | 17:08 |
th1a | That's down the road. | 17:08 |
th1a | But it is an obvious route. | 17:08 |
yvl | I really have trouble seeing benefits of accordeon *there* | 17:08 |
th1a | Basically it is relatively fault-tolerant design wise if you start adding a bunch of crap. | 17:09 |
th1a | And you don't have to come up with a fancy way of laying out a dynamic page, etc. | 17:09 |
yvl | hmm | 17:09 |
th1a | I'm not saying it is perfect. We need to play with the accordion thing more anyhow. | 17:09 |
yvl | I see your point, but I don't really agree to it :) | 17:10 |
yvl | oh | 17:10 |
yvl | yes | 17:10 |
yvl | we do need to play with it! | 17:10 |
th1a | Let me put it this way: | 17:10 |
th1a | What I am trying to avoid is ever being forced into a situation where the page looks like absolute dogshit, could be fixed by just writing a few lines of html, but somehow we can't do that because everything is pluggable magic. | 17:11 |
th1a | Or everyone acts as if everything needs to be pluggable magic, when it really doesn't. | 17:12 |
*** dadeng has quit IRC | 17:12 | |
yvl | well this I really agree with | 17:12 |
th1a | And one implication of that is that the plug points have to be put in places where they'll do little damage if they get weedy. | 17:12 |
*** dadeng has joined #schooltool | 17:13 | |
yvl | hmm | 17:13 |
yvl | by the way | 17:13 |
yvl | don't get me wrong | 17:13 |
yvl | I'm not trying to object | 17:14 |
th1a | I don't want to be stuck with buttons floating in the middle of the content area that can't be moved because they're some kind of viewlet or whatever. | 17:14 |
th1a | I'm just trying to make sure everyone understands where this is going. | 17:14 |
yvl | obviously we're trying to achieve the same thing | 17:15 |
yvl | just from different perspectives | 17:15 |
yvl | I mean - mine is quite close to the actual code | 17:15 |
th1a | Which can be a perilous situation. ;-) | 17:15 |
yvl | ending up in some "in violent agreement" situations | 17:16 |
yvl | right | 17:16 |
yvl | ok | 17:16 |
yvl | this is actually a very good point to experiment | 17:16 |
yvl | it's UI sprint and whatnot | 17:17 |
yvl | if you guys are in no hurry | 17:17 |
th1a | replaceafill & aelkner: You following this? | 17:17 |
aelkner | it's all theoretical at this point | 17:17 |
replaceafill | th1a yes | 17:17 |
aelkner | first, we need to discuss process | 17:18 |
aelkner | we now have a central branch | 17:18 |
yvl | ok, if you can give me 5 minutes to formulate what I want to put on the table... :) | 17:18 |
th1a | Well, we need to discuss what the defined viewlet managers are, right? | 17:18 |
aelkner | that wouldn't hurt | 17:19 |
* yvl takes a 3 min break to think about ActionLink s | 17:19 | |
*** asharma has joined #schooltool | 17:20 | |
* yvl back | 17:22 | |
yvl | th1a, you gave good food for thought | 17:23 |
yvl | let me talk a little about my approach on plugability in this implementation | 17:23 |
yvl | I am trying to split things into small renderable things | 17:24 |
yvl | we have similar concepts all over schooltool, just not consistent | 17:24 |
yvl | for example, the person view | 17:24 |
yvl | groups, sections and other stuff is added via ...person.Info manager | 17:25 |
yvl | the main part is rendered as a simple z3c display form | 17:25 |
yvl | actions and most of navigation is cramped into one humongous bar at the top | 17:26 |
aelkner | so far, so good | 17:26 |
yvl | my take is to add what you called "bags" | 17:26 |
yvl | and one central point - because you simply need one | 17:26 |
yvl | the central part is the display form | 17:27 |
yvl | it may be generic form | 17:27 |
yvl | it may be custom form - I don't want to care | 17:27 |
yvl | the rest of the person view central part is to be assembled via manager | 17:27 |
yvl | if you want, you can make that manager an accordeon | 17:27 |
yvl | in it's essence the code should work like this: | 17:28 |
yvl | th1a says - there's a lot of additional crap in person view, put that into accordeon | 17:28 |
yvl | developers specify that central viewlets should be rendered with "accordeon viewlet manager" instead of plain viewlet manager | 17:29 |
*** dadeng has quit IRC | 17:29 | |
yvl | currently I put a (non-mandatory) bag for actions on top of each of these components | 17:29 |
yvl | main | 17:29 |
yvl | groups | 17:29 |
yvl | sections | 17:29 |
yvl | etc. | 17:29 |
th1a | Literally on top of? | 17:30 |
yvl | at the moment yes | 17:30 |
yvl | but the point is it is a bag related to each component | 17:30 |
yvl | (it's not that hard to move ;) ) | 17:30 |
yvl | say, we want an "edit" button for groups | 17:31 |
yvl | we have | 17:31 |
yvl | person name and the rest of display form | 17:31 |
yvl | ---- | 17:31 |
yvl | advisors and stuff | 17:31 |
yvl | ---- | 17:31 |
yvl | groups | 17:31 |
yvl | ---- | 17:31 |
yvl | sections | 17:31 |
yvl | ---- | 17:31 |
yvl | then you have two options | 17:31 |
yvl | put the edit button in a bag of group actions | 17:32 |
yvl | (now it will get rendered on top of groups) | 17:32 |
yvl | we can move it at the bottom of groups | 17:32 |
yvl | another option is not to put it in the bag | 17:32 |
yvl | groups have their template, obviously | 17:32 |
th1a | We have to completely stop using the word action right now. | 17:33 |
th1a | Because I don't know what it means. | 17:33 |
aelkner | which word? | 17:33 |
th1a | "action" | 17:33 |
th1a | And up to this point in SchoolTool it has meant "everything." | 17:33 |
aelkner | def: a link that takes the user somewhere :) | 17:33 |
yvl | action - "a link that calls a modal dialog or follows to a new page to modify content" | 17:33 |
*** dadeng has joined #schooltool | 17:33 | |
aelkner | yvl, nice | 17:34 |
yvl | navigation - "a link that follows to a new page to view or modify any content" | 17:34 |
th1a | What is not a action? | 17:34 |
yvl | main difference - navigation is never modal dialog | 17:34 |
yvl | action is never "view" of information, always edit | 17:34 |
yvl | does this sound reasonable? | 17:34 |
th1a | How do I get back to view? | 17:34 |
aelkner | navigation | 17:35 |
yvl | from action: | 17:35 |
th1a | I action to edit and navigate to view? | 17:35 |
yvl | - via submit, cancel or other button | 17:35 |
yvl | - via breadcrumbs | 17:35 |
replaceafill | cancel navigation button :) | 17:35 |
yvl | - via other navigation link | 17:35 |
yvl | - by closing the modal dialog | 17:35 |
yvl | from navigation: | 17:35 |
yvl | - via other navigation | 17:35 |
yvl | - via breadcrumbs | 17:36 |
th1a | So one thing here is that I don't want to push to far into how the page content is created right now. | 17:36 |
th1a | I'm much, much, much, much, much more afraid that we'll do damage there than help. | 17:36 |
th1a | The content area of the page. | 17:36 |
yvl | ok, let me finish first | 17:37 |
th1a | I consider that a later iteration. | 17:37 |
yvl | it won't be long | 17:37 |
yvl | so, another option instead of putting action to a bag | 17:37 |
yvl | you can modify the groups template | 17:37 |
yvl | to contain something like : | 17:37 |
yvl | <tal:block content="context/groups/schooltool:content/edit_action"> | 17:38 |
yvl | and register it via zcml | 17:38 |
yvl | I'm done | 17:38 |
yvl | th1a, one of the things is | 17:38 |
yvl | that unless we want to write static html now | 17:39 |
yvl | we have to have at least something to put our code in | 17:39 |
yvl | say, replaceafill writes JS that takes a link and opens a dialog with a form | 17:39 |
yvl | JS should not depend on where that link is | 17:40 |
yvl | what I'm trying to say: | 17:40 |
yvl | don't worry that much if I put a link as "action" on top of content | 17:40 |
yvl | my goal is that you could say - "remove it from there, and put it in the center of a page" | 17:41 |
aelkner | and we need the code to make that easy to do | 17:41 |
yvl | or at least end up with code to make that easy to do :) | 17:42 |
aelkner | soon, i hope | 17:42 |
* yvl too | 17:42 | |
th1a | I'm not against hand-coding a lot more html than we do now. | 17:42 |
yvl | I'd like to put it this way | 17:42 |
yvl | hand-code in other places than where we do now | 17:42 |
aelkner | th1a, you mean redundant html/python code all over the app | 17:42 |
th1a | And if six weeks from now I want to move some buttons around in the content body and hear that it is impossible I'm going to fucking lose it. | 17:42 |
yvl | do I hear a definition for my next bonus? :D | 17:43 |
aelkner | :) | 17:43 |
aelkner | but seriously, that's what i am shooting for, ease of changes | 17:43 |
th1a | OK... | 17:43 |
aelkner | but there's no reason for redundant code and html all over the place | 17:43 |
aelkner | we need design of bag | 17:43 |
aelkner | we need viewlets | 17:44 |
aelkner | managers, etc. | 17:44 |
aelkner | so that when it comes time to make a page | 17:44 |
th1a | Let's talk about what will be, in terms of layout the "secondary navigation bar." | 17:44 |
aelkner | it's ust a matter of, put the link in this bag, put the html in this viewlet manager | 17:44 |
th1a | To me, that should be: | 17:44 |
th1a | something like... | 17:44 |
th1a | View | Edit | Reports | Preferences | 17:45 |
th1a | The same where ever it appears. | 17:45 |
th1a | (as relevant) | 17:45 |
th1a | I'm pretty sure we discussed this in Portugal. | 17:45 |
yvl | I'm with you | 17:45 |
th1a | Those are the rules we need to be nailing down now. | 17:47 |
yvl | secondary navigation is tabbed, right? | 17:47 |
th1a | They don't literally look like tabs at this point. | 17:47 |
yvl | you mean test.html? | 17:47 |
aelkner | and they are not navigation | 17:47 |
aelkner | they are actions | 17:48 |
th1a | In the guidelines. | 17:48 |
th1a | I'm thinking Ubuntu Web Guidelines. | 17:48 |
th1a | I'm not living in the past. | 17:48 |
th1a | We gotta MOVE ON. | 17:48 |
yvl | yes yes | 17:48 |
yvl | can you please point me where they don't look like tabs? | 17:48 |
yvl | page 19, tabs... | 17:49 |
th1a | They don't have rounded corners. | 17:49 |
yvl | ah :D | 17:49 |
th1a | Shadows, etc... | 17:49 |
yvl | a small note | 17:49 |
th1a | tabbish. | 17:49 |
yvl | in my vocabulary "tabbed" mean "have functionality of tabs" | 17:49 |
aelkner | some of the tabs could be menus, right? | 17:50 |
th1a | I'm not saying yes to aelkner at this point. | 17:50 |
aelkner | i mean Edit is not navigation, it's call up modal | 17:50 |
aelkner | the main page stays where it is | 17:51 |
aelkner | no navigation away | 17:51 |
th1a | From the user's perspective, yes, that's what would go in secondary navigation. | 17:51 |
* yvl is looking at: | 17:51 | |
yvl | View Edit Advisors Advisees Export Groups View Calendar Edit Preferences New Person Change Password Contacts Reports | 17:51 |
aelkner | well, that's important | 17:51 |
th1a | Maybe I should just call it "secondary" | 17:51 |
yvl | ok | 17:51 |
aelkner | secondary links | 17:51 |
yvl | View+Edit is one tab - the person itself | 17:52 |
yvl | Calendar may be another ? | 17:52 |
yvl | and that's it I guess | 17:52 |
th1a | View and edit are two tabs. | 17:52 |
aelkner | adn these tabs are viewlet managers, easy to customize, right | 17:52 |
aelkner | sorry, can't resist talking code there | 17:53 |
th1a | The "secondary" bar should be very limited and standardized. | 17:53 |
th1a | It might ONLY be View | Edit. | 17:53 |
th1a | (probably not) | 17:53 |
* yvl is actually thinking if we need it at all | 17:53 | |
aelkner | th1a, think about meus | 17:53 |
th1a | I'm not sure that we do need it at all. | 17:53 |
yvl | Launchpad has a nice sidebar with a box of: | 17:53 |
aelkner | our problem has partly been | 17:53 |
yvl | * Change branch details | 17:54 |
yvl | * Set branch reviewer | 17:54 |
yvl | * Delete branch | 17:54 |
aelkner | that our action links bag gets too big | 17:54 |
aelkner | that adding and action that has at least three words is forboten | 17:54 |
aelkner | you run out of screen real-estate | 17:54 |
aelkner | and menus solves that | 17:54 |
th1a | That's why we're moving things to a sidebar. | 17:54 |
th1a | And maybe we can use menus over there. | 17:54 |
aelkner | think launchpad bug view | 17:54 |
th1a | Or just in the body of the page. | 17:54 |
* yvl votes no second level nav at this point :) | 17:55 | |
aelkner | each cell has a menu button next to it | 17:55 |
th1a | I'm fine with no second level nav. | 17:55 |
aelkner | the user is used to clicking on button to find things out | 17:55 |
aelkner | so it's easy to change a bug in launchpad | 17:55 |
th1a | I'm not anti-menu in general. | 17:55 |
aelkner | you just click on something near the something you want to change | 17:55 |
yvl | give me stuff like small calendar and reports as boxes in right column, and I'm good ;) | 17:55 |
aelkner | and viola, the app teaches you what it can do | 17:56 |
th1a | aelkner: Your original question was menus in secondary navigation, right? | 17:56 |
aelkner | just saying, we can put it in the sidebar is not enough in my opinion | 17:56 |
aelkner | i mentioned them, yes | 17:56 |
th1a | That's what I was responding to. | 17:56 |
yvl | how about this: | 17:56 |
yvl | we put all links to the left sidebar | 17:57 |
yvl | and some popup links wired in the center of the page | 17:57 |
yvl | untill we figure out that is not good enough in three weeks - or not! | 17:57 |
yvl | and then re-arrange the whole damn thing | 17:57 |
th1a | Here's one specific question that has cropped up. | 17:58 |
th1a | Right now we've started embedding edit links in the individual (accordion) sections of the person view. | 17:58 |
th1a | So you open up "Advisors" and if you have permission, you get an edit link under the list of advisors. | 17:58 |
th1a | Do we want that approach, or more of a View everything only / Edit everything mode. | 17:59 |
yvl | I like that with-links approach | 17:59 |
yvl | it's closer to in-place-edit feel | 17:59 |
th1a | If we're doing that we don't need View/Edit at the top at all. | 18:00 |
replaceafill | i don't like having to protect the links :( | 18:00 |
aelkner | that is a good point | 18:00 |
yvl | replaceafill - if links are viewlets, they have permissions | 18:00 |
aelkner | but an issue we can resolve, i think | 18:00 |
yvl | if links are content, they have permissions | 18:00 |
replaceafill | yvl correct | 18:00 |
yvl | same as views | 18:00 |
yvl | not perfect, but still something | 18:00 |
th1a | OK. Now, backing up to the beginning... | 18:01 |
yvl | one moment | 18:01 |
th1a | Where are we now, yvl? | 18:01 |
th1a | :-D | 18:01 |
yvl | with this approach I'd like to settle on one thing | 18:01 |
yvl | are we manually adding the links now, or putting them into a bag | 18:02 |
yvl | before you answer | 18:02 |
yvl | it is in any case temporary | 18:02 |
yvl | I'm just wondering how that would be faster for us | 18:02 |
yvl | put them nicely now | 18:02 |
yvl | or put them "belong there", and fit them nicely later | 18:02 |
aelkner | yvl, no need to chose between them | 18:02 |
* yvl needs to | 18:02 | |
aelkner | we can design our main page/sidebars to be easy to insert/remove links | 18:03 |
aelkner | but the main page can also add any links it wants to | 18:03 |
yvl | aelkner, which implementation you need tomorrow? | 18:03 |
yvl | currently you have a bag | 18:03 |
aelkner | look, if we work together, we don't need anything tomorow | 18:03 |
yvl | I can think about the other one | 18:03 |
yvl | and maybe do it today | 18:04 |
*** dadeng has quit IRC | 18:04 | |
yvl | allright then | 18:04 |
yvl | let's make it this way | 18:04 |
yvl | register the links as damn action buttons for next few days | 18:04 |
yvl | those "edit advisors" | 18:05 |
yvl | so you can start doing modal dialogs there ;) | 18:05 |
yvl | so | 18:06 |
yvl | I would suggest you guys trying to port any random view | 18:06 |
yvl | for basic person | 18:06 |
yvl | preferably - z3c form view | 18:06 |
yvl | basically look over basicperson/browser/flourish.zcml | 18:07 |
yvl | and see how obvious/unobvious stuff is | 18:07 |
yvl | and then I could discuss code with you tomorrow | 18:07 |
yvl | you are on the same timezone, so that should be easier than working completely separately | 18:07 |
yvl | how does that sound? | 18:08 |
th1a | aelkner & replaceafill's first priority is grokking the js dialog stuff they've started. | 18:08 |
aelkner | so we are going to all push/pull from the same branch, starting now? | 18:08 |
th1a | Finishing that today. | 18:08 |
yvl | aelkner, please make your own branches | 18:08 |
th1a | So aelkner can solo on js next week. | 18:08 |
aelkner | th1a, that's already finished | 18:08 |
th1a | OK. | 18:08 |
th1a | We'll get to that report then. | 18:08 |
th1a | aelkner should branch and make merge requests, right? | 18:09 |
aelkner | what report? | 18:09 |
replaceafill | th1a i'd like some time to finish Chandara instructions too | 18:09 |
th1a | The report where aelkner tells me how the js work is coming. | 18:09 |
yvl | your daily meeting report, aelkner ;) | 18:09 |
aelkner | oh | 18:09 |
th1a | Let's get right to that. | 18:09 |
th1a | aelkner. | 18:09 |
yvl | th1a, JS will need a lot of tweaking - but that's what we have the sprint for | 18:10 |
yvl | (if we're not careful we'll end up with maintenance nightmare, but we will be) | 18:10 |
aelkner | so last night, replaceafill gave me the last walk-though of the jquery stuff | 18:11 |
aelkner | and in particular, the ajax stuff for updating the modal dialog with errors in place | 18:11 |
aelkner | that pretty much was it for doing modal dialogs | 18:12 |
aelkner | i started on the group add view which will need the ajax stuff for missing title | 18:12 |
aelkner | thing is there, the code uses base classes from schooltool skin,8 lines of code for add/edit views combined | 18:13 |
aelkner | but we never made such base classes for z3c forms and it's high time we did | 18:13 |
aelkner | i was thinking of creating a file schooltool/skin/forms.py | 18:14 |
aelkner | or maybe schooltool/app/browser/forms.py | 18:14 |
yvl | skin/flourish/form.py | 18:14 |
yvl | with their JS counterparts | 18:14 |
aelkner | sounds like a plan | 18:15 |
yvl | we'll fiddle with them until they are right | 18:15 |
aelkner | we'll need a AddForm and EditForm class there | 18:15 |
aelkner | yeah | 18:15 |
yvl | one does not walk into Mordor, sadly | 18:15 |
th1a | Please remember that add and editing objects will not mostly be done in modal forma. | 18:16 |
th1a | forms | 18:16 |
aelkner | so we need support for both | 18:16 |
yvl | yes | 18:16 |
aelkner | AddModalForm | 18:16 |
aelkner | replaceafill used AddInlineForm or View, i can't remember | 18:16 |
aelkner | can we have AddForm, EditForm, AddModalForm, EditModalForm? | 18:17 |
yvl | we'll see | 18:17 |
yvl | but something like that, yes | 18:17 |
aelkner | well, why must we wait? | 18:17 |
aelkner | someting that simple can be decided right here | 18:17 |
yvl | it's a headache, actually | 18:17 |
aelkner | ??? | 18:18 |
yvl | we'll see aelkner | 18:18 |
yvl | I don't see this that simple | 18:18 |
yvl | maybe it is | 18:18 |
aelkner | look, i don't want to 'see' anything, i want to do | 18:18 |
yvl | I think you'll need to do few views | 18:19 |
yvl | then we'll need to make decent bases | 18:19 |
aelkner | we already did a couple forms | 18:19 |
aelkner | we can talk bases now | 18:19 |
yvl | not in flourish | 18:19 |
yvl | now is a good time to pick some forms and do them from flourish branch | 18:20 |
yvl | then come the bases | 18:20 |
aelkner | ok | 18:20 |
aelkner | you spoke of person index.html view earlier | 18:20 |
aelkner | that's where i did most of my work this week | 18:20 |
aelkner | changing the view itself and the various viewlets registered against the manager you mentioned | 18:21 |
aelkner | let's talk about me getting that work into the flourish branch | 18:21 |
yvl | ok | 18:21 |
yvl | I'll be honest, I didn't follow your code changes | 18:21 |
aelkner | np, i havene't groked yours yet either :) | 18:22 |
aelkner | the point is, you mentioned changes you made to person index.html | 18:22 |
th1a | I think aelkner should charge ahead and check in some changes to flourish today. | 18:22 |
th1a | Request a merge, that is. | 18:22 |
th1a | And then have a code-based conversation tomorrow. | 18:23 |
yvl | I wonder if that would work | 18:23 |
yvl | it might | 18:23 |
yvl | maybe | 18:23 |
th1a | It might be the only thing that will work. ;-) | 18:23 |
aelkner | i need to discuss specifics to get the code added to flourish | 18:23 |
yvl | right | 18:24 |
aelkner | well, i need to read what yvl did, then change it i guess | 18:24 |
yvl | first, look at FlourishPersonView | 18:24 |
aelkner | or yvl could explain it here real quick | 18:24 |
aelkner | ok | 18:24 |
yvl | also search for it in basicperson/browser/flourish.zcml | 18:24 |
th1a | You guys speak better in code. | 18:24 |
yvl | modified templates are begin with f_* | 18:25 |
yvl | the base template was split into two: | 18:25 |
yvl | skin/flourish/templates/z3c_form_display.pt | 18:26 |
yvl | and FlourishPersinInfo view | 18:26 |
*** alga has quit IRC | 18:26 | |
yvl | with basicperson/browser/templates/f_person_view_details.pt | 18:26 |
yvl | they are exceptionally small | 18:27 |
yvl | but contain the main things you will need | 18:27 |
yvl | one of the important drawbacks, is that you can't add anything dynamic to html head | 18:27 |
yvl | no <sytle>, no <script> | 18:27 |
replaceafill | :| | 18:28 |
yvl | but those things you needed to add to head | 18:28 |
yvl | should be made static resources | 18:28 |
aelkner | why not have a viewlet manager in head? | 18:28 |
replaceafill | yvl what if they depend on info in the view? | 18:28 |
aelkner | and just let us add viewlets to that | 18:28 |
yvl | replaceafill, they should not need to | 18:28 |
yvl | JS has variables | 18:28 |
yvl | everything else is library | 18:28 |
yvl | like the rest of the world does | 18:29 |
yvl | for now you can chuck it anywhere instead of head | 18:29 |
yvl | like in f_person_view_details.pt | 18:29 |
replaceafill | by library you mean a centralized set of JS functions we code | 18:30 |
yvl | yes | 18:30 |
yvl | JS is object-oriented language, so there you go | 18:30 |
replaceafill | and do our buttons do onclick="callFoo(var1, var2)" | 18:30 |
yvl | they can | 18:31 |
replaceafill | you scared me with the non html head anymore | 18:31 |
replaceafill | :P | 18:31 |
yvl | and it is reasonable to render <script> in html | 18:31 |
replaceafill | hhmm | 18:31 |
aelkner | what do you mean in html | 18:31 |
* replaceafill doesnt like that, but ok | 18:31 | |
aelkner | that goes in head | 18:31 |
yvl | but it should be "configuration" as opposed to "definition of functions or objects" | 18:31 |
aelkner | what are we talking about here? | 18:32 |
yvl | instead of onclikc="" you can bind functions with jquery in a <script> part | 18:32 |
th1a | lol | 18:32 |
replaceafill | i like not having custom <styles> though :) | 18:33 |
yvl | replaceafill, it's a same approach | 18:33 |
replaceafill | yvl right | 18:33 |
yvl | discipline through forbidden head :D | 18:33 |
aelkner | yvl, where is this <script> part? | 18:33 |
replaceafill | :D | 18:33 |
aelkner | and <styles>? | 18:34 |
aelkner | i thought they had to go in head | 18:34 |
aelkner | isn't that html spec | 18:34 |
aelkner | help me out here, gjuys | 18:34 |
yvl | ok | 18:34 |
yvl | <styles> have to go in head | 18:34 |
yvl | but you could | 18:34 |
yvl | write a .css file | 18:34 |
yvl | and include it in head | 18:35 |
yvl | and we do have a mechanism for that | 18:35 |
replaceafill | can we restrict that ;) | 18:35 |
replaceafill | no css inclusion at all :P | 18:35 |
yvl | :P | 18:35 |
replaceafill | just the authorized css files ;) | 18:35 |
th1a | Yes! | 18:35 |
yvl | naughty naughty, making fun of lead developer and all | 18:35 |
replaceafill | sorry go on | 18:35 |
aelkner | so we're saying all css and js in resources files? | 18:35 |
th1a | Where they belong. | 18:36 |
replaceafill | yvl see!! th1a likes the idea! let's do it! | 18:36 |
replaceafill | aelkner correct | 18:36 |
aelkner | so css local to a view wold be in a file with same name as template, for instance, but with .css | 18:36 |
aelkner | and same for js? | 18:36 |
replaceafill | aelkner we talked about this yesterday, i said "a more cleaner scenario would involve centralizing all these "onclicks" | 18:36 |
yvl | of course, you will need to put some dynamic JS in html - that is inevitable - the very least in <a onclick="..."> form | 18:36 |
replaceafill | when we were making fun of the one line js | 18:36 |
yvl | but dynamic JS should be really small | 18:37 |
yvl | sometimes - none at all | 18:37 |
replaceafill | agree | 18:37 |
replaceafill | the smaller the better | 18:37 |
aelkner | and always in the body | 18:37 |
aelkner | in the onclick of an element? | 18:37 |
yvl | or in body as <script> | 18:38 |
replaceafill | aelkner remember we talke onclick in z3c.form is TextLine | 18:38 |
replaceafill | aelkner that's the reason | 18:38 |
aelkner | you can put <script> in the body? | 18:38 |
replaceafill | aelkner kind of to force you to use one liners | 18:38 |
replaceafill | aelkner yes you can | 18:38 |
aelkner | oh | 18:38 |
replaceafill | look at zc.datetimewidget for instance | 18:38 |
aelkner | and <styles>? | 18:39 |
aelkner | not right ow, please | 18:39 |
th1a | They should always be in separate files. | 18:39 |
replaceafill | well, you have the style="" attribute | 18:39 |
th1a | Don't use it. | 18:39 |
replaceafill | but DONT use it! | 18:39 |
replaceafill | :D | 18:39 |
yvl | aelkner, just for the sake of IRC logs (so you can find it later): | 18:40 |
th1a | aelkner: We want to make 95% of the CSS wrangling you do unnecessary. | 18:40 |
yvl | schooltool/skin/flourish/configure.zcml has zope:resourceLibrary directive | 18:40 |
yvl | an example how to define static resources | 18:40 |
aelkner | right, and that is handy | 18:40 |
replaceafill | th1a and the other 5% go in custom css files instead of style="..." attributes | 18:40 |
yvl | templates/main.pt has the example how to include those | 18:41 |
yvl | search for resource_library: in .pt | 18:41 |
yvl | so if you try to port | 18:41 |
yvl | your work to flourish | 18:41 |
yvl | put *everything* in page template first | 18:41 |
yvl | both <script> and <styles> part | 18:42 |
yvl | then move the <styles> part to custom .css file | 18:42 |
yvl | and include it as resource | 18:42 |
yvl | and then it will definitely be tomorrow and I will help you more | 18:42 |
th1a | Can we move toward wrapping this up? | 18:42 |
aelkner | and <script> part? | 18:42 |
yvl | in template | 18:42 |
yvl | body | 18:42 |
aelkner | ok | 18:42 |
yvl | f_person_view_detail.pt probably | 18:43 |
th1a | So if replaceafill is available and flourish is ready for the rest of the crew, | 18:43 |
aelkner | right | 18:43 |
th1a | I'd suggest a brutal insertion of the CSS included in the web guidelines. | 18:43 |
*** dadeng has joined #schooltool | 18:43 | |
replaceafill | :) | 18:43 |
aelkner | in a new file | 18:43 |
yvl | th1a, that is almost done | 18:43 |
yvl | and quite carefully | 18:44 |
aelkner | ubuntu.css? | 18:44 |
th1a | Oh, ok. | 18:44 |
yvl | with some unnecessary sugar that can be removed any time | 18:44 |
yvl | hence - Ubuntu fonts and stuff like that | 18:44 |
yvl | are already in flourish | 18:44 |
yvl | by the book, so to say | 18:44 |
th1a | Well, what I'd add to that is that, given yesterdays discussion about h2 margins, we might want to add some diagnostic outlines to various elements to help us see the spacing issues that crop up. | 18:44 |
th1a | Of course, firebug does that too. | 18:44 |
yvl | I am open to talk about this | 18:45 |
th1a | Ah, I have it running but haven't looke at it. | 18:45 |
yvl | just not today, please | 18:45 |
yvl | margins, padding and line heights are a bitch | 18:45 |
yvl | to put it gently | 18:45 |
yvl | there are some landmines in browser css support | 18:45 |
th1a | Well, that's why we aren't making them up from scratch. | 18:45 |
yvl | like magic 4 pixels out-of-nowhere | 18:46 |
th1a | OK. replaceafill, basically, take a look at that, start working on a plan. | 18:46 |
yvl | some of them you just need to know | 18:46 |
yvl | replaceafill: a note on form CSS if you ever do it | 18:46 |
replaceafill | th1a understood | 18:46 |
yvl | there are z3c_form_* templates in flourish | 18:46 |
yvl | if you make a resource library called | 18:46 |
th1a | In particular you might want to rip out all the calendaring css (there's a ton of it) and segregate it. | 18:46 |
yvl | schooltool.flourish.z3cform or whatever | 18:46 |
th1a | I think it is all mixed up now. | 18:46 |
yvl | and add z3c form specific css, that would be nice | 18:47 |
yvl | sadly, it may mean another library for formlib probably | 18:47 |
yvl | th1a, also done | 18:47 |
yvl | the ripping out part, that is | 18:47 |
th1a | Well, take a look at it replaceafill. | 18:47 |
yvl | I think that should be put back | 18:47 |
yvl | by whoever ports calendar views | 18:47 |
th1a | Apparently part of the reason yvl is so slow is he's doing things I figured someone else would do. | 18:47 |
yvl | and of course reviewed by the Czar | 18:48 |
yvl | :D | 18:48 |
replaceafill | :/ | 18:48 |
* yvl is greedy | 18:48 | |
replaceafill | so, yvl a better question | 18:48 |
replaceafill | what needs to be done in the css part? :) | 18:48 |
th1a | tbh, we're not going to be focusing on the calendar CSS much at all first time through. | 18:48 |
yvl | forms | 18:48 |
yvl | replaceafill, | 18:48 |
replaceafill | oh ok | 18:48 |
yvl | some basic elements are done | 18:48 |
replaceafill | yvl i should focus on those then? | 18:49 |
yvl | you could | 18:49 |
yvl | also, when views are remade | 18:49 |
yvl | there will be problems with spacing | 18:49 |
yvl | that needs to be solved with as little extra css classes as possible | 18:49 |
yvl | also! | 18:49 |
yvl | please keep the vertical rythm | 18:49 |
yvl | base is 8 pixels, FYI | 18:50 |
replaceafill | yes | 18:50 |
yvl | sum of all elements should be dividable by 8 | 18:50 |
yvl | I'm not sure if I made everything (that is specified now) pixel perfect | 18:50 |
th1a | Focus on getting rid of CSS. | 18:50 |
yvl | it's done, th1a | 18:50 |
yvl | we're starting from scratch | 18:50 |
th1a | Focus on selecting the right basic elements. | 18:51 |
yvl | right! | 18:51 |
yvl | :) | 18:51 |
replaceafill | yvl we only have the person form working right now, correct? | 18:51 |
yvl | add form | 18:51 |
yvl | and edit form | 18:51 |
yvl | yes | 18:51 |
replaceafill | ok | 18:51 |
yvl | and login :D | 18:51 |
yvl | they all look extremely crappy | 18:51 |
yvl | friggin fieldsets and all | 18:51 |
* th1a notes that this might be the moment that we switch from "Persons" to "People" | 18:52 | |
yvl | +1! | 18:52 |
replaceafill | :) | 18:52 |
yvl | People or Users | 18:52 |
th1a | Students aren't really users. | 18:52 |
th1a | Necessarily | 18:52 |
yvl | excellent point | 18:52 |
th1a | OK. | 18:52 |
yvl | People it is | 18:52 |
th1a | Let's be done now. | 18:52 |
th1a | Are we done now? | 18:52 |
aelkner | question | 18:53 |
aelkner | i will be working on person index.html today | 18:53 |
aelkner | and that involves the viewlets for personInfo manager | 18:53 |
*** jelkner has joined #schooltool | 18:53 | |
aelkner | yvl, did you already create new versions of the viewlets that i can change | 18:54 |
th1a | replaceafill, I guess you may need to give Chandara some love today, too. | 18:54 |
replaceafill | th1a great | 18:54 |
aelkner | i mean, in my brnahc this week (which was R&D branch) | 18:54 |
replaceafill | i want to get over with that too | 18:54 |
aelkner | i changed the viewlet templates in the course package, created a new one for advisory | 18:55 |
jelkner | th1a, do you have a minute, boss? | 18:55 |
th1a | jelkner, yes. | 18:55 |
aelkner | yvl, can i do the same in flourish? | 18:55 |
aelkner | just go ahead and change existing viewlet templates? | 18:55 |
yvl | aelkner, they are still bundled in old person.Info manager | 18:56 |
yvl | so it will most likely be the same | 18:56 |
aelkner | i don't understand | 18:56 |
aelkner | bundled in? | 18:56 |
yvl | they are same | 18:56 |
jelkner | asharma has been working diligently, but she has some concerns about the way the screenshots are turning out | 18:56 |
yvl | unchanged | 18:56 |
jelkner | see http://students.gctaa.net/~jeffelkner/STbookNepali/timetables.html | 18:56 |
yvl | short answer - yes you can | 18:56 |
replaceafill | aelkner you can take your changes and put it directly into flourish i think | 18:56 |
aelkner | ok, thanks | 18:57 |
replaceafill | (the viewlet ones) | 18:57 |
aelkner | ok, i'm done | 18:57 |
yvl | 95% that it will work effortlessly ;) | 18:57 |
yvl | ok guys | 18:57 |
jelkner | th1a, i can have her use gimp to shrink them | 18:57 |
yvl | good luck to you | 18:57 |
jelkner | but i don't want to waste her time | 18:57 |
yvl | and have fun! ;) | 18:57 |
aelkner | yvl, thanks! | 18:57 |
jelkner | so i wanted to check with you first | 18:57 |
replaceafill | thanks mr lead developer! :P | 18:57 |
th1a | She can shrink them. | 18:58 |
aelkner | jelkner, way to interrupt and meeting! | 18:58 |
th1a | Or do it programaticly with PIL. | 18:58 |
th1a | Or something else. | 18:58 |
aelkner | but anyway, i think th1a is tired of meeting | 18:58 |
jelkner | sorry aelkner, but i asked nicely 1st ;-) | 18:58 |
th1a | Either way, yes, shrinking is fine. | 18:59 |
th1a | Cropping, shrinking. | 19:00 |
th1a | That is jelkner? | 19:00 |
th1a | That it, jelkner? | 19:00 |
* th1a goes to lunch. | 19:01 | |
jelkner | th1a, yes sir | 19:02 |
* jelkner was showing asharma how to shrink images in gimp | 19:02 | |
replaceafill | jelkner have you seen phatch? | 19:03 |
jelkner | no | 19:03 |
replaceafill | in case you're doing batch resizing | 19:03 |
jelkner | mogrify works too | 19:03 |
jelkner | is it like that? | 19:03 |
replaceafill | dont know never saw mogrify :) | 19:03 |
replaceafill | but probably | 19:03 |
jelkner | the problem is, each of these images will need to be sized differently | 19:04 |
replaceafill | ah ok | 19:04 |
jelkner | so she really needs to look at them and use judgement | 19:04 |
jelkner | not a process that lends itself to automation | 19:04 |
*** dadeng has quit IRC | 19:42 | |
*** menesis has quit IRC | 20:06 | |
th1a | jelkner: You can see why I've been writing progressively more complicated automation scripts. | 20:15 |
th1a | replaceafill: ayt? | 21:27 |
replaceafill | th1a yes | 21:27 |
replaceafill | playing flourish | 21:28 |
replaceafill | :) | 21:28 |
th1a | I don't think I need to chime in with an email to Chandara at this point as long as you respond today. | 21:28 |
th1a | Or unless there is something in particular I need to say. | 21:28 |
replaceafill | ah, no, i'll work on that now | 21:29 |
replaceafill | i was just preparing for the meeting tomorrow | 21:29 |
th1a | I'm dividing your attention. | 21:30 |
replaceafill | :) | 21:30 |
th1a | But we need to keep Cambodia going. | 21:30 |
replaceafill | honestly, i'd like to focus on flourish today and tomorrow | 21:30 |
replaceafill | since i have yvl around | 21:31 |
replaceafill | but i'll go back to cambodia, no problem | 21:31 |
th1a | Well... you need to send an email and tell them what we're going to do. | 21:32 |
th1a | If you just want to say you'll work on it tomorrow or Monday, that's fine. | 21:32 |
th1a | Just don't leave them hanging. | 21:32 |
replaceafill | i'll better tell him i'll work on that on monday if that's ok then | 21:33 |
th1a | That's fine. Make sure you specify what you're going to do so we know you're both on the same page. | 21:33 |
*** jelkner has quit IRC | 21:37 | |
*** dadeng has joined #schooltool | 22:02 | |
*** alga has joined #schooltool | 22:18 | |
*** asharma has quit IRC | 22:39 | |
*** ignas has joined #schooltool | 23:13 | |
*** menesis has joined #schooltool | 23:39 | |
*** dadeng has quit IRC | 23:42 |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!