| *** alga has quit IRC | 00:04 | |
| *** ignas has quit IRC | 03:59 | |
| *** aks has joined #schooltool | 06:11 | |
| *** aks has joined #schooltool | 06:11 | |
| *** alga has joined #schooltool | 11:21 | |
| *** alga has quit IRC | 11:26 | |
| *** ignas has joined #schooltool | 13:16 | |
| *** ignas_ has joined #schooltool | 13:27 | |
| *** aks has quit IRC | 14:24 | |
| *** replaceafill has joined #schooltool | 16:10 | |
| *** th1a has joined #schooltool | 16:23 | |
| th1a | hi yvl, aelkner. | 16:30 |
|---|---|---|
| th1a | replaceafill is sick. | 16:30 |
| yvl | morning guys | 16:30 |
| replaceafill | good morning/afternoon | 16:31 |
| yvl | oh :/ | 16:31 |
| yvl | get well, replaceafill | 16:31 |
| aelkner | morning | 16:31 |
| replaceafill | ty | 16:31 |
| th1a | replaceafill started working on /resources. | 16:31 |
| replaceafill | nothing to show yet, will continue tomorrow | 16:33 |
| th1a | No problem. | 16:33 |
| th1a | My reflections over the holiday weekend were primarily: | 16:34 |
| th1a | 1) I'm excited about and proud of the changes we're making. | 16:34 |
| th1a | 2) We need to increase the pace, and the thing to cut is unnecessary pop-ups (going forward). | 16:36 |
| th1a | Not that I don't like them. | 16:36 |
| th1a | So: | 16:36 |
| th1a | a) make sure and warn me early and often about the kind of modals that we still can't do easily; | 16:36 |
| th1a | b) remind me to only use them where they really help. | 16:37 |
| th1a | OK? | 16:37 |
| yvl | agreed | 16:37 |
| yvl | and ditto on the excitement | 16:37 |
| th1a | So... aelkner, what were we stuck on last Friday that you wanted to talk to yvl about? | 16:38 |
| aelkner | it had to do with the field validators and the error snippets that are assosciated | 16:39 |
| aelkner | for instance, PythonIdentifier is the field type for demo field ids | 16:40 |
| th1a | That and the long fieldset legend conversation? | 16:40 |
| aelkner | right | 16:40 |
| aelkner | which one first? | 16:40 |
| aelkner | ok, the id field | 16:41 |
| aelkner | so if you put more than one work in that field, you get a very techie (not user-friendly) error message | 16:42 |
| aelkner | see: http://69.164.203.135:36660/demographics/addText.html | 16:42 |
| aelkner | if you fill in required fields, but have two workds for the id | 16:42 |
| aelkner | it says: Raised if the Validation process fails | 16:42 |
| aelkner | not very clear for the user | 16:43 |
| aelkner | now the error snippet that comes out (i found digging around in zope eggs) | 16:43 |
| yvl | since it's z3c.form, we'll just override the message | 16:43 |
| yvl | don't remember how to do that off hand | 16:44 |
| yvl | we can look at that after the meeting | 16:44 |
| aelkner | the snippets are registered in z3c/form/configure.zcml | 16:44 |
| aelkner | yeah, ok | 16:45 |
| aelkner | the other discussion regards the legend in forms | 16:45 |
| aelkner | we have a form macro which we should be using almost religously | 16:45 |
| aelkner | because it allows us to define the way the forms work merely using python and zcml | 16:46 |
| yvl | yes | 16:46 |
| aelkner | the macro has things like title, subtitle for the dark and light grey headings at the top | 16:46 |
| aelkner | label is for an <h3> at the top of the content area | 16:46 |
| aelkner | fields are rendered in the first fieldset | 16:47 |
| aelkner | and the groups (views registered against the view) are rendered as one fieldset per group | 16:47 |
| aelkner | the group title goes in the group's fieldset | 16:48 |
| aelkner | legend | 16:48 |
| aelkner | but groups is a special case for more complex forms | 16:48 |
| aelkner | and we didn't have anything defined for the lgend for the first fieldset | 16:48 |
| aelkner | the one that 90% of the forms will only be using | 16:48 |
| aelkner | so i added a legend element that uses view/legend|nothing | 16:49 |
| aelkner | i didn't add a legend=None to flourish.page.Page | 16:49 |
| aelkner | because I thought yvl should look this over before we go changing the base classes | 16:49 |
| yvl | ok | 16:49 |
| aelkner | but since the pt uses |nothing | 16:49 |
| aelkner | it works for any view that defines legend, which i did for the demo field add/edit views | 16:50 |
| aelkner | so we have title, subtitle, label and legend for the standard forms | 16:50 |
| aelkner | and groups for more complex ones | 16:51 |
| aelkner | sound right? | 16:51 |
| * yvl does not like that for normal forms label is label, legend is legend, but for "groups" label is legend | 16:53 | |
| replaceafill | +1 | 16:53 |
| aelkner | we could change the group label to legend | 16:53 |
| * yvl would prefer consistency here | 16:53 | |
| yvl | yes please | 16:53 |
| aelkner | +1 here as well | 16:53 |
| aelkner | i think it is so because | 16:53 |
| yvl | other than that, I'm good with the change | 16:53 |
| th1a | OK, we'll use the weird HTML name. | 16:54 |
| aelkner | the group view was considered renderable as a standalone view | 16:54 |
| aelkner | \so label would matter then | 16:54 |
| yvl | we can change names to whatever we want at this point | 16:54 |
| yvl | just keep them consistent | 16:54 |
| aelkner | but we din'e need to think of the groups as standalone views, so... | 16:54 |
| aelkner | don't need | 16:55 |
| aelkner | anyway, i don't know what vew even uses groups | 16:55 |
| yvl | then again, that is not an argument for having two different behaviours | 16:55 |
| aelkner | person add/edit views should use groups, but they don't | 16:55 |
| yvl | and call them subforms, yes | 16:56 |
| aelkner | they have their own custom pt using fieldsets as the attibute | 16:56 |
| yvl | yes | 16:56 |
| aelkner | and creates the fieldsets manually rather than views registered on views | 16:56 |
| aelkner | we don't need to change that right now, but in the future | 16:56 |
| yvl | sure | 16:56 |
| aelkner | if we want that kind of view, we should take advantage of the macro | 16:56 |
| yvl | +1 | 16:57 |
| yvl | and base classes and decent subforms at some point | 16:57 |
| yvl | but it may happen after this release though | 16:57 |
| aelkner | does anyone know of a view that uses groups? | 16:57 |
| aelkner | i'm just curious to see if that part of the macro is as yet unused | 16:59 |
| th1a | The person add forms do. | 16:59 |
| yvl | I don't think so | 16:59 |
| th1a | It is not an oddball case -- we'll be using more grouping for clarity. | 16:59 |
| yvl | they reimplement that behaviour | 16:59 |
| yvl | right | 16:59 |
| aelkner | no, i was saying before that is done custom | 16:59 |
| th1a | Right.. | 16:59 |
| yvl | I don't think that there are any views left that use groups | 16:59 |
| yvl | maybe something I forgot | 17:00 |
| aelkner | ok, i think the same is true | 17:00 |
| yvl | in any case, we should definitely implement API that makes using subforms (groups) easy | 17:00 |
| yvl | at some point | 17:00 |
| aelkner | so we can change the macro to use group/legend instead of group/label right now | 17:00 |
| yvl | th1a made a good point - not an oddball case | 17:00 |
| yvl | definitely | 17:00 |
| aelkner | so yvl, should be put legend=None in flourish.page.Page right now? | 17:01 |
| aelkner | i mean, for clarity to the developers | 17:01 |
| yvl | well... nah | 17:01 |
| aelkner | actually, we could use a base class for forms | 17:02 |
| yvl | I would prefer putting them into flourish.form.Form when we have those | 17:02 |
| yvl | right ;) | 17:02 |
| aelkner | :) | 17:02 |
| yvl | then again, I can make one tomorrow | 17:02 |
| yvl | doh | 17:02 |
| yvl | or today, if I'm a good boy ;) | 17:02 |
| aelkner | and we should start after that being good about using Form as base class for forms | 17:02 |
| yvl | aelkner, so I'll take care of this part | 17:02 |
| aelkner | and PAge for all other pages | 17:02 |
| yvl | right | 17:03 |
| aelkner | yvl, cool | 17:03 |
| aelkner | so we can discuss the validation error after the meeting | 17:03 |
| aelkner | th1a, i also loaded the changes to the forms (interface changes) into my instance | 17:03 |
| yvl | right | 17:03 |
| aelkner | so after i'm done discussing things with yvl, we could go over the forms and make any adjustments | 17:04 |
| th1a | aelkner: You haven't started resource attributes, right? | 17:04 |
| aelkner | not yet | 17:04 |
| th1a | OK. | 17:04 |
| th1a | So you know what you're doing next. | 17:04 |
| th1a | I'll take a look at the forms. | 17:04 |
| th1a | yvl: Are we wizardy yet? | 17:04 |
| aelkner | i could do /resource_demographics | 17:04 |
| yvl | th1a, yes, merged today | 17:05 |
| th1a | aelkner: Yes, that's what I'm saying. | 17:05 |
| yvl | it's somewhat quirky | 17:05 |
| yvl | does not reload the parent page after new timetable is created | 17:05 |
| th1a | replaceafill: Can you update the demo instance? | 17:05 |
| yvl | and glitches every time you press a button | 17:05 |
| replaceafill | th1a k | 17:06 |
| yvl | (you'll need to enter schooltool/2010/timetables link manually) | 17:06 |
| th1a | OK. | 17:06 |
| yvl | the glitches are because the dialog is "suspended" in a dumbest way possible | 17:06 |
| yvl | by erasing it's contents | 17:06 |
| yvl | we'll do something better later, but it's a central place, so - one change | 17:06 |
| yvl | what else... | 17:06 |
| yvl | there are more plumbing problems, like session expiring / user log-out while in that page | 17:07 |
| yvl | tracebacks also are not handled properly - they kind of disappear | 17:07 |
| yvl | but that's normal ui plumbing we'll need to do | 17:07 |
| *** ignas has quit IRC | 17:08 | |
| replaceafill | yvl is the new trunk designed to work with flourish.lyceum.journal? | 17:08 |
| *** ignas_ has quit IRC | 17:08 | |
| yvl | I put delete images in the container view, they're probably not ok there | 17:08 |
| * th1a is waiting to see it... | 17:08 | |
| replaceafill | im getting an error | 17:08 |
| yvl | replaceafill, | 17:08 |
| yvl | no | 17:08 |
| replaceafill | ZopeXMLConfigurationError: File "/home/replaceafill/sandboxes/st-flourish/flourish.journal/src/schooltool/lyceum/journal/configure.zcml", line 9.2 | 17:08 |
| replaceafill | ImportError: cannot import name ITimetableCalendarEvent | 17:08 |
| * yvl forgot to port | 17:08 | |
| replaceafill | ah ok | 17:08 |
| yvl | sorry | 17:08 |
| yvl | I'll fix that after the meeting or tomorrow | 17:08 |
| yvl | developers might be interested in two things: | 17:09 |
| yvl | flourish/browser/templates/f_ttwizard_choice.pt | 17:09 |
| replaceafill | hhmm yvl same thing on the egg (sorry to interrupt) | 17:09 |
| yvl | onclick="ST.dialogs.submit(this, this)" | 17:09 |
| replaceafill | ZopeXMLConfigurationError: File "/home/replaceafill/sandboxes/st-flourish/eggs/schooltool.lyceum.journal-0.8.0dev_r256-py2.6.egg/schooltool/lyceum/journal/configure.zcml", line 9.2 | 17:09 |
| replaceafill | ImportError: cannot import name ITimetableCalendarEvent | 17:09 |
| yvl | replaceafill, it won't work with journal | 17:10 |
| replaceafill | ah! | 17:10 |
| yvl | sorry | 17:10 |
| replaceafill | sorry | 17:10 |
| yvl | another thing of interest | 17:10 |
| replaceafill | th1a updated | 17:10 |
| yvl | timetable.browser.app.FlourishTimetableContainerView | 17:11 |
| yvl | ImageInputColumn | 17:11 |
| yvl | probably I duplicated replaceafill's work accidentaly | 17:11 |
| replaceafill | s/duplicated/improved :P | 17:11 |
| yvl | in any case, that is in schooltool.table.table package now | 17:11 |
| replaceafill | s/accidentally/on purpose | 17:11 |
| yvl | :D | 17:11 |
| * yvl is not *that* evil | 17:11 | |
| replaceafill | nice job with the image column! | 17:12 |
| th1a | Hm... can I create a year? | 17:12 |
| yvl | no | 17:12 |
| yvl | we did not implement that ;) | 17:12 |
| th1a | Right. | 17:13 |
| th1a | Probably that should be next. ;-) | 17:13 |
| th1a | replaceafill: Can I have a year? | 17:13 |
| th1a | Isn't there a way to access different skins via the URL? | 17:13 |
| replaceafill | th1a we do | 17:13 |
| replaceafill | http://69.164.203.135:6660/schoolyears/2011 | 17:13 |
| th1a | Cool. | 17:14 |
| replaceafill | the index view doesnt work of course :) | 17:14 |
| yvl | oh... http://69.164.203.135:6660/schoolyears/2011/timetables | 17:14 |
| yvl | just created a timetable :) | 17:15 |
| th1a | So... if I change the title and then go back it doesn't remember the new title? | 17:15 |
| yvl | no, at the moment | 17:16 |
| yvl | which is probably wrong | 17:16 |
| th1a | I' | 17:16 |
| yvl | this was actually the simplest implementation | 17:16 |
| th1a | I'm a little anti-cancel button here. | 17:16 |
| th1a | yvl: Sure. | 17:16 |
| yvl | true, it does look a bit out of place | 17:17 |
| yvl | frankly, I just wanted to test the cancel button there :) | 17:18 |
| yvl | because we may need that in some dialogs | 17:18 |
| th1a | Yes. | 17:18 |
| yvl | we could keep it in first step only | 17:18 |
| yvl | or completely remove it | 17:18 |
| th1a | OK. | 17:18 |
| replaceafill | nice, validation on the dialogs! | 17:18 |
| th1a | It is a good start. | 17:18 |
| yvl | right | 17:19 |
| aelkner | th1a, merged yvl's timetable changes and loaded into my instance | 17:19 |
| th1a | I'll give you more feedback in an email. | 17:19 |
| yvl | thanks, th1a | 17:19 |
| th1a | I need to revisit these individual forms. | 17:19 |
| th1a | Which were rushed in the original implementation. | 17:19 |
| th1a | As I'm sure you've noticed. | 17:20 |
| yvl | time is always a precious commodity ;) | 17:20 |
| yvl | th1a, is there something you'd like me to work on? | 17:21 |
| * yvl probably want's to do a little plumbing, or at least look at that and maybe postpone it | 17:22 | |
| yvl | also - timetable views themselves | 17:22 |
| th1a | Right this minute or tomorrow? | 17:22 |
| aelkner | yvl, you are done with timetable mostly? | 17:22 |
| yvl | tomorrow | 17:22 |
| yvl | aelkner, no - just the modal wizard | 17:22 |
| th1a | I'll give you feedback for tomorrow on more timetable bits. | 17:22 |
| yvl | sure | 17:22 |
| yvl | thanks! | 17:22 |
| aelkner | how about the modal plumbing we talked about last week? | 17:23 |
| yvl | well, it kind of features it ;) | 17:23 |
| aelkner | well, that's great | 17:23 |
| yvl | the plumbing is the simplest solution that worked for me | 17:23 |
| th1a | Who needs to do what regarding the fieldset legends (an issue I can't quite force myself to understand)? | 17:23 |
| * yvl is trying hard not to get too deep into stuff | 17:23 | |
| aelkner | is it independent from the timetable logic? | 17:23 |
| th1a | We really can't plunge into plumbing now. | 17:24 |
| yvl | precisely, th1a | 17:24 |
| * yvl just wanted to show that he's aware of that :) | 17:24 | |
| yvl | aelkner, yes | 17:24 |
| aelkner | i'm ok with tabling the discussion, i just wanted to make a note of the task yet to be done | 17:24 |
| yvl | basically, if you do the onclick="" thing for a form inside a modal dialog | 17:24 |
| yvl | it should be good enough | 17:25 |
| aelkner | by onclik="" you mean the document.ready js we've been using? | 17:25 |
| yvl | no | 17:25 |
| aelkner | th1a, i realize you are leaning away from modals, but we will still end up with more than one | 17:26 |
| yvl | please look at timetable/browser/templates/f_ttwizard_*.pt | 17:26 |
| aelkner | so plumbing will mater at some point | 17:26 |
| aelkner | yvl, after the meeting? | 17:26 |
| yvl | sure | 17:26 |
| th1a | OK aelkner & replaceafill, get me your invoices. | 17:27 |
| th1a | Thanks guys. | 17:27 |
| * th1a drops the bag of gravel. | 17:27 | |
| yvl | thanks guys | 17:27 |
| yvl | and thanks th1a! | 17:27 |
| th1a | Let the after-meeting begin! | 17:27 |
| aelkner | :) | 17:28 |
| yvl | :) | 17:28 |
| yvl | ... after these commercials ... | 17:28 |
| aelkner | th1a, i'll send invoice after that | 17:28 |
| * yvl takes a 5 minute break | 17:28 | |
| aelkner | yvl, puff away | 17:28 |
| yvl | :P | 17:28 |
| aelkner | :) | 17:28 |
| * yvl back, aelkner | 17:33 | |
| yvl | so, what would you like to discuss first? | 17:34 |
| aelkner | um | 17:35 |
| aelkner | let's pop the stack | 17:35 |
| aelkner | let's get the modal discussion out of the way | 17:35 |
| yvl | ok | 17:35 |
| aelkner | i haven't had time to pur over your timtable stuff | 17:35 |
| yvl | right, it's quite fresh | 17:36 |
| aelkner | but i was just wondering about the plans for keeping modal view/link | 17:36 |
| aelkner | generation simple to do | 17:36 |
| * yvl has plans for that too, but tabled for now | 17:36 | |
| yvl | first, let's look at timetable/browser/templates/f_ttwizard_choice.pt | 17:36 |
| aelkner | ok, looking... | 17:37 |
| yvl | the interesting parts are onclick="" | 17:37 |
| aelkner | yeah, i'll say they are interesting :) | 17:38 |
| yvl | for ST.dialogs.submit() | 17:38 |
| yvl | first argument is the "form selector" | 17:38 |
| yvl | basically an element from which I use jQuery to find the closest form | 17:38 |
| yvl | since buttons are inside the form, that works | 17:38 |
| aelkner | makes sense | 17:38 |
| yvl | then it searches the closest jQuery dialog | 17:39 |
| yvl | the second parameter is optional | 17:39 |
| yvl | it is the selector of the buttton clicked | 17:39 |
| yvl | again, that's the same button | 17:39 |
| yvl | if you ommit the button, it will not get into the POST request, and you won't see what's been clicked from Zope | 17:40 |
| yvl | just so you know - you can control "other" forms simply by passing custom selectors instead of "this" | 17:41 |
| yvl | we probably won't need that, but this might be an useful side-effect | 17:41 |
| yvl | ST.dialogs.close(this) works in the same way | 17:41 |
| yvl | finds closest dialog to "this" (button) and closes it | 17:41 |
| yvl | I didn't try - but we can also add those on-clicks to z3c.form forms | 17:42 |
| yvl | but we'll need to do that quite explicitly | 17:42 |
| yvl | IIRC that would be getting the buttons, the same way we do when we want to addClass to the buttons | 17:42 |
| yvl | and setting buttons['cancel'].onclick="ST.dialogs.close(this)" | 17:43 |
| aelkner | i was about to go there | 17:43 |
| aelkner | but you beat me to it :) | 17:43 |
| aelkner | if we have the general enough case | 17:43 |
| aelkner | then python is all we need | 17:43 |
| aelkner | and base class can handle most cases | 17:44 |
| yvl | yes | 17:44 |
| aelkner | how soon can we have that? | 17:44 |
| yvl | I should probably work on that today before I leave | 17:44 |
| yvl | but no promises ;) | 17:44 |
| yvl | latest - tomorrow morning | 17:44 |
| aelkner | sounds great | 17:44 |
| yvl | but probably today | 17:45 |
| yvl | :) | 17:45 |
| aelkner | i will defer pouring over your changes till then | 17:45 |
| aelkner | save me time doing it twice | 17:45 |
| yvl | ok | 17:45 |
| aelkner | anyway, i only brought this stuff up because you were asking for something to do :) | 17:45 |
| yvl | :))) | 17:46 |
| aelkner | ok, we can pop the stack again | 17:46 |
| yvl | ok | 17:46 |
| yvl | errors | 17:46 |
| aelkner | z3c/form/configure.zcml | 17:46 |
| yvl | >>> NegativeAgeMessage = error.ErrorViewMessage( | 17:47 |
| yvl | ... u'A negative age is not sensible.', | 17:47 |
| yvl | ... error=TooSmall, field=IPerson['age']) | 17:47 |
| yvl | >>> zope.component.provideAdapter(NegativeAgeMessage, name='message') | 17:47 |
| aelkner | what file is this from? | 17:47 |
| yvl | that's an example from z3c/form/error.txt | 17:47 |
| aelkner | ok, looking... | 17:47 |
| yvl | you beat me to it this time ;) | 17:47 |
| aelkner | yeah, but i didn't have the sense to reach as far as error.txt! | 17:48 |
| replaceafill | aelkner do you need to customize the error message for a single field in the form? | 17:49 |
| yvl | you don't necessarily need to customize for the field | 17:49 |
| aelkner | replaceafill, yes, a PythonIdentifier field | 17:49 |
| yvl | simply error=ThatErrorType would probably do | 17:49 |
| aelkner | yvl, where? | 17:49 |
| aelkner | in the interface? | 17:50 |
| th1a | The error message should address the specific field. Ideally. | 17:50 |
| yvl | we can do that | 17:50 |
| yvl | aelkner, error.ErrorViewMessage takes these parameters: | 17:50 |
| yvl | ('error', 'request', 'widget', 'field', 'form', 'content') | 17:50 |
| aelkner | th1a, true, but also general cases can be expanded for tings like float fields or something | 17:50 |
| yvl | where content is context I guess | 17:50 |
| aelkner | or any custom type of field we want | 17:51 |
| * th1a tells himself YAGNI. | 17:51 | |
| aelkner | yvl, where do you put the call then? | 17:51 |
| yvl | in something.py: | 17:51 |
| aelkner | th1a, solving your need and providing plumbing is the same cost | 17:52 |
| aelkner | i mean, the field on the form is the issue | 17:52 |
| yvl | MyErrorMessage = z3c.form.error.ErrorViewMessage(_('The new message'), error=TheErrorClass, field=TheField) | 17:52 |
| yvl | then in zcml: | 17:52 |
| aelkner | but we aren't going to have to specify (redundantly) the error types everywhere | 17:52 |
| yvl | <adapter ".something.MyErrorMessage" name="message" /> | 17:52 |
| aelkner | yvl where My...=? | 17:53 |
| yvl | eh? | 17:53 |
| aelkner | please be specific so my feeble brain can follow | 17:53 |
| aelkner | MyErrorMessage = | 17:53 |
| aelkner | interface.py? | 17:53 |
| yvl | look at | 17:53 |
| yvl | term/browser/term.py | 17:53 |
| yvl | or better yet... | 17:54 |
| yvl | well, term.py is ok | 17:54 |
| yvl | we use WidgetsValidatorDiscriminators(...) there | 17:55 |
| yvl | so in the same way | 17:55 |
| yvl | just put: | 17:55 |
| aelkner | i was looking for this kind of thing... | 17:55 |
| yvl | WrongIDErrorMessage = error.ErrorViewMessage(...) | 17:55 |
| yvl | and then the adapter in configure.zcml | 17:55 |
| aelkner | see, that's what i'm talking about! :) | 17:56 |
| yvl | ah, found it! | 17:56 |
| yvl | skin/widgets.py | 17:56 |
| yvl | Fckeditor_editform_config = ComputedWidgetAttribute( | 17:56 |
| yvl | basically - the same thing | 17:56 |
| aelkner | um, i don't like that one so much | 17:57 |
| aelkner | i mean, it's confusing | 17:57 |
| aelkner | the other one at least had a comprehensible argument list | 17:58 |
| yvl | ok | 17:58 |
| yvl | if you want to know the actual argument list | 17:58 |
| yvl | you need to look at | 17:58 |
| yvl | z3c/form/error.py | 17:58 |
| aelkner | no, i understand that part from looking myself | 17:59 |
| yvl | discriminators= show the valid arguments | 17:59 |
| * replaceafill goes back to bed, see you tomorrow gentlemen | 17:59 | |
| aelkner | and also, you mentioned it above | 17:59 |
| aelkner | replaceafill, feel better! | 17:59 |
| replaceafill | thanks aelkner | 17:59 |
| *** replaceafill has quit IRC | 17:59 | |
| yvl | right, aelkner | 17:59 |
| aelkner | i was just saying we need the right set of base classes to make this look more like term.py | 18:00 |
| aelkner | and less like the cheditor example | 18:00 |
| * yvl agrees | 18:00 | |
| yvl | probably something like | 18:00 |
| yvl | ErrorViewMessage(_('This is not a valid ID'), | 18:01 |
| yvl | error=IDontRemeberTheClass, | 18:01 |
| yvl | field=IPythonIdentifier, | 18:01 |
| yvl | request=IFlourishLayer) | 18:01 |
| * yvl probably named the classes wrong | 18:01 | |
| yvl | but you probably get the idea | 18:01 |
| aelkner | i do | 18:02 |
| aelkner | that and the zcml <adapter> thing, and done, right? | 18:02 |
| yvl | yes | 18:02 |
| aelkner | i'll try that out today and we can talk about it tomorrow | 18:02 |
| yvl | fck widget thing also does that at the end of skin/configure.zcml | 18:02 |
| aelkner | so really, no base class needs to be created | 18:02 |
| aelkner | just the one python call and the zcml | 18:03 |
| yvl | just uses the name "config", and you need to use "message" since that's what you want to change | 18:03 |
| yvl | yes, aelkner | 18:03 |
| aelkner | ok, understood then | 18:03 |
| yvl | it's quite flexible, but somewhat not easy on the eye | 18:03 |
| aelkner | and ckconfig is special case anyway | 18:03 |
| aelkner | yes, that is true | 18:03 |
| aelkner | easier to find examples always makes these things easier to deal with | 18:04 |
| yvl | true :) | 18:04 |
| aelkner | at some point i'm going to write a developers doc, and you can fill in the parts i get wrong | 18:04 |
| aelkner | but my doc is definitely going to point quickly (and omni-presently) to examples | 18:04 |
| yvl | +1 | 18:05 |
| aelkner | soon, but ot yet though | 18:05 |
| aelkner | not | 18:05 |
| yvl | just it would be a little bit nicer if the examples were in the doc itself | 18:05 |
| yvl | code tend's to move around | 18:05 |
| yvl | it would be sad to see it out of date :| | 18:05 |
| aelkner | it's a good point, but really one could look at it as being a doc that enforces a discipline | 18:06 |
| aelkner | on developers in addition to aiding them | 18:06 |
| aelkner | and the responsibility could then be high on keeping it in sync with code | 18:06 |
| aelkner | but we can talk about that later | 18:07 |
| yvl | sure | 18:07 |
| yvl | allright then... | 18:07 |
| aelkner | i think we are done then | 18:07 |
| yvl | maybe I can go home, and do the base form class later? | 18:07 |
| yvl | i.e. tomorrow? | 18:07 |
| aelkner | right | 18:07 |
| yvl | if it's not pressing | 18:07 |
| aelkner | we can discuss what you've done then | 18:08 |
| aelkner | at the meeting | 18:08 |
| yvl | cool | 18:08 |
| aelkner | ok, i'll let you go | 18:08 |
| yvl | thanks | 18:08 |
| yvl | good luck! | 18:08 |
| aelkner | have a good one | 18:08 |
| yvl | see you soon :) | 18:08 |
| yvl | thanks | 18:08 |
| aelkner | cya | 18:08 |
| aelkner | and thanks for your insights | 18:08 |
| th1a | aelkner: We might want to wait for replaceafill to tell you how to do this, but I'd like to use the jquery-ui checkbox icon instead of the "x" in your demographics table. | 18:11 |
| th1a | See http://jqueryui.com/themeroller/ | 18:11 |
| th1a | aelkner: Switch "Limit keys" in various add/edit forms to "Limit to group(s)" | 18:12 |
| aelkner | th1a, invoice sent | 18:13 |
| aelkner | th1a, if we already use the checkbox icon somewhere | 18:14 |
| th1a | aelkner: Change "Reorder fields" in the sidebar to "Reorder or Delete Fields" | 18:14 |
| aelkner | i probably can figure out how to do it | 18:14 |
| th1a | Let's just ask replaceafill tomorrow. | 18:15 |
| aelkner | ok | 18:15 |
| th1a | He uses one of them somewhere. | 18:15 |
| aelkner | any other changes? | 18:15 |
| aelkner | i can ping you when i've made them all | 18:15 |
| th1a | I guess we're capitalizing the sidebar links like titles. | 18:15 |
| th1a | So keep that consistent. | 18:15 |
| aelkner | can you let me know when you go on lunch break so that i choose the same time to break? | 18:16 |
| th1a | OK. | 18:16 |
| aelkner | ok, no sentence caps for sidebar | 18:16 |
| th1a | aelkner: Take out the hint for "Required" on these forms. | 18:16 |
| aelkner | just for labels, right? | 18:16 |
| th1a | Hm? | 18:17 |
| aelkner | sentence caps for form labels | 18:17 |
| th1a | Yes. | 18:17 |
| aelkner | i mean, we don't even use the form label for demo field add/edit | 18:17 |
| aelkner | but i was just trying to establish that | 18:17 |
| aelkner | ok | 18:17 |
| th1a | I have no idea what you're talking about, but is probably fine. | 18:17 |
| aelkner | :) | 18:18 |
| aelkner | i tend to file things into general slots, so you think of certain parts of the page with the same terms as me | 18:18 |
| th1a | OK, I see. | 18:18 |
| aelkner | i mean, i hope to | 18:18 |
| th1a | I just thought you were responding to me but you were continuing your thought. | 18:18 |
| aelkner | yeah, that's ok | 18:18 |
| aelkner | basically, as you saw, we are mapping out parts of the pages with view attributes | 18:19 |
| aelkner | it is important for us to be able to drive stuff with python | 18:19 |
| th1a | Oh... we need a hint for "list of values" | 18:19 |
| aelkner | so i figure, since we already need to do that | 18:19 |
| th1a | Can that be higher in the Selection List form? | 18:20 |
| aelkner | i would have you communicate what you want us to do using the same attribute names | 18:20 |
| aelkner | title (dark grey) subtitle (light grey), label (h3), legend (first fieldset legend) | 18:21 |
| aelkner | so if you can use those terms, you can communicate the changes speedily to us | 18:22 |
| aelkner | appropos, i was going to ask you to go over those things on the demo field add/edit views | 18:22 |
| aelkner | i chose the best title/subtitle i could think of for add/edit | 18:23 |
| aelkner | but you might have a better idea in mind | 18:23 |
| th1a | Not really. | 18:23 |
| th1a | Can we move "list of values" higher in the selection list field form? | 18:23 |
| aelkner | and have Limit to group(s) at the bottom, right? | 18:25 |
| th1a | Yes. | 18:26 |
| th1a | Just move it above required. | 18:26 |
| aelkner | i'm curious about our plans | 18:27 |
| aelkner | if you don't mind me asking about things like old skin tests and all that | 18:27 |
| aelkner | i don't know if changing the order of the interface will break existing tests | 18:28 |
| aelkner | i probably should if those tests were thorough enough :) | 18:28 |
| th1a | We'll have to clean up later. | 18:28 |
| aelkner | ok, we'll have a period of time devoted to just that, right? | 18:28 |
| th1a | Yes. | 18:28 |
| aelkner | ok, never mind then | 18:28 |
| aelkner | i'll change the order now | 18:29 |
| th1a | Yes... now is not the slow down and clean up point. | 18:30 |
| th1a | That'll be in about six weeks. | 18:30 |
| th1a | Make List of values: "Selection list" | 18:32 |
| th1a | Hint: "Enter the valid values for the field below. One value per line. These values will be displayed as a menu in forms." | 18:33 |
| th1a | aelkner, Did I mention capitalize "Yes" and "No" under "Required?" | 18:34 |
| th1a | Oh, and I guess we need a "Done" link here to go back to Manage. | 18:35 |
| th1a | In /demographics. | 18:35 |
| th1a | That may end up being changed, but lets put it there for now. | 18:36 |
| th1a | I think that's it. | 18:36 |
| aelkner | Done link here, where would that be? | 18:37 |
| th1a | In /demographics. | 18:37 |
| aelkner | back to School, you mean? | 18:38 |
| aelkner | and that tab doesn't work yet, btw | 18:38 |
| aelkner | oh, Applicatiopn works | 18:38 |
| aelkner | sorry, school works too | 18:38 |
| th1a | Uh... yeah, do /settings | 18:38 |
| aelkner | that's new | 18:38 |
| aelkner | yvl must have fixed those views | 18:38 |
| aelkner | ok, so i'll go to settings | 18:38 |
| th1a | Where is goes is not so much an issue as having it there. | 18:38 |
| aelkner | i'll put it at the end like in reorder/delete view | 18:39 |
| th1a | Yes. | 18:40 |
| aelkner | th1a, everything loaded into my instance except yes/no change | 18:46 |
| aelkner | that will probably be a bit trickier | 18:46 |
| aelkner | i bet we use standard zope widget for that | 18:47 |
| th1a | Meh. | 18:47 |
| th1a | Well, check quickly if you can. | 18:47 |
| aelkner | ok | 18:47 |
| aelkner | in the meantime, check my work against what you were asking for | 18:47 |
| aelkner | th1a, we have no yes/no widget in our own source, so it's definitely a zope rendering | 18:51 |
| aelkner | could we wait until tomorrow to discuss with yvl? | 18:51 |
| th1a | Meh. Can we just, like, subclass it and fix that or something? | 18:51 |
| aelkner | that's the whole point of these plumbing discussions, so we arrive a point where we | 18:52 |
| aelkner | can do just that, subclass something and override | 18:52 |
| aelkner | but i don't now of any plumbing for that right now | 18:52 |
| aelkner | know of any | 18:53 |
| aelkner | can we table that until tomorrow? | 18:53 |
| th1a | Sure. | 18:55 |
| aelkner | otherwise, any goofs by me in the forms? | 18:55 |
| th1a | I gave you new text for "List of values" and its hint. | 18:56 |
| aelkner | oops, sorry, let that slip | 18:56 |
| th1a | Also, get rid of the hint for "Required" on all the add/edit forms. | 18:56 |
| aelkner | right | 18:56 |
| aelkner | th1a, changes loaded in instance | 19:00 |
| * th1a is about ready for lunch. | 19:00 | |
| aelkner | could you check one last time | 19:00 |
| aelkner | hopefully i won't make you repeat yourself yet again | 19:01 |
| th1a | OK, good. Lunch! | 19:03 |
| aelkner | ok | 19:03 |
| th1a | Basically, you can start the same process for resource attributes now. | 19:03 |
| th1a | Make sure they aren't called demographics anywhere in the interface! | 19:03 |
| aelkner | Resource attribtues? | 19:04 |
| aelkner | Resouce custom attrbtues? | 19:04 |
| th1a | Just attributes is fine. | 19:04 |
| aelkner | I mean for form title/subtitle | 19:04 |
| aelkner | because the appear prominantly at top | 19:04 |
| aelkner | we have (Demographics) (Change information for Ethnicity) | 19:05 |
| aelkner | for instance | 19:05 |
| aelkner | See the problem is this: | 19:06 |
| aelkner | conceptually the user is forced to think of two things | 19:06 |
| aelkner | 1) the fact that there are demo fields (give me a sec here) | 19:06 |
| aelkner | 2) the fact that these custom fields appear in the form for adding or editing a particular object | 19:07 |
| aelkner | so even calling the title Demographics as we have so far is not very clear | 19:07 |
| aelkner | the actual filled in values for persons are the dmeographcis | 19:07 |
| aelkner | the fields are the schema | 19:07 |
| aelkner | and i know you don't want to use that word for users! | 19:08 |
| aelkner | but there has to be some way to define the difference for the user | 19:08 |
| aelkner | so that these links and form labels make sense | 19:08 |
| aelkner | form titles/subtitles i mean of course | 19:08 |
| aelkner | well, and the label, too, if we want to include it (which we don't at the moment) | 19:09 |
| aelkner | so how about after lunch | 19:09 |
| aelkner | ok, i'll assume th1a has already made that decision :) | 19:10 |
| * th1a went to lunch. | 19:32 | |
| th1a | I | 19:33 |
| th1a | am not super concerned about the use of demographics for people, although it is a little sloppy. | 19:33 |
| th1a | I just don't want the concept of "resource demographics" to appear at all in the interface. | 19:34 |
| aelkner | please suggest what you do want when you suggest what you don't want so that I know what to do | 19:42 |
| th1a | Resource attributes. | 19:42 |
| th1a | That's what I want. | 19:42 |
| aelkner | for title | 19:43 |
| th1a | Resource attributes? | 19:43 |
| aelkner | right | 19:43 |
| th1a | Yes. | 19:43 |
| aelkner | subtitle? | 19:43 |
| aelkner | New Text Field as before, right | 19:43 |
| aelkner | Change information for Roofing | 19:43 |
| aelkner | for a resource demo field, for instance | 19:44 |
| aelkner | that's for editing, of course | 19:44 |
| aelkner | ok,i'll assume that you are ok with that | 19:45 |
| th1a | Well, considering we just did exactly the same thing, I don't see what the problem is. | 19:45 |
| th1a | Just do the same thing. | 19:45 |
| aelkner | it is consistent that way | 19:45 |
| aelkner | that can't be bad | 19:45 |
| aelkner | ok, agreed | 19:45 |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!